In the past I’ve written several blog posts about how to use Arduino to interface with remote power sockets. For home automation involving powerline devices (e.g. lights, heaters, pumps, fans), this is my favorite solution, because it’s low-cost (remote power sockets are widely available at cheap price) and convenient (no messing around with relays and powerline wires). Also, one Arduino plus transmitter can simultaneously talk to many power sockets, making this a scalable solution too.
With the just released OpenSprinkler firmware 2.1.1, support for interfacing with remote power sockets has finally arrived. So you can now use OpenSprinkler not only to control sprinkler valves, but also powerline devices. Trying to find a programmable way to control your Christmas lights? Look no further! With OpenSprinkler’s easy-to-use web interface and flexible programming capability, you can enable automated control of lights, heaters, pumps, fans — anything that can be plugged into wall outlets.
Here is a quick video tour on how to get started:
Below are detailed instructions.
Required Parts:
- OpenSprinkler 2.0, 2.1, 2.2 or above.
- 433MHz Radio Frequency (RF) transmitter-receiver pair.
- RFToy.
- One or more remote power sockets, preferably those with separate on/off buttons.
How does this work?
Let me briefly explain how the whole thing works. First, common remote power sockets operate in the 433MHz radio frequency band. When you press a button on the remote, it sends out a signal to the power socket, which gets decoded and acted upon. If we can sniff the signal, we can use a microcontroller plus a 433MHz transmitter to replicate the signal, thus be able to directly control the power socket in software. The RFToy is a gadget that I’ve designed to easily decode signals from common remote power sockets. Once we have the code, we can use OpenSprinkler to simulate the code, thus be able to control remote devices.
Heads-up: the following steps require a small amount of soldering. The estimate time for modification is 15 to 20 minutes.
Step 1: Decode Remote Power Sockets
Take out the RFToy, plug in a 433MHz receiver (making sure the VCC and GND pins on the receiver match the +5V and GND pins on the RFToy). Follow the on-screen instructions to record the on/off signal of a power socket. Once decoded, the signal will be converted to a 16-character hexademical code.
To test if the code works, take out the 433MHz transmitter, and solder a 17cm (6.7inch) long wire antenna to the ANT pin. Then plug it into the RFToy (making sure the DATA and GND pins on the transmitter match the DATA and GND pins on the RFToy). Bend the pins as necessary. Now click button S3 or S1 on the RFToy, the power socket should be toggle on or off just like when you press the buttons on the remote. Keep in mind that although most remote power sockets work in the 433MHz band, there are some that work in the 315MHz band. In that case, just use a 315MHz transmitter-receiver pair.
Step 2: Install RF Transmitter to OpenSprinkler
Remove the OpenSprinkler enclosure, and locate the RF transmitter pinouts (marked A3 VIN GND). The pinouts are located either close to the top of the PCB, or next to the Ethernet jack. Plug in the transmitter to the pinouts, making sure the DATA-VCC-GND pins on the transmitter match the A3-VIN-GND pins on the circuit board. Then solder the three pins at the back of the circuit board, and clip as necessary. Carefully arrange the wire antenna around the LCD and re-install the enclosure.
It’s important to use a wire antenna of sufficient length, otherwise the transmission range will be severely limited.
Step 3: Final Testing
Make sure your OpenSprinkler is running firmware 2.1.1 or above. If not, please follow the firmware instructions to upgrade your firmware first. Then go to Edit Stations, select the station you’d like to use as an RF station, and change its name to the 16-character hexademical code recorded on the RFToy. Any station with a name of this form will be automatically recognized as an RF station. When the station is turned on, the controller will automatically send out the signal through the installed RF transmitter, thus turning on the corresponding power socket (and vice versa for turning off the station).
Three quick notes:
- The normal station function still works (i.e. if there is a sprinkler valve connected to that station, it will be switched on/off accordingly).
- Most likely you want to turn off the ‘sequential’ flag for RF stations. This is because unlike sprinkler stations, you probably don’t want RF stations to be serialized with other stations.
- If you are short of stations, just increase the number of expansion boards. You don’t need to have the physical expansion boards (think of RF stations as virtual sprinkler valves). Firmware 2.1.1 supports up to 48 stations in total.
With this feature, you can now use OpenSprinkler to programmably switch a large number of powerline devices, such as Christmas lights, landscape lights, water pumps, heaters, fans.
Keep in mind that because this is still an experimental feature, don’t use it on anything critical (i.e. those that can cause damages if accidentally left on). Depending on the distance and obstacles between OpenSprinkler and remote power sockets, it might not reliably switch on/off power sockets. So take time to do plenty of testing before you finalize the setup.
That’s it. We encourage you to try out firmware 2.1.1 and let us know your comments / suggestions / feedback. Don’t forget to post pictures of your projects. We would greatly appreciate your efforts. Thanks!
Any possibility for a solution for osbo also?
Similar to the other comment, is it possible for this to be adapted to the OSPi? Dan-in-CA would have to adapt your C++ code to python in order to send the RF signal based on the “sniffed” RF code correct?
Theoretically it can, however, OSPi currently doesn’t have built-in space for RF transmitter, so you will need to solder wires and connect a transmitter yourself. Also, the python program has to be modified to add this functionality. My concern is that because python isn’t very accurate in terms of timing, it may not work because the signal requires pretty accurate timing (down to a tends of microseconds). On the plus side, I am working on porting the Arduino-based OpenSprinkler code to C++ on RPi. I am quite close to be done. Once this is finished, OSPi can run exactly the same code as the Arduino-based OpenSprinkler, so all the features will be completely compatible (however, you will lose the flexibility of python because to make the program maximally compatible between Arduino and RPi it will have to be written in C++).
Hi Ray, I have just purchased OpenSprinkler DC with RFToy and a few other components but I am having an issue controlling my remote power switches.
App Version 1.4.6
Firmware 2.1.5(1)
Hardware 2.3 (DC)
I am using standard RF switches (Status RCS-K09) and the remotes have separate on/off buttons for each of 4 channels.
Using RFToy I can record each of the 4 channels as follows:
FE835 F FE835 7 012C
FE835 B FE835 3 012C
FE835 D FE835 5 012C
FE835 E FE835 6 012C
Then I name the OpenSprinkler stations accordingly but the switches don’t operate. So using RFToy I sniff what is being output by OpenSprinkler as the following:
FE835 F FE835 7 001E
FE835 B FE835 3 001E
FE835 D FE835 5 001E
FE835 E FE835 6 001E
So it seems the signal timing is not being replicated properly.
Is this part of the code supposed to be replicated, or is it just fixed to a common value that my switches don’t happen to use, and I would therefore need to modify the firmware to adjust it?
Many thanks, Brett.
But when trying to cntrol my remote power switches
Ok looking into this a little more and varying the values supplied in the station name I can see that in every case OpenSprinkler is actually reducing the signal timing to exactly 75% of that supplied. I’m not sure how this value is used, but I’m guessing this might perhaps be to allow for delays in processing or something. For example 012C becomes 00E1, 0100 becomes 00C0, and 00F0 becomes 00B4.
However this does seem a little odd, firstly to apply a percentage rather than deduct a fixed known value, and secondly to presumably output a different signal timing code to that actually being effectively emitted. So I’m quietly hoping it’s just a bug.
My next step will be to desolder the transmitter from OpenSprinkler and try it in the RFToy hoping this will then send out the code unaltered and my switches will jump to life (should have done this to start with).
But I will wait for your response before doing so, as I soldered it on both sides of the pcb and have lost my desoldering gun!
The 75% is a scaling factor in the firmware code, it’s pre-calibrated to account for the processing overhead of the microcontroller. Specifically, when you tell it to send a signal of 100 us, the internal processing overhead ended up adding some more, say, 25 us. Therefore it ends up sending a signal of 125 us. Therefore the 75% is used to so that it sends a signal of 75 us, and adding the 25 us overhead, it becomes 100 us in the end.
But likely the scaling factor is too aggressive. In that case you can modify the last four digits to counter-act the scaling. For example, you can change the last four digits to 0x190, that way, after scaling by 75% it will become 0x12C, which is the correct timing value.
Yup that was it, works perfectly! I think I should try find the upper and lower limits then choose a value in the middle, however 0x190 seems very reliable actually.
Ok I tested 4 RF switches (all Status RCS-K09) and found reliable max and min values to be 0x163 and 0x38B. So I simply now use a mid point of 0x277.
A few mod request for the pot mostly related to RF control…
1) Provide specific parameter for RF code rather than use station name.
2) Provide parameter to scale RF timing signal. Ideally per station (to support different RF switches in one system).
3) Add simple on off buttons to the manual control rather than duration only (thought I noticed this in some demos).
4) Allow the Additional Start Times repeat frequency to be set in seconds. Would be very useful for testing, demos, and driving things like light and fountain displays.
BTW a couple of notes on build quality you might like to know about… The jumper under the LCD on my OpenSprinkler DC had not been bent over out the way properly, resulting in it being forced against a surface mount component on the board and twisting such that the jumper itself had broken. Easily resolved but worth mentioning. Switch 3 on my RFToy is faulty, I often have to press it 10 times to get a response, which means the press and hold becomes infuriatingly difficult to achieve. I wonder if you could send me a spare switch or simply point me to a source in the UK for the component?
Many thanks for your help, Brett
1) This has already been incorporated in the upcoming firmware 2.1.6.
2) I am not sure: the timing value is part of the RF code, providing additional scaling just adds more variables and can cause confusion to users and complicate UI design.
3) We made the conscious decision to make the timer value for manual control mandatory — this is to prevent users from unintentionally leaving the station on forever and forget to turn it off.
4) Start times are always in granularity of minutes. Changing it to seconds is not possible for the near future.
Regarding the LCD header: can you take a picture to show which SMD components is it forcing against? That area of the circuit board should be clear of components by design, so I am surprised the LCD header is forced against any component. Regarding RFtoys: all RFtoys have been tested, including tests on buttons. But I agree that it’s possible a button or two may be less reliable than others. This is the standard 6mm x 6mm tactile button, such as this one:
http://uk.farnell.com/multicomp/mc32829/switch-tactile-spst-50ma-through/dp/1712952
Thanks for the link.
1) Great.
2) Understood, but it’s more complicated for users to adjust the signal timing portion of the RF code, than adjust a simple percentage.
3) I suspected as much, but it’s just too restrictive to not allow simple on/off switches. Perhaps you could allow it for RF only. Or perhaps just implement a global safety switch/duration to apply the restriction by default.
4) Understood, I can however see a large market in controlling those dancing water fountain/jet displays with coloured lights.
Ok perhaps I should simply start tinkering with the code myself, but I don’t really want to have to repeat changes in each new release, one neat solution might be to implement such restrictions/features as compile time options.
I have taken a pic of the jumper should I send it to you via email?
Hi Ray, just updated my Opensprinkler DC with latest firmware 2.1.6 this afternoon and I’m getting some very odd behaviour. It looks like the unit is turning off all RF switches on a 45 second cycle? After testing I can confirm no programs running at all, and I can even disable the RF stations, but every 45 seconds the unit sends out an Off signal to each of my RF stations. I only noticed the behaviour this evening when I manually switched on my lights etc via the remote control, and the only way I can stop it from turning off what I manually turn on is to unplug the units power. Is this something that makes any sense to you?
Yes, it’s repeatedly sending signals to RF stations to make sure they are in sync. The repeat cycle is about 48 seconds. This is to make sure that the status on the controller matches the actual status of the station. If you want to manually switch on / off your lights, ideally you should use your OpenSprinkler to do so, instead of using a separate remote control.
On a related matter I was wondering what changes were made to the RF signal timing and if I should perhaps adjust my signal timing values back to ensure they are still mid range. In other words if you changed the 75% then I probably need to adjust my timing values accordingly.
The timing issues have been fixed in firmware 2.1.6. Specifically, it turns out that the 75% scaling is not necessary at all. So firmware 2.1.6 has removed that scaling.
Ok so had another read of 2.1.6 release notes and found mention of the periodic re-sending of RF signals to keep them in sync with the controller. I understand the reasoning but feel it is just not practical to assume opensprinkler is the only thing controlling them, and that users will not want or need to manually control their RF switches with their existing remote controls. In effect this feature has now rendered the remote controls useless. Especially when you consider there is no longer a simple on/off switch for stations (only duration). Therefore may I request the ability to enable/disable this sync feature in the next release, perhaps a sync attribute per station or something? Many thanks, Brett.
Well, to say ‘this feature has now rendered the remote controls useless’ is a bit harsh. Keeping the remote/RF stations in sync with the controller is particularly requested by some users. For example, if the controller is saying the RF station is on, but the station is actually off, that would cause issues and confusion. Because RF stations do not have feedback (the communication is one way), it’s important to repeatedly send the signal to make sure they are in sync. If you need to switch the RF station manually, can’t you just use OpenSprinkler to do so (instead of use a separate remote control)?
Well that’s my point really, if I can only use Opensprinkler to control my switches then the remotes have been made redundant. I understand the need for the sync in certain applications due to no feedback, I just suggest it should be a feature that can be enabled/disabled because some people (like me) still wish to use their remotes to control the switches manually. Actually I find Opensprinkler controls my switches very reliably, so the sync feature doesn’t add anything for me, it just means I can’t use my remotes. Personally I want to use opensprinkler to add scheduling and sensors to my RF switches, but I don’t want it to take absolute exclusive control of them. For example I may have a light which I wish to come on and off through the night on a schedule as a deterrent to burglars, I might also want it to come on during the night when a sensor detects someone is outside, but importantly I still want to be able to quickly switch it on/off as desired during the evening while sat in that room. Similarly I may have a heater that I want to come on when a sensor detects a drop below a certain temperature, perhaps for frost or damp protection, but I still want to override this when sat in that room/garage/shed. Now if I switch my light or heater on using my remote, Opensprinkler simply turns it off within 45 seconds, and if I turn my light or heater off using the remote, Opensprinkler turns it back on within 45 seconds (which might become dangerous in some situations). So instead of simply clicking a button on my remote I have to get my smartphone (or laptop if not using one) launch the interface, find the station, program a duration, and click submit (and that’s assuming my wifi is not playing up). Now if there was a simple on/off switch per station, as there used to be, it would help, but to be honest even then it would still be easier to use the remote. Frustratingly even if I choose to disable the station Opensprinkler still maintains the sync, I have resorted to changing a digit in the RF code to temporarily disable this syncing. Don’t get me wrong I think Opensprinkler is great, but if I could just disable some of these safety features I would consider it fantastic. However I acknowledge it’s probably exactly as required for controlling only sprinklers. All I ask is that you consider adding a sync enable/disable switch, ideally per station, in a future release.
Well we can consider adding the support to disable sync in the future. At the moment if you absolutely need this feature, the easiest way is to modify the firmware yourself, by simply commenting out this line:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/OpenSprinkler.cpp#L705
Agree with Brett. I don’t want opensprinkler taking exclusive control of my RF stations. I will compile the code and comment out that line. But would be great if there was a field in the GUI to allow this in the future.
Also, The video is now out of date, with newer firmwares. You don’t name the station the code anymore. Can name it anything you want. Then change the type to RF and then enter the code. Took me some time troubleshooting to work that out. I re-did the solder, thinking I must of soldered wrong, before I checked out the GUI in more detail and found the new options.
Very happy customer here. Loving open sprinkler and ability to control RF stations.
Thankyou
That’s great, thanks for the pointer, just the excuse I need to have a play.
I got the remote power socket working, no problems there.
The only glaring omission for using this as a light controller is that I can’t see how to set a definite “Off” time (eg. I want the light to come on at local sunset, and turn off at 11:00pm)… there is only “duration”.
The firmware currently does not support an ‘end’ time. You can only set a start time, and duration (and duration can be from sunset to sunrise). In the next firmware we will consider adding support to define an end time.
Great Stuff Ray!!
I went through the fun of decoding my RF timings based on your article here: http://rayshobby.net/interface-with-remote-power-sockets-final-version/
Can you describe how to convert those timings into the 16 digit code used in opensprinkler?
For example, using your method, I successfully decoded a single outlet from a 3 outlet set:
1010 0010 0100 0000 0000000
0110 0010 0100 0000 0000000
Where:
1=1250us on, followed by 395us off followed by 395us on followed by 1250us off
and
0=395us on followed by 1250us off.
I know the first quad represent the command (on/off), the 2nd quad represent the “channel” and the 3rd quad represent the “socket id”. With the Stanley’s, the Channel # is always the same within a set, and the on/off commands are the same with only the 3rd quad changing. But you already know that.
So, what’s the formula?
If I remember it correctly, the 16 digit code consists of 6 digits for on signal, 6 for off, and 4 for timing. They are all hexidecimal representations. You can use any binary to hex converter, for example:
http://www.binaryhexconverter.com/binary-to-hex-converter
In your case, your on signal seems to be only 23 bits long, which is a bit strange as it should be 24 bits. I assume there is a missing 0 at the end? If so, it translates to A24000, and similarly your off signal translates to 624000. The timing is 395 in decimal (the shorter pulse length), so that’s 018B in hex. Together the 16-digit code should be:
A24000624000018B
I hope this works. The missing ending 0 is my guess, so it might not be correct. You should check the signal again.
Hi Again,
I rechecked my signal – I was missing some data – actually, I had too much data which I presumed was noise…. I found out that my problem is that my remotes use 26 bit signalling. I decoded using Arduino RCSwitch library as follows:
ON
1001 0000 1000 10000000000000 = 2422000
Decimal: 37888000 (26Bit) Binary: 10010000100010000000000000 Tri-State: not applicable PulseLength: 436 microseconds Protocol: 1
Raw data: 13540,1244,484,384,1312,388,1308,1248,484,384,1316,384,1320,376,1328,368,1320,1240,492,372,1316,388,1312,384,1316,1244,492,376,1320,380,1312,384,1312,384,1316,384,1312,384,1312,384,1320,384,1316,380,1320,376,1316,384,1312,384,1312,388,1324,
OFF
0101 0000 1000 10000000000000 =1422000
Decimal: 21106688 (26Bit) Binary: 01010000100001000000000000 Tri-State: not applicable PulseLength: 436 microseconds Protocol: 1
Raw data: 13540,380,1308,1248,476,388,1316,1240,488,380,1316,380,1316,376,1328,372,1308,1244,484,384,1312,388,1316,376,1316,384,1312,1240,484,380,1316,384,1312,384,1312,388,1312,384,1320,376,1320,376,1324,28,1316,380,1312,388,1316,380,1312,384,1332,
So my code would end up being:
24220001422000018B
(18 bytes – not 16 which is expected by OS)
Not that I thought it would work, but I plugged that into OpenSprinkler and it didn’t even send a signal 🙂 Any chance of getting variable bits (or in this case bit) remotes working?