Close
0%
0%

Reactron Collector: switch module

A completely independent, stand-alone, rechargeable switch module, integrated into a wireless RF network, with an assignable purpose.

Similar projects worth following
Fairly simple, this stand-alone module is basically just a switch wired to a digital input of an ATmega328P, with a HopeRF radio to transmit the button state to the network. The unit is coded to be asleep most of the time, since it is a human interface device it doesn't require a heavy duty cycle. Consequently the device can use very little power, and last a very long time on a single charge from the rechargeable battery. This also makes it completely wireless.

Unremarkable hardware, but the utility lies in the implementation. Sometimes you just need a button somewhere, that does something concrete, or abstract. This button allows you to have a button anywhere in range of the RF network, and assign it to do any action available on the RF network - physical or otherwise. Turn on a light, pump some water, send an e-mail, trigger a file copy to a backup device, anything.

The handful of components are simple, a battery holder and rechargeable battery from Sparkfun, a Reactron arduino clone with radio. The button itself is a lighted SPST momentary switch.

The code is what adds a little flexibility to this setup. The switch could actually be any of a choice of switches, with numerous poles , tri-state, latching, etc. The code is what decides how the switch behaves. This particular SPST momentary is tied to a digital input and a digital output, where the digital output is pulsed. When the switch is closed, the input sees a pulsed signal. This allows a bit of safety, we know that the switch is not accidentally open or shorted - or if it is, we can ignore it or take an appropriate action.

In addition, this switch has a blue LED built in. That LED is also tied to a digital output, and the code will light the light if and only if all the conditions assigned to enabling the switch are true. this is how you know that all the dependencies are online and ready to go.

Technically, this could be considered an Integron, a human interface device within the Reactron network. It has human input (button press) and output meant for human eyes (light). While that is true, it is not very complex as far as interaction goes. The light is basically an “on” light, indicating operational status, and the button is just a bit (for this switch) or set of bits (for more complex switches). The important thing is the state of those bits. So this is a Collector - it collects the data, which are the state of the bits (in this case, just the one).

By itself, it does nothing. A bit turns on and off, completely useless if it isn’t assigned some action to trigger by another node that is monitoring its state (or receiving its state actively and asynchronously - both modes are available). But that too is the strength and the flexibility - it can be assigned to anything, and it can have a one-to many, many-to-one, or many-to-many relationship between monitoring node(s) and actioning node(s).

In the house of the future, perhaps all light switches will be these low-voltage, wireless, data-only devices. Not this hardware, but perhaps something even more low-power with a tiny sealed battery that would last thirty years. (But the concept is the same, those would just be inevitable refinements.) This way, you don’t have to have mains wiring all over the place, every place you need what is essentially just a human interface. Power could go just from the source to the light (or other load) with a data interpreter in between, monitoring the bits in these switches. Even today, these switches can be made completely flat, with thickness on the order of a millimeter - battery, chips, perhaps a capacitive sense switch - as a sealed single data-addressable unit, these can be placed anywhere on the wall or not on the wall. Want to hang a different picture but the switch is in the way? Just peel it off and move it over a bit. Gang several together for two-way, three-way, or completely customized behavior.

In my version here, the electronics are basically flat, and the switch is not, because it is just an inexpensive panel-mount momentary switch. I have mounted this switch inside the top cover of a water tank, with a Lexan shield in between to protect the electronics from any accidental moisture. 

This is the cover to the water tank of my coffeemaker.

Coffee maker

The function is to expose its state to my automatic water pump that fills the coffeemaker when the tank is low. This provides a manual “run the pump” signal, in case I want to fill it higher, or just purge the line. It occurs to me that since the switch unit is in the cover, I should put some electrodes there that hang downward, such that it creates a limit switch to prevent overfilling.

Currently the coffeemaker itself has a switch to detect the low-water condition, but nothing built in for too-much-water. Well, maybe I will get to that someday. This would effectively...

Read more »

  • 1 × Reactron (Arduino clone) with HopeRF radio based on Moteino, lowpowerlab.com
  • 1 × SPST momentary switch with blue LED any switch will do
  • 1 × Battery holder Sparkfun
  • 1 × Rechargeable battery Sparkfun
  • 1 × Lexan shield implementation dependent

View all 7 components

  • Potential superclassing

    Kenji Larsen06/27/2014 at 02:48 0 comments

    As I was writing the details up I couldn't help but think of my other flat and tiny node, which really is more of a human interface device.  It is almost the same as this switch setup without the switch, and with an OLED screen instead.  

    Small Integron

    I described it more in detail here.  It uses a LiPo instead of a button rechargeable, and has a JST connector for easy recharging The screen node doesn't last very long, hours compared to potentially years with the low-power programming of the switch node. Other than this, there are minor mechanical differences, like it lacks a programming header, though I did not have to add that to the switch setup, I just did that for convenience.

    This unit is location-aware and can re-purpose its displayed information dependent on its location.  I was thinking, I could use the exact same code in the switch units, which are not coded to be location aware, they are just functionally assigned.  I was further thinking that maybe the thing to do here is to merge the code, and specify whether or not there is a screen, or a switch, and whether or not it should be location-reassignable, or functionally assigned, or some combo.

    Maybe that is too complex.  The nodes themselves are so simple that it is almost worth it, to just maintain one codebase instead of two.  I'm not sure that I would ever want or need a location-reassigning switch though.  

    Now that I have said that, I will need one soon, I am sure.

View project log

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates