Archive for April, 2011

Plugwise Protocol Analysis, Part 2

25 April 2011 Leave a comment

Continuing in my attempts to understand the PlugWise protocol, I discovered a few more command/reply types in my captured.

Role call

Periodically the source queries the Circle+ node for all nodes that could be connected to the Circle+. This is done with the command/reply sequence 0018/0019.  The 0018 command queries 64 nodes and the 0019 reply contains the MAC of the Circle+ and the MAC of another Circle or “FFFFFFFFFFFFFFFF” and the associated nodeID .

The first query (nodeID=00):

w 0018 000D6F0000B1B64B 00
r 0000 027A 00C1
r 0019 027A 000D6F0000B1B64B 000D6F0000B1B967 00

The last query (nodeID=3F)

w 0018 000D6F0000B1B64B 3F
r 0000 02B9 00C1
r 0019 02B9 000D6F0000B1B64B FFFFFFFFFFFFFFFF 3F

Switching a circle on and off

Captured the command for switching a node on and off this uses the command 0017. This command does not have its own reply code, but returns a 0000 reply message.containing the usual 16-bit reply value (might be a bitfield) and the MAC of the circle that switched. The reply for on or off is different.

Switch the circle ON

w 0017 000D6F0000AF4C47 00
r 0000 037B 00C1
r 0000 037B 00DE 000D6F0000AF4C47

Switch the circle OFF
w 0017 000D6F0000AF4C47 01
r 0000 038F 00C1
r 0000 038F 00D8 000D6F0000AF4C47

Error reply that leads to a command resend

I noticed this behaviour in my logs. This was after one of the many 0023 requests, and instead of the 0024 reply there was an 0000 reply with code 00E1. Is this a NAC or Timeout, or Network Busy reply? It repeats a few times, and then a 0008 command is send (is this some sort of restart?), after which a short initialisation sequence follows and everything continues.

w 0023 000D6F0000B1B5B6
r 0000 0312 00C1
! no reply received!

! another request that succeeds.
w 0023 000D6F0000B1B967
r 0000 0313 00C1
r 0024 0313 000D6F0000B1B967 0B047EAE 00044440 0185 653907014023 4CCEC0C2 02

! the ‘timeout’ reply.
r 0000 0312 00E1

! same request as the one that failed.
w 0023 000D6F0000B1B5B6
r 0000 0317 00C1
r 0000 0317 00E1

! retries, this is the 16th.
w 0023 000D6F0000B1B5B6
r 0000 0328 00C1
r 0000 0328 00E1

! seems it is giving up retrying, sends command 0008.
w 0008 00
r 0000 0329 00C1
r 0000 0329 00DD 000D6F0000B1B64B

Then a short initialisation; First a 0023 to the stick, followed by a sequence to the Circle+ 0023,0029,003E,0012, followed with normal 0023 commands to other circles.

w 0023 000D6F0000B835CB
r 0000 032A 00C1
r 0024 032A 000D6F0000B835CB 0000000000000000 00 80 6539 0700 8510 4CCEC22A 00

w 0023 000D6F0000B1B64B
r 0000 032B 00C1
r 0024 032B 000D6F0000B1B64B 0B047EAF00044450 01 85 6539 0700 7324 4CCEBFA1 01

w 0029 000D6F0000B1B64B
r 0000 032C 00C1
r 003A 032C 000D6F0000B1B64B 07311206230411

w 003E 000D6F0000B1B64B
r 0000 032D 00C1
r 003F 032D 000D6F0000B1B64B 0C1F070601457A

w 0012 000D6F0000B1B64B
r 0000 032E 00C1
r 0013 032E 000D6F0000B1B64B 00260129 0000F03B 00000000 0002

w 0023 000D6F0000B1B967
r 0000 032F 00C1
r 0024 032F 000D6F0000B1B967 0B047EAF 00044440 01 85 653907014023 4CCEC0C2 02

I also saw an 0059/0000 command reply after it got all circles. This was part of an 0023, 004A, 0029, 0012, 0059 sequence to the Circle+

w 004A 000D6F0000B1B64B
r 0000 034F 00C1
r 0000 034F 00F1 000D6F0000B1B64B

w 0029 000D6F0000B1B64B
r 0000 0350 00C1
r 003A 0350 000D6F0000B1B64B 08321206230411

w 0012 000D6F0000B1B64B
r 0000 0351 00C1
r 0013 0351 000D6F0000B1B64B 00250126 0000F8DE 00000000 000C

w 0059 000D6F0000B1B64B FFFF
r 0000 0352 00C1
r 0000 0352 00FA 000D6F0000B1B64B

No idea yet what the purpose of command 0059 is, it sends FFFF and the reply returns a status 00FA in a generic 0000-reply.
I suppose it would be nice to find the meaning of the 0000-reply. It almost has to be a 16-bit bitfield. Some 0000-replies return extra data (like a MAC).

Categories: Domotica Tags: ,

Plugwise Protocol Analysis, Part 1

24 April 2011 4 comments

I ordered my Plugwise set two weeks ago, and it arrived a few days later. The hardware looks OK, through it is a bit expensive. Big disadvantage is that it’s windows only, through there are some people that have things running with their own software (both Linux and Windows). My goal is to get things up-and-running with Linux, but that means some reversing work. I did find two blogs about it, and that was a good starting point.

To get a quick start I remembered that the netbook I recently bought still has it’s windows partition (I use Linux on it), so I could install the ‘Source’ and check how it works.

Installation went OK and it discovered my circles (through I still had to type the circle-addresses myself). I only discovered  the buttons at the bottom  a few days later after wondering how to change settings, but the Plugwise window can be resized. Not many software developers think of somewhat smaller screens (1024*600 is not that big a resolution, but also not far from the old 1024*768 and the also quite popular 1366*768).

I have PlugWise devices with firmware v2.4 (as read from the PlugwiseData.mdb) and the ‘Source’  is v2.16

Analising the Protocol

From Hackstuces I got the idea to use portmon and capture the communication. I did forget to change the max line-length it stores in the log, so for my initial captures (where I configured the circles) some date is truncated. I concentrated my analysis of the protocol with the ‘data gathering’ part, for now.

Offcourse I also used the findings I found at Maartens blog, but it is not complete yet. That is why I’m writing this, documenting what I found and a way to find it again. For the data frame structure, see the Plugwise Unleased document and the blog posts.

Remember, all communication data is ASCII, and the messages where we are looking at are all HEX digits. There are also some other Ascii messages, but those seem to be informational only and contain no new data. It is probably to aid debugging, likely messages for the circle network. I’ll just ignore them for now.

Here are three mayor parts I see when looking at the traffic, after starting the ‘Source’.

  • Initialisation and clock-synchronisation with the Circle+
  • read real-time data from circles
  • read stored data from circles

I Striped out the Start and End (CrLf) sequence, and CRC16 from each message. According to this post in Domotica forum the ACK reply can be considered as a notification that the command is being processed (or rejected) and it gives the sequencenumber back for tracking what happens with it. In the dumps below, I omit this ACK reply, to save space.


This is a simple sequence, where the MAC of the Stick is found, and some synchronisation with the Circle+ takes place.

For my hardware here are the MAC addresses.

  • 000D6F0000B835CB (Stick)
  • 000D6F0000B1B64B (Circle+)

This is the sequence of commands and responses I found:

So to summarise the command/reply sequence:

  • (to stick) 000A/0011, (to circle+) 004E/0000 , then a reset (might be just a probe, to see if the network is connected)
  • (to stick) 000A/0011, 0023/0024, 0023/0024
  • (to circle+) 0023/0024, 0016/0000, (0008/0000), 0028/0000, 0029/003A, 004A/0000, 003E/003F (the position of the 0008/0000 sequence varies)
  • (to circle) 0023/0024, 003E/003F, 0012/0013

The 08 command contains no MAC, so is a bit strange. It returns the MAC of the Circle+, but before this command there was already communication directly to the Circle+ (probably using the Circle+ MAC from the ‘Source’ configuration). The 0016 command contains the current date-time.

There is a difference between reading the Circle+ and the other Circles, but both have Commands 0023 and 003E in common. Now the Circle+ is the coordinator node that has a Clock. That explains some differences, as command 0016 is a SET clock data and command 003E is a GET clock. Maarten already analysed this data. Note that the clock seems to be set to UTC, not local time. The 16-bit integer for Minutes  in the date part of the 0016 command is counted from midnight of the first day of the month.

Note that command 003E is only used in the first round of calling all the circles, so it is part of the initialisation/synchronisation.

The reply to the initialisation command (000A) gives the MAC-address of the Stick
w 000A
r 0011 0001 000D6F0000B835CB 01 01 440D6F0000B1B64B 3B44 FF

In the reply, the sequence number (0001) associated with the command, MAC address Stick (000D6F0000B835CB), 64-bit, two 8-bit fields that are either True (non zero) or False (zero), an Extended PAN ID (440D6F0000B1B64B) 64-bit, and the PAN ID (3B44) 16-bit, and another unknown 8-bit value (FF). The Extended PAN ID looks like the Circle+ MAC with the first byte changed to 44 instead of 00. The value of 44 is set when configuring the network, an changes when the network is destroyed and rebuild.

Using command 0024 more info is requested from the stick

w 0023 000D6F0000B835CB
r 0024 0002 000D6F0000B835CB 00000000 00000000 00 80 6539-0700-8510 4CCEC22A 00

This request is weird, maybe a probe if a Circle+ is connected
w 004E 000D6F0000B1B64B
r 0000 0003 00F4 000D6F0000B1B64B

Now, for some unknown reason, Initialisation restarts here (does that every time)
w 000A
r 0011 0004 000D6F0000B835CB 01 01 440D6F0000B1B64B 3B44 FF

The following two (identical) commands go to [000D6F0000B835CB], the Stick, detected in the previous command
w 0023 000D6F0000B835CB
r 0024 0005 000D6F0000B835CB 00000000 00000000 00 80 6539-0700-8510 4CCEC22A 00
w 0023 000D6F0000B835CB
r 0024 0006 000D6F0000B835CB 00000000 00000000 00 80 6539-0700-8510 4CCEC22A 00

So to summarise the command/reply sequence:
(to stick) 000A/0011, (to circle+) 004E/0000 , then a reset
(to stick) 000A/0011, 0023/0024, 0023/0024

First time data-scan from circles is different for Circle+ and normal Circles. I omit the capture, just the commands.

Circle+ 0023/0024, 0016/0000, (0008/0000), 0028/0000, 0029/003A, 004A/0000, 003E/003F

Circle+ 003E reply 003F 000D 000D6F0000B1B64B 12 1B 2A 06 01 45 7A

Circle   0023/0024, 003E/003F, 0012/0013

Circle  003E reply 003F 0012 000D6F0000AF4C47 12 1B 28 06 01 45 7A

Both give about the same reply, a different sequence number, almost identical time stamp, an identical  unknowns.

Noticed that several commands return a 0000-reply. Those replies have the same structure, reply code 0000, 16-bit sequence value, another 16-bit value (probably bit-fields, some kind of status, it seems) and a 64-bit MAC address.

Read real-time data from circles

All Circles are read with 0023/0024 and 0012/0013 command/reply pairs. The handling of the Circle+ is not different from others, after the initialisation sequence completed. The Source (awefull name)  keeps asking for data, so it can display real-time data.

w 0023 000D6F0000B1B64B
r 0024 0056 000D6F0000B1B64B 0B048013 00044480 01 85 6539-0700-7324 4CCEBFA1 01
w 0012 000D6F0000B1B64B
r 0013 0058 000D6F0000B1B64B 002F0175 00010AA7 00000000 0004
w 0023 000D6F0000B1B967
r 0024 005A 000D6F0000B1B967 0B048014 00044470 01 85 6539-0701-4023 4CCEC0C2 02
w 0012 000D6F0000B1B967
r 0013 005B 000D6F0000B1B967 00070038 00002E14 00000000 0004

Read stored data from circles

Al Circles are read with command/reply 0048/0049. It takes more than one command to read one circle.

W 0048 000D6F0000B1A240 00044460
R 0049 0051 000D6F0000B1A240 0B047F80 00000A87 0B047FBC 00000ACF 0B047FF8 00000AAC FFFFFFFF FFFFFFFF 00044460
W 0048 000D6F0000B1A240 00044440
R 0049 0052 000D6F0000B1A240 0B047E90 00000A9B 0B047ECC 00000AD4 0B047F08 00000B0B 0B047F44 00000B0E 00044440
W 0048 000D6F0000B1A240 00044420
R 0049 0053 000D6F0000B1A240 0B047DA0 00000A8C 0B047DDC 00000A98 0B047E18 00000A6D 0B047E54 00000A71 00044420

W 0048 000D6F0000B1B5B6 00044480
W 0048 000D6F0000B1B5B6 00044460
R 0049 0055 000D6F0000B1B5B6 0B047F44 000021AA 0B047F80 000020F1 0B047FBC 0000216D 0B047FF8 0000213E 00044460
W 0048 000D6F0000B1B5B6 00044440
R 0049 0057 000D6F0000B1B5B6 0B047E54 00036708 0B047E90 00035291 0B047ECC 00000DD3 0B047F08 00002199 00044440
W 0048 000D6F0000B1B5B6 00044420
R 0049 0059 000D6F0000B1B5B6 0B047D64 000349C5 0B047DA0 0003538A 0B047DDC 0003541F 0B047E18 000355A4 00044420

I have not attempted to decode the 0049 replies. From the data structure I assume that 8 values ( 32 bit each) are returned, probably in pairs belonging together. I also assume the parameter in the 0048 command and the matching one in the 0049 reply (for example “00044420“) is some sort of buffer-code.  I did read about a buffer address mentioned in the explanation of the device info command, but not this command structure.

[later] I think the pairs of data is a power-value followed by a timestamp. The timestamp has the same structure as the date-word of the 0016 command. This means that  value 0B 04 7DA0 could mean Year 2011, Month April,  From the start of the month 32160 minutes, this is 536 hour, which is 22 days and 8 hour. Somewhere during the 23rd of april (yesterday), when the data was captured. So that is most likely.

[days later] The structure of this reply is explained in the plugwise unleased documents, and indeed 4 pairs of data, each pair represents one hour of accummulated power usage.


In the previous two sections, different data is retrieved. While analizing the log-captures, I noticed that both processes run at the same time. So a 0023 command starts and before de 0024 reply is received a 0048 command is send. Then the 0024 reply arrives followed with the 0049 reply. in between I also see the ACK replies. It is likely that the next command is not send before the ACK is received, but I am not sure if that is the case. Might be that usually the ACK is generated by the NC in the circle+, and has less delay as data-replies, so arrives shortly after the command is send. I assume that data-reply first needs to get back from a circle to the NC before it is transmitted to the stick.

It is not possible match a command directly with an ACK, but the ACK has the same sequence-number as the data-reply, which arrives later, and can be matched with a command. I suggest to  not wait for results from a command, just process what arrives. For error correction, wait for the first (fast) ACK reply and store the sequence number and associate that with the command (evaluate the value too for error processing). E.g. 00C1 is an OK response, but I did see this type of message used for other things (like responding with 00E1 instead of the expected reply), that could considered as some kind of timeout in the Zigbee network.

A forum post mentions that 00C2 and 00C3 are error-return codes from the ZigBee stack and that the command and it is not accepted.

Categories: Domotica Tags: ,

Plugwise on Linux

13 April 2011 Leave a comment

Het leek me wel leuk om eens te kijken wat de verschillende apparaten hier nu allemaal aan energie verbruiken en dat wilde ik dan over langere tijd meten. Hiervoor blijkt een systeem met de naam Plugwise te bestaan, waarmee je met je computer inzage in die gegevens kan krijgen.

Ik was op internet al wat  tegengekomen, o.a via BWired en Digits Domotica Blog, daarmee op het domotica forum terecht gekomen. Dat inspireerde me om hier toch eens wat serieuzer naar te kijken wat na een tijdje resulteerde in een bestelling van een Plugwise Home Kit.

Vanuit de leverancier van Plugwise wordt helaas alleen Windows ondersteund. Gelukkig hebben enkele mensen Plugwise ook onder Linux aan het werk gekregen. M’n enige machine thuis met Windows erop, is m’n werk-laptop en die wil ik daarvoor natuurlijk niet gebruiken. Ik gebruik thuis een zuinige (ASRock ION 330) onder Ubuntu Linux en die moet ook de koppeling met Plugwise gaan dienen. Het zal wel wat extra uitzoekwerk zijn, maar dat is vast leerzaam.

Nuttige informatie over Plugwise op Linux (PoL), ben ik hier en hier: tegen gekomen.

Vandaag is mijn Plugwise Home set binnengekomen.  Aan de slag dus. Alvast gekeken hoe de Plugwise USB Stick onder linux herkend wordt.

Dit zie ik met lsusb
Bus 002 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

En dit gevonden in syslog
kernel: usb 2-5: new full speed USB device using ohci_hcd and address 4

kernel: usb 2-5: configuration #1 chosen from 1 choice

kernel: usbcore: registered new interface driver usbserial

kernel: USB Serial support registered for generic

kernel: usbcore: registered new interface driver usbserial_generic

kernel: usbserial: USB Serial Driver core

kernel: USB Serial support registered for FTDI USB Serial Device

kernel: ftdi_sio 2-5:1.0: FTDI USB Serial Device converter detected

kernel: usb 2-5: Detected FT232RL

kernel: usb 2-5: Number of endpoints 2

kernel: usb 2-5: Endpoint 1 MaxPacketSize 64

kernel: usb 2-5: Endpoint 2 MaxPacketSize 64

kernel: usb 2-5: Setting MaxPacketSize 64

kernel: usb 2-5: FTDI USB Serial Device converter now attached to ttyUSB0

kernel: usbcore: registered new interface driver ftdi_sio

kernel: ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver

modem-manager: (ttyUSB0) opening serial device...

modem-manager: (ttyUSB0): probe requested by plugin 'Generic'

modem-manager: (ttyUSB0) closing serial device...

en van lsusb
Bus 002 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

Nu moet er geconfigureerd worden; De Stick en Circle+ moeten gepaird worden en daarvoor heb ik een python scriptje gevonden.

Categories: Domotica Tags: , ,

Hello world!

6 April 2011 Leave a comment

Welcome to This is your first post. Edit or delete it and start blogging!

Categories: Uncategorized