A few days ago, as I was in a nearby DIY store (looking for something I didn't find in the end), I came by the Electricity aisle and noticed cheap remote sockets. These are a not new thing, I owned some more than 25 years ago — so unstable there were switching on and off randomly — and in France at least, the Belgian company Chacon made a successful product (DI.O) with this kind if items.
One of the major issue with them is that they are without any feedback of the status like you could have on a modern "smart plug". Yet, where a Z-wave socket alone is at least 40€, here a pack of 2 sockets was less than 15€ including the remote and its battery. The "manual" includes a EC Declation of Confirmity so I assume there are safe to use. The power is limited to 1000W but for Christmas lights, this is not an issue!
Obviously, the idea was also the do the reverse engineering on the protocol and if possible try to emulate the remote itself like I did several times in the past. Turns out that this very model of remote is used in dozens of packs and the circuit inside is well known and even officially documented!
Protocol and Home Automation
A quick search show pages and pages on the subject. These one are now called "Smart Home" but were previously sold under the Phenix brand by IDK. Protocol seems virtually identical to the Elro Home Easy plugs.
The next question was: What is the best to integrate these elements in the existing installation? There are two main parts for this: controlling the sockets but also making the most of the remote (especially the two unused ON/OFF buttons).
As described last year, I own a La Crosse Weather Station to which I added several additional (TX2 & TX3) sensors.
Trouble is, as the technology is phased out in favor of a 868Mhz based one, these sensors are harder to come by and are also a bit pricey.
Chance
Unexpectedly, I noticed a news about a firmware update of the RFXtrx433E from RFXCom talking about a well known chinese online shop's version of a sensor. Indeed, I was able to become the owner of a "433MHz Wireless Weather Station Digital Thermometer Humidity Sensor" for the very lucky price of US$8.88 all included.
Protocol
These sensors are apparently compatible with the Alecto WS1700 ones. The protocol was decoded and published on the Pilight wiki and forums.
It looked simple enough so I decided to modify my Arduino/Digispark script in order to decode it as well.
Pulses
Yet there was a catch! La Crosse TX3 protocol uses a variation of pulses on the high level with timing on the low level being almost identical (and ignored by my decoder's implementation).
For the WS1700... it's the opposite! Hence only a succession of 37 identical 500µS pulses was the only thing seen.
Also, the signal finishes by a "very long" (~9200µS) Low and, as usual with this kind of device, the whole sequence is repeated several times.
If we detect at least 8 continous short high pulses, then we know it's not a TX3 sensor but probably a Alecto compatible one and therefore from now on only low pulses will be read.
The strategy is then to wait for very long pulse, read the full signal, checking the header (~1900µS ~3800µS ~1900µS ~3800µS), and at last validating with the last pulse which should be again a very long one.
The new algorithm is represented in the following flowchart:
Reporting
The Id, which is randomly generated when inserting new batteries -- same as TX3 -- is ignored... I will assume that nobody else has a compatible sensors around and use the channel number instead.
Channel (there is a physical switch to select it) is coded 00=CH1, 01=CH2, 02=CH3. This will be my sensor ID because it is fixed. But to avoid any clash, I add 1001 so CH1=1001, CH2=1002, CH3=1003.
Battery will be reported as OK or KO.
There is a small button at the back of the sensor to force the emission. Apart for tests, it is not that useful and we can ignore the bit reporting this.
Temperature is in 10th of degrees Celcius so value is divided by 10. Negative values are taken care of as well.
Humidity is straight out the signal received except if not read properly (0%).
Quite happy with the results from the current setup, I decided to complete my collection of sensors with a WSTX3-TH to put on the front balcony.
As a free bonus, since I moved to the final version (from prototype breadboard to a PCB one with all the necessary pins properly grounded), I seem to receive the signal from a neighbouring sensor as well. With 3 temperature readings from outdoors, I think I'm covered for the winter!
As I said before, I found this one on ebay for 1 € (inc. postage)!
But it is not specially noted for its quality of reception and output signal is very noisy.
On my right: RXB6
I decided to break the piggy (hum!) and ordered a RXB6 module which has a far better reputation. Cost from China is $5 (inc. pp). Obviously it took 3 weeks to arrive but finally, I was able to try it on the Arduino.
Surprise! It didn't work at all. Nothing, no signal on the PIN 13.
After a while, and really thinking I got a duff one, I hooked it on the Digispark and... miracle!
Performances
But if I had some readings, it occured to me that something must be wrong as TX sensors are quite chatty (a repeted signal every minute or so) and I had only 20 values for a whole evening.
Something was definitely amiss. OK pulseIn is not necessarily the best method ever but since the microcontroller is not doing anything else, this should not be a problem.
While decoding, I ignore the LOW part of the signal (the 1000μS gap) but still...
After a lot of trial and error, I finally understood where the lock was: A tiny little bug!
The Bug
The first loop validate the preamble by checking the value is 10d (00001010b) but the variable was defined by int so depending on the preceding bits it could have held a different (higher) value despite a correct preamble.
To correct this behaviour I could either do a AND 255 with the value but I simply defined by variable by 8-bit byte type.
I also changed the boundary timings to be less restrictive.
Pin 13
Reading about different receivers, it seems that the RXB familly (at least) doesn't cope well with pull-ups. Since the pin 13 of the Arduino has a LED, this might be the reason why it didn't work when I first tried it. It works fine on any other pin...
Additional items
Adding an external antenna to the RXB6 doesn't seem to make much difference but when hooked on the digispark, a decoupling capacitor (100nF) seems mandatory for the RF receiver!
And the winner is...
RXB6 module is definitely better, especially with the outdoor sensor, but it also uses twice as much power (6.7mA vs 3.8mA). And the XY-MK-5V has an unbeatable value for money.
