Tag Archive: Pulse


Thanks to ADH Heating Services I now have jeenodes counting pulses from my mains cold water supply:


Boiler hot water outlet:


And gas meter:


The pulses are being pulled into DomotiGa:

Which allows me to graph with RRDTool:

I also created my own module for DomotiGa to hook up to my custom 433Mhz RF receiving jeenode- I now have my window/door sensors (along with a bunch of rogue devices?) appearing:


I’m not best sure how to tackle the fact that the devices don’t issue an idle command when the alert has finished (i.e. when the door is closed or the fire is put out?). I’m considering trying out the built in DomotiGa feature to revert the values after 1minute or so (the smoke alarm should continue to send data whilst the alarm is being sounded so this shouldn’t be a problem).

I’m still troubleshooting a few problems- for example USB serial ports failing to open with error: "Cannot open serial port (#5)":

And some jeenodes going offline. Hopefully I will have more time to look into this later in the week.

L

More 433Mhz RF Hacking

I touched on the smoke detectors and door/window sensors I ordered last week: – here are a few more details.

The smoke detectors were £5.75 each – http://www.ebay.co.uk/itm/260990530306#ht_3800wt_1385 (all now sold out, but more available on a separate listing from the same seller – http://stores.ebay.co.uk/greatgougo)
The door/window sensors were £2.50 each – http://www.ebay.co.uk/itm/200759112077?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649#ht_500wt_1170 (shop link if/when the listing ends – http://stores.ebay.co.uk/HI-AYY-STORE)

The RF signals broadcast by both devices are not decoded by the RFXCom receiver/transceiver RFXtrx433. This meant finding a way to receive and decode myself.

I already had a few jeenodes (http://jeelabs.com/products/jeenode) knocking about and a 433Mhz plug (http://jeelabs.com/products/ook-433-plug) – there are many alternatives available. I fired up some sketches from the jeelib library (https://github.com/jcw/jeelib/) but wasn’t getting any output when triggering the door/window sensors or the smoke detectors;

I found a discussion on the jeelabs forum (http://forum.jeelabs.net/node/87) which led me to an application called ProtocolAnalyzer (http://wiki.nethome.nu/doku.php/analyzer/start). ProtocolAnalyzer describes a real simple circuit design which brings the RF signal voltage down to a safe voltage to pump into the microphone/line-in port:

I didn’t even have the right components so I improvised:

I only had a 4K7 variable resistor rather than fixed, and I think those fixed resistors are about 370 ohm so I doubled up. I didn’t have any capacitors, so I’ve omitted for the time being but that might be the reason I’m getting slightly inconsistent results as you will see later.

I fired up ProtocolAnalyzer and immediately started to see data coming in (without activating the sensors)- this suggested my CurrentCost devices and such were probably being heard. Many of the signals were being identified as conforming to the "Pronto" protocol, but the data wasn’t very helpful (nor was the way in which it was being displayed). To read the data you had to drill-down on each record. As I ultimately wanted to compare a large result set in an attempt to find patterns and work out which bits/bytes/words meant what this wasn’t really practical.

So I disabled all of the decoders and enabled just the raw signal capture:

I could now drill down and determine the pulse spec:

Which I could then use in an Arduino sketch to capture data. I used the ookRelay2 sketch and modified the Home Easy (HEZ) decoding function to decode my new devices:

class HezDecoder : public DecodeOOK {
public:
HezDecoder () {}
// see also http://homeeasyhacking.wikia.com/wiki/Home_Easy_Hacking_Wiki
virtual char decode (word width) {
if (400 <= width && width < 1600) {
gotBit(width <= 600);
return 0;
}
if (width >= 3000 && pos >= 5) {
for (byte i = 0; i < 6; ++i)
gotBit(0);
alignTail(64); // keep last 56 bits
return 1;
}
return -1;
}
};

As soon as I activated one of the sensors data started to flood in:

[ookRelay2]
HEZ 51 85 171 42 51 3
HEZ 166 106 85 101 102 32 51 85 171 42 51 3
HEZ 153 169 90 85 153 3
HEZ 51 85 171 42 51 3
HEZ 51 83 171 42 51 3
HEZ 51 85 171 42 51 3
HEZ 166 106 85 101 102 32 51 83 169 42 51 3
HEZ 51 85 171 42 51 3
HEZ 170 86 85 102 6 50 51 85 171 42 51 3
HEZ 51 85 171 42 51 3
HEZ 204 85 171 42 51 3
HEZ 51 83 181 170 50 3
HEZ 51 85 171 42 51 3

I’m not 100% sure of the reason for the receptions (I think some protocols rebroadcast multiple times to enable validation). Nor am I sure of the reason for the discrepancies (you can see most of the packets are HEZ 51 85 171 42 51 3 but a few contain different values).

I took the most common result and recorded it along with the jumper position (presumably indicating the home code):

I followed a methodical approach of moving the jumpers and recording the result- ending up with a pattern something like:

ABCD-EFGHIJ?? IJ GH EF AB CD
NNNN-NNNNNNNN HEZ 51 51 51 51 51 3
NNNL-NNNNNNNN HEZ 51 51 51 51 179 2
NNNH-NNNNNNNN HEZ 51 51 51 51 83 3
NNLN-NNNNNNNN HEZ 51 51 51 51 43 3
NNLL-NNNNNNNN HEZ 51 51 51 51 171 2
NNLH-NNNNNNNN HEZ 51 51 51 51 75 3
NNHN-NNNNNNNN HEZ 51 51 51 51 53 3
NNHL-NNNNNNNN HEZ 44 51 51 51 181 2
NNHH-NNNNNNNN HEZ 51 51 51 51 85 3
NLNN-NNNNNNNN HEZ 51 51 51 179 50 3
NHNN-NNNNNNNN HEZ 51 51 51 83 51 3
LNNN-NNNNNNNN HEZ 51 51 51 43 51 3
HNNN-NNNNNNNN HEZ 51 51 51 53 51 3
NNNN-NNNNNNNN HEZ 51 51 51 51 51 3
NNNN-NNNNNNNL HEZ 51 51 51 51 51 3
NNNN-NNNNNNNH HEZ 51 51 51 51 51 3
NNNN-NNNNNNLN HEZ 50 51 51 51 51 3
NNNN-NNNNNNHN HEZ 51 51 51 51 51 3
NNNN-NNNNNLNN HEZ 43 51 51 51 51 3
NNNN-NNNNNHNN HEZ 53 51 51 51 51 3
NNNN-NNNNHHNN HEZ 85 51 51 51 51 3
NNNN-NNNNLLNN HEZ 171 50 51 51 51 3
NNNN-NNNHNNNN HEZ 51 53 51 51 51 3
NNNN-NNHHNNNN HEZ 51 85 51 51 51 3
NNNN-NHNNNNNN HEZ 51 51 83 51 51 3
NNNN-HNNNNNNN HEZ 51 51 53 51 51 3

So I could see that the jumpers in pairs appeared to directly affect each byte of data being returned. I think built this table to demonstrate how I think they correlate:

DDDD-AAAAAAAA
3210-76543210
A0 = Not Used
A1 = Not Used
HEZ AA32 AA54 AA76 DD32 DD10
NN = 51
NL = 43
NH = 53
LN = 179
LL = 171
LH = 181
HN = 83
HL = 75
HH = 85

Next steps:

  • Configure each of the sensors with unique jumper configurations
  • Determine and position the sensors
  • Add the 433Mhz receiver to the jeenode connected to my raspberry pi (running DomotiGa) and modify the sketch to decode these signals as well as receiving 868Mhz broadcasts from other jeenodes
  • Tweak the DomotiGa code to interpret the received data

Home Automation Progress

An update since last week.

I decided I’d like to keep my CurrentCost netsmart pro posting electricity consumption data to pachube so spliced into the cable to see if I could pickup on the serial data using my home automation hub without disrupting communication between the enviR (CC128) and the bridge.

Taking the leftmost pin of the two connectors with the notch/clip facing downwards the pins are joined as so:

RJ45 -> RJ11
1 -> 1 (Yellow)
4 -> 2 (White)
7 -> 3 (Blue)
8 -> (White)

Rather annoying that they used white for 2 of the cores! On my USB serial cable for the enviR the pinout was as so:

RJ45
4 (Red) -> Spliced into White (pin2)
7 (Green) -> Spliced into Blue
8 (Yellow) -> Spliced into White (pin8)

After hooking the bridge, enviR and usb up to the laptop I could see data coming in over through the serial port- voila!

I punched the CurrentCost details into the hah web interface:

Then configured the extra data streams to pachube:

Just waiting for a few hours for some data but it appears to be flowing in nicely:

<eeml xmlns="http://www.eeml.org/xsd/005"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://www.eeml.org/xsd/005 http://www.eeml.org/xsd/005/005.xsd" version="5"><environment><data id="2"><tag>Light</tag><value>0.00</value></data><data id="3"><tag>Humidity</tag><value>0.00</value></data><data id="1"><tag>Temperature</tag><value>0.00</value></data><data id="13"><tag>CCIAM3</tag><value>44.00</value></data><data id="12"><tag>CCIAM2</tag><value>157.00</value></data><data id="11"><tag>CCIAM1</tag><value>5.00</value></data><data id="15"><tag>CCIAM5</tag><value>0.00</value></data><data id="14"><tag>CCIAM4</tag><value>82.00</value></data><data id="10"><tag>CCTotal</tag><value>415.00</value></data><data id="16"><tag>CCIAM6</tag><value>0.00</value></data></environment></eeml>

I took delivery of the two water meters today- just waiting for a friend to help me fit them and my additional jeenodes to arrives so I can get the data into the hah!

The crazy looking squid thing is the cheapest usb hub I could find to allow me to plug both the jeelink and currentcost enviR into the hah at the same time- hideous but does the job :)

L

%d bloggers like this: