Tag Archive: Decode


I think I may’ve just had that eureka moment!

As part of the almighty home automation project I have been seeking a mains plug/socket which both meters the power consumption of attached devices AND allows remote switching. I struggled to find anything that fit the bill (and was reasonably priced and/or "open") but ended up taking the plunge and buying a few AlertMe (aka IRIS) Smart Plugs (£25/each).

Knowing that the AlertMe products communicate using Zigbee, if I want them to talk to anything more than themselves I would need to do a little packet sniffing in an attempt to document the packet format.

I first found some software that looked up to the job: http://www.ubilogix.com/products/ubiqua Ubiqua by Ubilogix (although I’m just using the trial version, I doubt I can afford the hefty $999 license fee!) and then found a compatible USB dongle: http://uk.farnell.com/jsp/search/productdetail.jsp?SKU=1855261 Texas Instruments CC2531EMK Zigbee USB dongle (£46.68).

A few days later- everything’s delivered and I fire it up (I use a Mac with VirtualBox to run windows virtual machines. I couldn’t get the driver working in Windows 7, so settled for XP).

There is a ton of traffic and I have very little idea what any of it is!

My next thought was- maybe I can find figure out which device is which through the online portal / web interface (maybe the mac addresses will be listed). They weren’t directly, but clicking on "manage" and viewing the source they were there for the taking:

Ubiqua uses a short notation but you can easily find it:

So, what next? Well there is where I got a little stuck and found myself examining random packets and not really figuring anything out. Applying a filter to only see traffic from the current clamp / meter reader seemed sensible but I believe because the mesh like nature of the Zigbee protocol each message was being relayed by each device causing a lot of duplication. I removed the SmartPlugs, leaving just the hub and meter reader (the SmartPlugs have battery backup so I think it takes a while for them to stop transmitting, I held the power button which I think drained them quickly- the orange light was no longer appearing).

So now we’ve isolated some traffic we’re interested in from a lot of "noise"- but we’re still pretty clueless. Brainwave… let’s monitor a short period with normal consumption then a short period with high consumption (I put the oven on) then a short period with 0 consumption (I removed the current clamp from the mains cable). I made a note of the packet count in Ubiqua at each change so I could be sure to pick a packet from each of the phases.

The incoming packets still don’t seem consistent- so maybe there are more conversation taking place than simply "here’s my power consumption" but I found a fairly regular packet structure 116 bytes in length and decided to filter my packets to just those. I then took the ZCL payload data from one of the "normal", "high" and "zero" samples:

Normal:
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

01 DC 01 DC 01 DC 01 DD 01 DB 01 DD 01 DD 01 DD 01 DD 01 DA 01 DC 01 D4 01 D2 01 D5 01 D2

00 03 A8 FA

High Use:
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

0E EE 0E FA 0E F4 0E F9 0E F7 0E F9 0E FB 0E FC 0F 13 0E E3 0E E9 0E E7 0E EA 0E 36 0B 33

00 03 A9 27

Zero Use:
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 03 A9 AE

You can see I chopped the payload into three logical sections. Now my hex isn’t great, but I could quickly see 2 hex digits (8 bits or 1 byte) didn’t really mean anything but when paired and converted to decimal the numbers started to look very much like my estimated power consumption (repeated a number of times- at a guess there are 15 samples in each packet?). Taking the first reading from each packet you end up with:

01 DC = 476 W
0E EE = 3822 W
00 00 = 0 W

Whilst this seemed very likely I wanted to try and confirm the value… So I did another capture and checked the "power now" value on the portal- bingo, spot on!

I still have a lot of work to do to try and determine:

  • What the other packets are?
  • How to decode the consumption packets from the SmartPlugs?
  • How to decode the on/off switching instructions to the SmartPlugs?

And then potentially attempt to build a little arduino circuit / sketch to facilitate communication. Meanwhile I will no doubt be having a poke around inside the devices :)

I didn’t previously mention that the Zigbee packets are actually encrypted- I’m not quite sure where it came from but there was already a key in Ubiqua which was able to successfully decrypt the AlertMe / IRIS packets: AD:38:19:32:6F:D5:C8:F9:F2:8D:78:F0:82:66:AE:57 – I don’t know if this is unique to my devices or the same for everyone.

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

I wrote another little shell script / python script to pull the status & current playing track name:

import xml.etree.cElementTree as XML import requests endpoint = '/MediaRenderer/AVTransport/Control' action = '"urn:schemas-upnp-org:service:AVTransport:1#GetTransportInfo"' body = '<u:GetTransportInfo xmlns:u="urn:schemas-upnp-org:service:AVTransport:1"><InstanceID>0</InstanceID><Channel>Master</Channel></u:GetTransportInfo>' headers = { 'Content-Type': 'text/xml', 'SOAPACTION': action } soap = '<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body>' + body + '</s:Body></s:Envelope>' r = requests.post('http://192.168.0.218:1400' + endpoint, data=soap, headers=headers) dom = XML.fromstring(r.content) print dom.findtext('.//CurrentTransportState') action = '"urn:schemas-upnp-org:service:AVTransport:1#GetPositionInfo"' body = '<u:GetPositionInfo xmlns:u="urn:schemas-upnp-org:service:AVTransport:1"><InstanceID>0</InstanceID><Channel>Master</Channel></u:GetPositionInfo>' headers = { 'Content-Type': 'text/xml', 'SOAPACTION': action } soap = '<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body>' + body + '</s:Body></s:Envelope>' r = requests.post('http://192.168.0.218:1400' + endpoint, data=soap, headers=headers) dom = XML.fromstring(r.content) track = {} import re print re.search('<dc:title>(.*)</dc:title>', dom.findtext('.//TrackMetaData'), re.IGNORECASE).group(1)

See:

I also got lighttpd & php5 up and running on my raspberry pi running domotiga so I can access the web interface:

Now I’m trying to get the 433Mhz door/window sensors connected but first I need to work out how to decode the rf packets. I tapped into my jeelabs 433Mhz ook plug and built a circuit similar to that described here: http://wiki.nethome.nu/doku.php/analyzer/hardware

I didn’t have all the right bits handy but it worked regardless!

After doing some captures in Protcol Analyzer I think I have determined the pulse width to be around 1500μs:

But I’m still at a bit of a loss how to then decode (I’m hoping I can somehow separate each "data packet" then compare packets origination from two different sensors) then work out which bit relates to the "house code" etc

Here’s a sample of the hex data:

Door Sensor #1

0000 0067 0000 0019 0017 003b 0040 0012 0040 0012 0040 0012 0017 003b 0040 0012 0017 003b 0016 003b 0017 003b 0040 0012 0040 0012 0040 0013 0016 003b 0040 0012 0017 003b 0040 0012 0016 003c 003f 0013 0016 003b 0040 0013 003f 0013 003f 0013 0016 003c 0016 003b 0016 0279

0000 0067 0000 0019 0016 003b 0040 0012 0040 0011 0040 0012 0017 003a 0040 0011 0018 003a 0016 003b 0018 003a 0040 0011 0040 0013 0040 0011 0018 003a 0040 0012 0016 003c 003f 0013 0016 003b 0040 0012 0016 003c 003f 0012 0040 0013 003f 0013 0016 003c 0016 003b 0016 0279

0000 0067 0000 0019 0018 0039 0041 0010 0040 0011 0040 0011 0018 003a 0040 0010 001a 0038 0019 0038 001a 0037 0042 000f 0040 0012 0040 0012 0017 003a 0040 0011 0017 003b 0040 0012 0017 003a 0040 0012 0017 003a 0040 0011 0040 0012 0040 0012 0017 003b 0016 003b 0017 0277

Door Sensor #2

0000 0067 0000 0019 0016 0038 003b 0010 0016 0039 0016 0038 0016 0038 003a 0011 0016 0039 0016 0038 0016 0038 003a 0011 003a 0011 003a 0011 0016 0038 003a 0011 0016 0039 0039 0011 0016 0039 0039 0012 0015 0039 0039 0012 0039 0012 0039 0012 0015 0039 0015 0039 0016 0265

0000 0067 0000 0019 0016 0038 003a 0011 0016 0038 0016 0038 0016 0039 003a 0010 0016 0039 0016 0038 0016 0038 003a 0011 003a 0011 003a 0011 0016 0038 003a 0011 0016 0038 003a 0011 0016 0039 0039 0012 0015 0039 0039 0012 0039 0012 0039 0011 0016 0039 0015 0039 0015 0266

0000 0067 0000 0019 0016 0038 003a 0011 0016 0038 0016 0038 0016 0039 003a 0011 0015 0039 0016 0038 0016 0039 0039 0011 003a 0011 003a 0011 0016 0039 0039 0011 0016 0039 0039 0012 0015 0039 0039 0012 0015 0039 0039 0012 0039 0012 0039 0012 0015 0039 0015 0039 0016 0265

L

%d bloggers like this: