Project

General

Profile

Reverse Engineering Zigbee Communication (AlertMe / IRIS)

Added by ltickett about 6 years ago

I’m curious whether anyone has attempted to "reverse engineer’ zigbee communication?

I have just discovered the AlertMe products, specifically the SmartPlug (just what i’ve been looking for). While they work nicely and have quite a nice web interface etc, I would like to integrate them into my unified home automation software.

I picked up the TI USB Zigbee device and have had a play with Ubiqua Protocol Anaylzer:

It appears to’ve sniffed the network key and decrypted the packets successfully but I’m not quite sure what my next step is (i.e. how to actually decode the payload data into consumption and switch on/off instructions).

I have had a pretty good google but not really come up with much (plenty about the initial sniffing, but nothing about what’s next…

L


Replies (66)

RE: Reverse Engineering Zigbee Communication (AlertMe / IRIS) - Added by ltickett about 6 years ago

I think I may’ve cracked it- just working on a blog post :)

RE: Reverse Engineering Zigbee Communication (AlertMe / IRIS) - Added by CapnBry about 6 years ago

Have you done any more work on this? I’ve picked up one of the Iris smart plugs from Lowes and attempted to integrate it into my existig Zigbee network without purchasing one of their base stations. I’m using an XBee ZB 2.4GHz module.

So far I can tell that for that the smart plug will only join a PAN with a Zigbee stack profile (ZS) of 2, encryption enabled (EE=1) and the encryption options set to transmit key on join (EO=1). However, once the module joins it sends a device discovery request looking for a specific endpoint from the application beyond the controller. I’m not sure what it is looking for here and after a second the smart plug leaves the network and continues scanning.

I’ve considered buying a base station just to sniff the initialization protocol at this application level, but I’m concerned that once the module joins the base station it will be forever locked to that PAN and encryption key. I don’t see a mechanism for resetting the smart plug to have it scan again. My module looks different than yours does, it doesn’t have a battery and has only one button on the outside which actuates the relay to turn the connected device on and off. There are no buttons on the inside either, just a 8 pin programming header of some sort.

RE: Reverse Engineering Zigbee Communication (AlertMe / IRIS) - Added by ltickett about 6 years ago

I haven’t yet, though I would like to.

Maybe you could share a bit of information on how you got to where you are now? (to join the PAN network etc). It’s possible I can capture the packets/data you need to falsy present your XBee ZB module as an IRIS hub?

I would be very disappointed if once the devices joined a network they were unable to be paired with other devices! In fact, i have ordered the heating control devices from British Gas (also rebranded IRIS/AlertMe) and they come with their own hub. I will definitely want to join everything together (seems pointless having two hubs).

L

RE: Reverse Engineering Zigbee Communication (AlertMe / IRIS) - Added by ltickett about 6 years ago

And my plugs also only appear to have one button (relay on/off). Have you tried holding it down?

I haven’t tried anything yet- I did intend to pull the circuit board out of the enclosure to take a look what microcontroller it’s using etc…

RE: Reverse Engineering Zigbee Communication (AlertMe / IRIS) - Added by CapnBry about 6 years ago

I’ve tried holding the button down but all I get is a click when I first press it and no matter how long I hold it doesn’t start blinking again. There might be some trick to it though, but I can’t say for sure if there’s a way to unjoin because I can’t get it to join yet.

The process that occurs when the device is plugged in for the first time goes something like this (it is a standard Zigbee process):

-- Switch to new channel
-> Beacon Request - Broadcast looking for nodes on this channel)
<- Beacon - Each device on the network replies to the beacon, which includes the Zigbee stack profile. If the coordinator does not say it is stack profile 2, the smartplug switches to the next channel and repeats

-> Association Request - The smartplug request joining
-> Data Request - I'm not sure what this does
<- Association Response - Smartplug has joined the PAN
<- Transport Key - Coordinator sets the standard network key, this is the key you see in Ubiqua that lets you decrypt packets
-> Key Request - Smartplug requests trust center key
<- Transport Key - Coordinator sends trust center key
-> Device Announce - The smartplug announces that it is part of the network
-> Link Status - Smartplug announces link status costs and neighbors
-> Match Descriptor Request - Smartplug is broadcasting looking for an endpoint on the PAN that indicates it is the Iris system (last part is my assumption)

All of the above is handled by the coordinator API on the XBee module, so it is transparent to the application. The match descriptor request shows up as a “Zigbee Receive Packet” frame with the following data:
09 25 FD 00 FF
Some scans the second to last byte is different.

I’m guessing that the appliction is supposed to know what that means and then send back a response because 10 seconds later the smartplug announces it is leaving the network and goes back to scanning.

RE: Reverse Engineering Zigbee Communication (AlertMe / IRIS) - Added by CapnBry about 6 years ago

Actually looking into it a little deeper using the explicit receive API type on the coordinator, it looks like that data is actually coming in another packet. I get the Match Descriptor Request on Endpoint 0, Profile 0, Cluster 0x13 (which is the ZDO command for it). Following that I get a packet for Endpoint 0x02, Profile 0xC216, Cluster 0x00F6, which is the data I’m seeing above there (09 25 FD 00 FF). That data appears to be a ZCL header (09 25 FD) with ZCL paylod (00 FF).

This is a lot to digest but if your Ubiqua trial license is still good, it would be great if you could capture the data from the association request through the Match Descriptor Request up to where the network traffic settles down. I might be able to determine what response the device is looking for.

RE: Reverse Engineering Zigbee Communication (AlertMe / IRIS) - Added by ltickett about 6 years ago

First thing I have to try and get the plug to leave the PAN :)

RE: Reverse Engineering Zigbee Communication (AlertMe / IRIS) - Added by ltickett about 6 years ago

Hmm, trial has indeed expired- hmmm…

RE: Reverse Engineering Zigbee Communication (AlertMe / IRIS) - Added by ltickett about 6 years ago

I had a Texas Instruments SmartRF Packet Sniffer installed which i dumped some data from and attached to this post (hopefully you can download the TI software and open the dump).

Holding the power button on the smartplug definitely does something (the wifi light lit orange and stayed lit until i held the power button down for a few seconds a 2nd time). I did this all which capturing the packets in the attached dump.

I think i had disabled all other ZB devices, so all the traffic captured should be from the hub and plug (unless the neighbours have devices).

Let me know how you get on. Also what software you are using?

L

test.psd (27.1 KB) test.psd

RE: Reverse Engineering Zigbee Communication (AlertMe / IRIS) - Added by CapnBry about 6 years ago

Aha! SmartRF Packet Sniffer, that’s what that software was called! I got SmartRF Studio and that wouldn’t let me do a thing. This is much better. I’ve been using a trial key for Ubiqua which expires in a couple of weeks and using that data to hook up to a .NET Zigbee receiver I use for my existing Zigbee device (a thermostat).

It doesn’t look like I can use the data from your capture. Everything beyond the NWK header is encrypted and I’m not familiar with the decryption routine. All that is handled by the XBee adapter firmware for me, or by Ubiqua sniffing the key exchange during pairing. SmartRF only supports decryption on Bluetooth Low Energy devices.

I might as well pick up one of the base stations for pulling the protocol apart. In my mail yesterday Lowes sent me a \$10 of \$50 coupon so it is almost like they’re asking me to pull apart their protocol. My thermostat was super simple because it doesn’t actually support a Zigbee device protocol, they just use the radio like a serial port and transmit all the data to the DigiData endpoint. None of this fancy proper endpoint mapping.

RE: Reverse Engineering Zigbee Communication (AlertMe / IRIS) - Added by CapnBry about 6 years ago

Good news. Looks like the answer was the obvious one, that it wants the coordinator to respond with endpoint 0x02. That is the same one I saw the one packet from. I coded up my response packet, but bad news! I can’t get it to unpair with the Isis hub. When I plug it back in, it just sits trying to connect to the hub.

I took it apart and gave it another look over to see if there was a reset or something inside and looks like it is no joy— it is forever paired to that hub I think. I sent a support email asking if there was a way to pair it with a new hub so let’s see what they say.

EDIT: Hooray, turns out you can unpair it from the Isis device page. That’s crazy. If your hub dies for any reason, welp looks like all your devices are garbage. Looks like my packet isn’t formed properly but I’ll have to look at it tomorrow as I am out of time today.

RE: Reverse Engineering Zigbee Communication (AlertMe / IRIS) - Added by ltickett about 6 years ago

Great. Keep us posted.

The other thing that occurred to me… maybe it doesn’t even matter if the device(s) are paired to a non-existent hub (i.e. on some random PAN) if we’re simply “sniffing” the traffic.

I guess it would be a problem if the device(s) weren’t paired to any devices or part of any PAN (as presumably they’d not be broadcasting any data)… but as long as they think they’re paired to something they’ll be sending data for us to collect.

RE: Reverse Engineering Zigbee Communication (AlertMe / IRIS) - Added by CapnBry about 6 years ago

Yeah it doesn’t look like they broadcast their data if there’s no hub running. The data is unicast and if it doesn’t see the hub running it just keeps publishing routing requests looking for a path back to it. There would also be the problem of sniffing it without the encryption key and method, which would be kind of a pain to figure out without the Ubiqua software.

I did get it to join my XBee-based network but it only spit out a 13 byte status packet that I think contains the plug status and something else about the line (it bounces back and forth between 243 and 242 for me). The wattage I’m pretty sure I can get but it requires the coordinator subscribe to the value and I haven’t got that just yet.

I really need to come up with a better infrastructure in my app for doing this. Right now it is all hard-coded, see this? send this! and if there’s more than one client on the wire that would be all sorts of spaghetti. I’ll work that part out once I’ve got it communicating and publishing to my MQTT.

RE: Reverse Engineering Zigbee Communication (AlertMe / IRIS) - Added by CapnBry about 6 years ago

Just to check in (because 70% of the internet is full of posts where someone is going to figure something out and report back, but it never happens) I still have this on my plate. I’ve been out of town and don’t get much opportunity to work on it during the week but hopefully this Sunday I’ll be able to take another crack at this nut.

I really like these plugs though. Measurement, wireless, and a controllable relay for \$30 each? That’s a pretty good deal despite not putting out things like power factor or voltage.

RE: Reverse Engineering Zigbee Communication (AlertMe / IRIS) - Added by sh0x about 6 years ago

Thought I’d jump in on this. I have the iris motion sensor, door/window sensors, doorbell button. I have the power outlet too. I am thinking about getting an Iris hub and CC2531EMK just to sniff the frame formats being sent from the hub.

Also I came across information on lowes website that alertme sensors can be reset by taking out the battery for 30 seconds then upon replacing it hitting the button 8 times within 10 seconds. I haevn’t looked at the power outlet yet but the other sensors have this. It might suffice to reset your sensors if your hub were to break.

RE: Reverse Engineering Zigbee Communication (AlertMe / IRIS) - Added by sh0x about 6 years ago

On another note, I just received a power outlet from safeplug.com. They sent it to me for free to ‘try’ before I buy (really?). They understand I want to build my own hub so they emailed me over all the driver docs. The plugs use zigbee HA profile (SE units are also available). They will provide power usage metrics and can be controlled remotely using zigbee. Safeplug comes with two receptacles. It is surface mount but its aesthetically pleasing in my opinion. They have built in RFID readers to support RightPlug, and they come with RFID keys to reset the plug or to enable/disable the receptacles manually without requiring a zigbee network. And their plugs can act as zigbee routers to extend your network.

I’m super impressed with safeplug so far. Unfortunately they don’t have a lot of other products such as light switches or sensors and I’m not sure what their road map is.

I haven’t tested them with zigbee yet but I hope to get these going in the next week or so. I’ve only seen US versions of their plugs too.

RE: Reverse Engineering Zigbee Communication (AlertMe / IRIS) - Added by ltickett about 6 years ago

Great news to hear others are keeping on top of this- i have literally been snowed under at work since back from my holiday so probably wont be able to pick this back up for a while!

However, on a different note… I have opened my EVE Alpha board and had my AlertMe / British Gas “heating pack” installed now so when I do finally get back around to looking at this it will be with more devices and hopefully with the hardware to eliminate the need for the hubs!

RE: Reverse Engineering Zigbee Communication (AlertMe / IRIS) - Added by CapnBry about 6 years ago

Hrm apparently I haven’t gotten the email notifications that there was activity on this thread. More people join the fray!

Good news! I’ve got the SmartPlugs paring and sending data. As mentioned previously, the plugs will only attempt to join a network with encryption on, the key sent during join, and a zigbee stack profile of 2. These are all handled by setting the properties on the XBee from X-CTU, or using AT commands.

When the new device tries to join, it sends a “device announce”. When this is seen, store the short and long address of the node. If the node is new to you, send an “Active Endpoint Request” to the device (Endpoint=ZCL, ProfileId=Device Profile, ClusterId=0x0005). Meanwhile, the device will also send a “Match Descriptor Request” ZCL ClusterId=0x0006. Respond that you (address of interest = your short address, 0x0000 if you’re the coordinator) has the endpoint 0x02. The device should have responded to the endpoint request that it supports 2 endpoints, 0x02 and 0xf0. Now you just need to tell it to turn on, by sending a packets to ProfileId 0xc216. Here’s a less verbose description

Device: Announce
You: (Endpoint=ZCL, Profile=Device Profile, Cluster=0x0005) Active Endpoint Request
Device: (Endpoint=0x00, Profile=0x0000, Cluster=0x0006) Match Descriptor Request
You: (Endpoint=0x00, Profile=0x0000, Cluster=0x8006) Match Descriptor Response data=endpoint 0x02
Device: (Endpoint=0x00, Profile=0x0000, Cluster=0x8005) Active Endpoint Response data=endpoints 0x02 0xf0
You: (Endpoint=0x02, Profile=0xc216, Cluster=0x00f6) FrameControl=0x11 ClusterCmd=0xfc
You: (Endpoint=0x02, Profile=0xc216, Cluster=0x00f0) FrameControl=0x19 ClusterCmd=0xfa data=0x00 0x01

And you’re connected! The device will still come up and connect to you without going through the descriptor search from now on until you unpair it. As shox pointed out, you can unpair a device by unplugging it and pressing the button for a second, then plugging it back in and hitting the power button 8 times within 10 seconds.

Now for the data. These all come on Endpoint=0x02, Profile=0xc216 all in little endian:
Cluster=0x00ef, ClusterCmd=0x81 2 bytes (every 10 seconds): Instant power usage in watts
Cluster=0x00ef, ClusterCmd=0x82 9 bytes (every 60 seconds): Minute stats, 4 bytes total running watt seconds, 4 bytes uptime in seconds, 1 byte reset indicator
Cluster=0x00ee, ClusterCmd=0x80 2 bytes (on change, boot): Plug power state? the LSB of the first byte is on/off indicator but there are more bitflags here
Cluster=0x00f0, ClusterCmd=0xfc 13 bytes (every 30 seconds): Unknown, bytes 2-5 are a dword continuously incrementing by 30,720 per packet, a millisecond count?
// Not sure about how these next 3 affect the latching of the power state
Cluster=0x00ee, ClusterCmd=0x01 1 byte: Request plug power state. The byte is always 0x01 (plug 1?)
Cluster=0x00ee, ClusterCmd=0x02 2 bytes: Change plug power state. The first byte is on/off, the second is 0x01. This appears to be latched in some way, requiring ClusterCmd=0x03 to precede it?
Cluster=0x00ee, ClusterCmd=0x03 0 bytes: Unlatch the power state to allow it to be changed by 0x02 above? Not sure why they’d need that but I can’t toggle the power without sending this first

RE: Reverse Engineering Zigbee Communication (AlertMe / IRIS) - Added by hamiltonsean69 almost 6 years ago

Hello CapnBry,

I am actively working on a project for school(UCSD) which uses a Raspberry Pi and the Xbee ZB device. I see you have had success in controlling the IRIS Smart Plug. I am using this same device as my first test case. Can you provide the code that you used to get the smartplug pairing and sending data? This would be a great head start for me. I appreciate any help you can provide.

Sean

RE: Reverse Engineering Zigbee Communication (AlertMe / IRIS) - Added by millsy almost 6 years ago

Hi,
I’ve also been looking closely this thread.I’m very new to this zigbee thing so excuse my ingnorance. I managed to get hold of a couple of alertme devices (key fob and pir) cheap and trying to get them to make friends with a Telegesis USB stick i had. I get the similar behaviour in that i get SED and NEWNODE anounces on a certain node id meaning thats its joined the network but then after 10 seconds it leaves and joins again with another nodeid. i can request endoints and descriptors in thet 10seconds. They show up 0x02 and 0xf0 similar to the plug. profieid is 0xC216. i can also get the inclusters of each endpoint (strange there doesn’t show out clusters as these are ‘output’ type devices!).

Im using the telegesis terminal using their AT commands. It’s this resonse to the endpoint request i’m struggling with. Is this required before the devices stop hopping about? only i can’t see any specific command that does this. I was told by Telegesis that the resonse is automatic so i’m wondering if it needs something else before it with connect properly. I can send UCAST messages but i’m struggling a bit to understand how to interprit your response messages to something this Telegesis stick can send. (thei

RE: Reverse Engineering Zigbee Communication (AlertMe / IRIS) - Added by millsy almost 6 years ago

oops…my 2year old decided to press return in the middle of that last post!. Anyway i was just going to mention their AT command list is available on their website.

Any sort of help would be greatly appreciated.

Craig

RE: Reverse Engineering Zigbee Communication (AlertMe / IRIS) - Added by CapnBry almost 6 years ago

hamiltonsean69 wrote:
> I am actively working on a project for school(UCSD) which uses a Raspberry Pi and the Xbee ZB device. I see you have had success in controlling the IRIS Smart Plug. I am using this same device as my first test case. Can you provide the code that you used to get the smartplug pairing and sending data? This would be a great head start for me. I appreciate any help you can provide.

The code is a bit of a mess because I’m not sure where to go with it just yet and haven’t given it much time since I got it reporting data. Here’s the source code
http://capnbry.net/\~bmayland/zigbee/zigbee-alertme-20130512.zip

It uses “Micheal’s Networking Toolkit” http://mftoolkit.codeplex.com/ which had some bugs and was incomplete with regard to ZCL packets so I’m not sure what code is his and which I’ve edited. His project isn’t under development any more. I’ve included everything I’ve got. You’ll also get an error about not having MqttLib which is fine, it should build without it. I publish my data into a mqtt cloud. Things that refer to the “thermostat” are for my air conditioner thermostat, which comes on the DigiData endpoint. Anything from that you can disregard.

RE: Reverse Engineering Zigbee Communication (AlertMe / IRIS) - Added by CapnBry almost 6 years ago

millsy wrote:
> I’ve also been looking closely this thread.I’m very new to this zigbee thing so excuse my ingnorance. I managed to get hold of a couple of alertme devices (key fob and pir) cheap and trying to get them to make friends with a Telegesis USB stick i had. I get the similar behaviour in that i get SED and NEWNODE anounces on a certain node id meaning thats its joined the network but then after 10 seconds it leaves and joins again with another nodeid. i can request endoints and descriptors in thet 10seconds. They show up 0x02 and 0xf0 similar to the plug. profieid is 0xC216. i can also get the inclusters of each endpoint (strange there doesn’t show out clusters as these are ‘output’ type devices!).

I can’t tell from a quick look at their docs what AT command would create an endpoint that they’d automatically respond with, so you’ll probably just have to do it yourself when you get the Match Descriptor Request:
Source/Dest Endpoint: ZCL (0x00)
Cluster ID: Match Descriptor Response (0x8006)
Destination Address 16/64: (the node)
And then the data:
SeqNo: From request
Status: Success (0)
Address of Interest: coodinator (0x0000)
Endpoint Count: 1
Endpoints: 0x02

If I didn’t send that the plug would leave the channel after 10 seconds as you’re seeing. Once it got that far it would lock on for many minutes before it gave up trying to finish the join. That’s your window for doing the 0x00f6 and 0x00f0 clusters on the AlertMe profile (0xc216). After those, data would start showing up and it wouldn’t leave the channel any more.

RE: Reverse Engineering Zigbee Communication (AlertMe / IRIS) - Added by hamiltonsean69 almost 6 years ago

I get three messages continuously from the plug. One is a Route Record Indicator, then and unknown message that is clusterID=0x007d and profileID=0x3300. The last message is the match descriptor that I can reply too. However the plug still leaves the network after replying to that message right now but it looks as though I need those 0x00f6 and 0x00f0 messages, I will try those tonight.

Milsy, what is the SED and ANNOUCE messages you are seeing? I never see?

It is kind of sad that AlertMe did not make these devices part of standard profiles like Home Automations or Smart Energy… That would have made interoperability much easier. I wrote AlertMe asking for a specs document or anything they would provide, I hope they do but not counting on that too much.

(1-25/66)