One more decoder, a home automation protocol this time – a X10 RF transmitter:
That’s a Marmitek SS13, sending out over 433 Mhz (European model).
This is a fairly simple protocol (documented here), although synchronization and packet detection works a bittle differently from the other decoders so far:
Sample output:
Easy!
I’ve added support for controlling X10 devices via the CTX15 module described in the past two days:
First thing was to extend the ookRemote GUI, by adding these definitions to ookRemote.tcl:
With this change, the configuration section in “config.txt” supports CTX15 buttons:
These new buttons will send X10 commands to the CTX15 module. But this needs a bit of wrapping to turn them into frames, including the proper checksums. So I added two methods to “sketches/ctx15try/host.tcl”:
The “send” method overrides the existing one and sets up a frame before calling the original method with it.
That’s it. I can now make the Marmitek AM12 switch “clunk” with my mouse – audible feedback! :)
Now that the CTX15 has been connected via a JeeNode, it’s fairly straightforward to tie it into JeeMon.
First I created a new folder called “sketches/ctx15try/” with a file “host.tcl” in it, using this code as quick test:
The reason there is nothing more, is that I changed the ctx15try.pde sketch a little to return lines starting with “CTX15” – since these are the easiest to tie into JeeMon. The change affects these lines in yesterday’s demo:
I’ve also wrapped the received frame in {}’s, because that simplifies processing in JeeMon (Tcl interprets $’s and []’s unless escaped).
To activate everything, I added an extra line to the config.txt configuration file, so that the output from the JeeNode USB (serial# A900adwo) automatically gets picked up as sketch:
Here is an example of the above code running:
Good. CTX15 events are coming in. They are easily recognizable as (unit#, command) pairs.
But as you can see, these pairs don’t always arrive in the same frame. So we have to add a bit of logic to get things right. Here’s an updated version of host.tcl:
The solution used above is as follows: if it looks like a unit code (A..P + 1..16), then save that as last one seen. If it’s anything else, use the last saved location. I’m not sure this covers all possible scenarios, but for this very simple test it seems to work. Here’s a screen shot of the real-time status window:
As you can see, the CTX15 event was turned into an “AOFF” command for the “ctx_A01” device, which was created on-the-fly by this code.
Hmm, looking further, I think the “A” prefix needs to be stripped from “AOFF”. Oh well, it’s all scripted, I’ll adjust that when I get to using this stuff for real.
So that’s it. A few dozen lines of C code in the JeeNode to act as pass-through and do the polling, and a few dozen lines of Tcl code to tell JeeMon how to interpret the incoming data. Now we get notifications whenever any X10 activity is detected on the mains power line.
Onwards!
Another popular home automation module is the Xanura CTX15:
That’s a live 220V power-line connection in the top right corner!
I’ve connected the CTX15 module through a UART Plug, with a 4.7 kΩ resistor in series with the RX signal (yellow from CTX15). This is because the signal swings up to 5V, whereas the UART plug only accepts 3.3V voltage levels. The module is powered from the PWR pin, which on a JeeNode USB carries 5V.
The CTX15 is a bi-directional interface, it can send as well as receive A10-type power-line commands (a superset of X10). The trouble is that it needs to be polled to read out what has been received and buffered so far.
Here’s a sketch which takes care of that:
And here’s some sample output:
As a test, I powered up yesterday’s XM10E test setup as well, to send out on and off commands to unit A.1 every 3 seconds. As you can see with the CTX being read out every 5 seconds, multiple received packets will sometimes be combined and returned as one reply.
Let’s go some more into home automation – the X10 power-line system in this case.
Here’s is a sketch which turns a remote appliance on and off every 3 seconds:
I used the Arduino X10 library (had to mess around with the use of headers to get rid of compile errors, and enable the pull-up on the zero-crossing input).
This sketch runs @ 3.3V on a JeeNode with some stuff attached to port 1:
It’s just a simple re-wiring to an RJ11 connector. This in turn, plugs into the XM10E opto-isolated interface:
There’s also a X10 receiver built into the XM10E, which I’m going to ignore for now.
X10, in its simplest and oldest form, is a power-line transmission system, i.e. the signals to control a switch are sent over the same wires as the AC power itself (using a 120 KHz signal injected at the zero crossings). Proper mains isolation is essential, of course – as built into the XM10E unit.
The result is that you can plug this device into any outlet in the house and it’ll switch on and off as defined in the above sketch:
It’s hard to miss – the relay built into that thing switches on and off with a very loud “clunk”!
The power consumption of this switch is 0.6 W off and 0.9 W when on, according to the Cost Control. Not bad, until you start installing many dozens of these switches around the house … then it will add up!