Posts Tagged ‘PlugWise’

Plugwise Protocol Analysis, Part 6 (Firmware update observations)

7 October 2012 4 comments

Last year, there was a new firmware release for the PlugWise system. Curious as I was, I captured the communication between “Source” and the “Stick”as I did for the other protocol analysis sessions. Today I found me notes about this and document them here. The intention of this is to discover possible new commands used by the Plugwise protocol, some of them might be useful for open source implementations of software to use the “Circles”. I do NOT think uploading firmware should be done through our own software, but it is nice to know how it works.

As I captured this data quite a while ago, I am not sure anymore how complete all this is.

Update Firmware

After I got a message in “Source” that new firmware was available, I captured the chatter between “Source” and “Stick”. This update did update everything it could find, and tore down the old network and configured a new one. This is different from just updating a new module in your network. Probably, because some parts of the mesh-network protocol changed, or just because the “Stick” and/or the “Circle+” need an update, so the mesh-network is reset.

Analysis if the Firmware update process to firmware 2011
Summary of firmware versions as reported by the 0024 response

Before the update,  running firmware 2010

  • Stick    653907008510 4CCEC22A 00
  • Circle+    653907007324 4CCEBFA1 01
  • Circle    653907014023 4CCEC0C2 02

After the update, running firmware 2011

  • Stick    653907008510 4DCCDA69 00
  • Circle+    653907007324 4DCCDAF3 01
  • Circle    653907014023 4DCCDB7B 02

Other remarks

  1. Network ID changed (modified circle+ address)
    • Before update
      • LongPAN:060D6F0000B1B64B
      • ShortPAN:1606
    • After update
      • LongPAN:8A0D6F0000B1B64B
      • ShortPAN:3B8A
  2. Internal archive buffers
    • all buffers cleared
    • first bufferaddress is 0x00044000 (same)

What happens when the software starts:

1) Initialization sequence. Gets some basic data for the software
1a)    Initialization request to the stick with the 000A/0011 sequence
1b)    Identification request to the stick with the 0023/0024 sequence
This gives the PAN id and the stick-address and the firmware version of the stick.
1c)    Request to Circle+ (software must know address) with 004E/0000 sequence (gives a status 00F4)
2a)    Initialization request to the stick with the 000A/0011 sequence
2b)    Identification request to the stick with the 0023/0024 sequence (repeats 2 or 3 times, reason unknown)
2c)    Identification request to the Circle+ with the 0023/0024 sequence
2d)    Time-sync with Circle+ 0016/0000 and 0028/0000 sequences
2e)    Other setting to Circle+ 004A/0000 (poll interval an probably something else)
2f)    Then a sequences 0029/003A, 003E/003F to the Circle+
2g)    Send the reset code 0008 00/0000, position changes between tests, somewhere after the 004A/0000 sequence
2h)    For ‘source software’, normal scanning starts (0023/0024;0012/0013, later also 0048/0049)

When running the firmware update software, instead of normal scanning an inventory of modules is done with 0018/0019 for 64 modules (this seems the maximum number of modules, but I am not sure of this)

3a)    scanning for available modules with 0018/0019
3b)    query Stick and Circle+ with 0023/0024 sequence
3c)    reset code 0008 01/0000
3d)    query normal Circles with 0024/0023 sequence (once each)
3e)    send reset code 0008 00/0000, twice

4a)    query all normal Circles with 0023/0024 then 000C/0010 (gives firmware version)
4b)    query Circle+ with 0023/0024 then 000C/0010 (gives firmware version)
4c)    query Stick with 0023/0024 then 000C/0010 (gives firmware version)
4d)    send reset code 0008 00/0000

Update Stick

5) get firmware version (request and reply)
SEND    000C 000D6F0000B835CB
RECV    0000 0076 00C1
RECV    0010 0076 000D6F0000B835CB 4CCEC22A

The 000C/0010 sequence is always preceded by a 0023/0024 sequence, both reports the old firmware level.

After the firmware update this check is done again, then the 0010 reports the new firmware version (loaded and ready to start i assume) and the 0024 reports the old firmware version (the running version)
This phase is probably the checking phase of a firmware update.
It starts with an 0008 reset, then queries the circles, then circle+, then stick, then another 0008 reset.

6) First firmware upload (bootloader?) to the stick
6a) a few checks
SEND    0023 000D6F0000B835CB
RECV    0000 0075 00C1
RECV    0024 0075 000D6F0000B835CB 00000000 00000000 00 80 653907008510 4CCEC22A 00

SEND    000C 000D6F0000B835CB
RECV    0000 0076 00C1
RECV    0010 0076 000D6F0000B835CB 4CCEC22A

6b) this prepares for the firmware upload, I assume
SEND    000B 000D6F0000B835CB
RECV    0000 0077 00C1
RECV    0003 0077 00CF    *** -=-Pair/unpair/confirm-=- ***

6c) send firmware/bootloader image
... binary data, not the typical ascii-hex data ... (bootloader, firmware)
6d) a few checks again
SEND    0023 000D6F0000B835CB
RECV    0000 0078 00C1
RECV    0024 0078 000D6F0000B835CB 00000000 00000000 00 80 653907008510 4CCEC22A 00

SEND    000C 000D6F0000B835CB
RECV    0000 0079 00C1
RECV    0010 0079000D6F0000B835CB 4DCCDB7B

Update Circle+

SEND    000F 000D6F0000D3595D023C
RECV    0000 015A 00C1
RECV    0000 015A 00E8 000D6F0000D3595D

Somewhere here the network was torn down and the new firmware uploaded, then the network is rebuild.
No need to analyze the firmware upload on the windows side, as you need the windows software+license anyway.
Could not find the firmware files on disk, so I assume they are held in memory.
Anyway, the circles are updated so that does not mater.

RECV    0006 0003 CircleMAC

SEND    0023 CircleMAC
RECV    0000 0020 00E1

SEND    0007 01 CircleMAC
SEND    0023 CircleMAC

****    RECV    0061 FFFD CircleMAC
****    Received the 0061 broadcast between other chatter

RECV    0024 00DB CircleMAC 00010002 00048B28 01 85 653907014023 4DCCDB7B 02
(the clock is uninitialized)

SEND    0016 CircleMAC 0B07923C 00044000 4000 17380D 02
here the time is SET, and reset buffers too
RECV    0000 00DC 00D7 CircleMAC

SEND    0023 CircleMAC
RECV    0024 00DD CircleMAC 0B07923C 00044000 01 85 653907014023 4DCCDB7B 02

SEND    005F CircleMAC

SEND    0057 CircleMAC 003C 0000
RECV    0000 00DF 00F8 CircleMAC
SEND    0058 CircleMAC 01
RECV    0000 0123 00F9 CircleMAC

SEND    0023 CircleMAC
RECV    0024 0130 CircleMAC 0B07923E 00044000 01 85 653907014023 4DCCDB7B 02

SEND    0040 CircleMAC 00 01
RECV    0000 0131 00E5 CircleMAC


A plugwise device can have it’s firmware loaded in a buffer and it is activated by a ‘reboot’. Maybe you can switch between 2 firmwares, as can also be done with some other ’embedded’ devices, as kind of fail-save mechanism.  Firmware is uploaded to each device separately.

After flashing new firmware the module is reset and all configuration data (like schakel schema’s) are uploaded again.

Categories: Domotica Tags: ,

Plugwise Protocol Analysis, Part 5 (Date/Time)

3 July 2011 4 comments

More and more details become clear in the plugwise protocol. In Plugwise Unleased Maarten made this post, that describes a timesync between the modules and the computer. There is also a second DateTime format in use.

I also found a third field, that is also represent a time format. This is in the 003F response and the 0016 command.

In this post I describe what I found for future reference. I use color to make references to the same type of timestamp more clear. To make the messages fit, I removed the MAC-addresses ((…) in those commands.

Date-time format – Packed for archive

This date-time format is used when storing data in the buffers for data logging. It only registers down to the minute level. This is sufficient, as the data is archived on an hourly base, i.e. the power consumption of a device is measured for one hour and the accumulated power usage for that hour is archived. Commands that use this format are 0016/0000 and 0023/0024.

SEND    0016 ... 0B0540DB FFFFFFFF FFFF 0C2B13 04    [2011-05-12 12:43 UTC]
RECV    0000 ...

SEND    0023 ...
RECV    0024 ... 0B0540DB 00045278 01 85 653907014023 4CCEC0C2 02    [2011-05-12 12:43 UTC]

The Archive DateTime ‘stamp’ is used in the read-buffer sequence 0048/0049

SEND    0048 ... 00045140
RECV    0049 ... 0B05378C 00002564 0B0537C8 00002574 0B053804 0000259E 0B053840 00002592 00045140

Codesample in VBscript to decode this (e.g: 0B05378C)

Function DecodePWpackeddate(ByVal strPWdate) 
Dim intYear, intMonth, lngMinutesMonth 
Dim intDay, intHour, intMinute 
If strPWdate <> "FFFFFFFF" Then 
intYear = CInt("&H" & Mid(strPWdate,1,2)) + 2000 
intMonth = CInt("&H" & Mid(strPWdate,3,2)) 
lngMinutesMonth = CLng("&H" & Mid(strPWdate,5,4)) 
intDay = CInt(lngMinutesMonth \ (60*24) ) +1 
intMinute = CInt(lngMinutesMonth Mod (60*24) ) 
intHour = CInt(intMinute \ 60) 
intMinute = CInt(intMinute Mod 60) 
DecodePWpackeddate = (intYear) & "-" & Right(("00" & intMonth),2) &_ 
"-" & Right(("00" & intDay),2) & " " & Right(("00" & intHour),2) &_ 
":" & Right(("00" & intMinute),2) & " UTC" 
DecodePWpackeddate = "0000-00-00 00:00 UTC" '* no date 
End If 
End Function

DateTime format – ASCII-format

This format is used where more real-time clock data is needed. You also have seconds resolution. The  04 is a weekday indicator (already documented my Maarten, who documented this earlier. I did read that, but forgot when writing this entry).

SEND    0028 ... 194312 04 120511    [2011-05-12 12:43:19 UTC]
RECV    0000 ...

SEND    0029 ...
RECV    003A ... 204312 04 120511    [2011-05-12 12:43:20 UTC]

DateTime format – HEX-format

Below the command and reply (to a different command), 0016 / 003F that also has time information, but this time a different notation. Now there are three groups of hex-numbers that (after conversion to decimal) are hh, mm ss values. I have marked them in pink. The 04 value here is again a Day of Week value.

SEND    0016 … 0B0540DB FFFFFFFF FFFF 0C2B13 04

RECV    0000 ...

SEND    003E ...
RECV    003F ... 0C2B15 04 01457A

Codesample in VBscript

Function DecodeHexTime(ByVal strHexDoW, Byval strHexTime)
Dim intDoW
Dim intHour, intMinute, intSecond
intDoW = Cint("&H" & strHexDoW)
intHour = Cint("&H" & MID(strHexTime,1,2))
intMinute = Cint("&H" & MID(strHexTime,3,2))
intSecond = Cint("&H" & MID(strHexTime,5,2))
DecodeHexTime = Right(("00" & intHour),2) & ":" & Right(("00" &_
intMinute),2) & ":" & Right(("00" & intSecond),2) &_
" UTC (" & DayOfWeek(intDoW) & ")"
End Function

The other unknown value of the 003F response does not change much. I did see different values in 003F responses when setting a ‘schema’, but it’s meaning  is still a mystery for me.

So that concludes this post.

Categories: Domotica Tags: ,

Plugwise Protocol Analysis, Part 4 (Create Network)

15 May 2011 5 comments

I experimented with my PW network to find how to create a network, and add modules to it. So first I removed one module completely from my network using Source and did a full reset of that Plug. Then, a bit later, I discovered the PW diag util, and looked at it a bit. BTW, Diag does not find your comport by itself, you have to click on the … button, then everything is easy.

I also tried resetting a circle using Diag and by accident, did that too with my Circle+.  Ok, network gone. Wanted to test that anyway, but a bit unplanned for now. Ok great oppertunity to reconfigure my whole network. I made captures of most of this, some stil pending more detailed analisis. I soon had my circle+ and another circle in my network, but did not see my other plugs. I decided to reset them too with a hard-reset. They became visible again, and I added them back into the network.

Now I had a working system again, and also captures of what happened. No real analisis of what happened during network creation, but the logging is below. I do not yet  know why so many attempts are registered. The second Network PAN ID offer is accepted, through I cannot see why the first few failed, maybe just ‘timing’.

Note that 000D6F0000B835CB is the Stick and 000D6F0000B1B64B is the Circle+

Anyway, here is what I logged:

RECV 0000 000C 00C1
RECV 0011 000C 000D6F0000B835CB 01 00
SEND 0023 000D6F0000B835CB
RECV 0000 000D 00C1
RECV 0024 000D 000D6F0000B835CB 00000000 00000000 00 80 653907008510 4CCEC22A 00
SEND 004E 0000000000000000
RECV 0000 000E 00C1
RECV 0000 000F 00C1
RECV 0011 000F 000D6F0000B835CB 01 00
SEND 0023 000D6F0000B835CB
RECV 0000 0010 00C1
RECV 0024 0010 000D6F0000B835CB 00000000 00000000 00 80 653907008510 4CCEC22A 00
SEND 0023 000D6F0000B835CB
RECV 0000 0011 00C1
RECV 0024 0011 000D6F0000B835CB 00000000 00000000 00 80 653907008510 4CCEC22A 00
SEND 0023 000D6F0000B835CB
RECV 0000 0012 00C1
RECV 0024 0012 000D6F0000B835CB 00000000 00000000 00 80 653907008510 4CCEC22A 00

*** -=-Pair-=- *** (no offer made)
SEND 0001
RECV 0000 0013 00C1
RECV 0003 0013 00CE
RECV 0000 0014 00C1
RECV 0011 0014 000D6F0000B835CB 01 00
SEND 0023 000D6F0000B835CB
RECV 0000 0015 00C1
RECV 0024 0015 000D6F0000B835CB 00000000 00000000 00 80 653907008510 4CCEC22A 00

*** -=-Pair-=- *** (no offer made)
SEND 0001
RECV 0000 0016 00C1
RECV 0003 0016 00CE
RECV 0000 0017 00C1
RECV 0011 0017 000D6F0000B835CB 01 00
SEND 0023 000D6F0000B835CB
RECV 0000 0018 00C1
RECV 0024 0018 000D6F0000B835CB 00000000 00000000 00 80 653907008510 4CCEC22A 00

*** -=-Pair-=- *** (offer made, but not accepted)
SEND 0001
RECV 0000 0019 00C1
RECV 0003 0019 00CE
RECV 0000 001A 00C1
RECV 0011 001A 000D6F0000B835CB 01 00
SEND 0004 0000 0000000000000000 000D6F0000B1B64B
RECV 0000 001B 00C1
RECV 0061 FFFD 000D6F0000B835CB
RECV 0005 001B 0001
SEND 0023 000D6F0000B835CB
RECV 0000 0001 00C1
RECV 0024 0001 000D6F0000B835CB 00000000 00000000 00 80 653907008510 4CCEC22A 00

*** -=-Pair-=- *** (offer made, accepted)
SEND 0001
RECV 0000 0002 00C1
RECV 0003 0002 00CE
RECV 0000 0003 00C1
RECV 0011 0003 000D6F0000B835CB 01 00
SEND 0004 0000 0000000000000000 000D6F0000B1B64B
RECV 0000 0004 00C1
RECV 0061 FFFD 000D6F0000B835CB
RECV 0005 0004 0001

After this a full reply (0011) is receved
RECV 0000 0005 00C1
RECV 0011 0005 000D6F0000B835CB 01 01 060D6F0000B1B64B 1606 FF
SEND 0023 000D6F0000B1B64B
RECV 0000 0006 00C1
RECV 0024 0006 000D6F0000B1B64B 0B051AF6 00044D78 01 85 653907007324 4CCEBFA1 01
SEND 0026 000D6F0000B1B64B
RECV 0000 0007 00C1
RECV 0027 0007 000D6F0000B1B64B 3F7FA7CC 3F7FA7CC 3CD87C2F 00000000

So in the end the new NetworkID (Long PAN) is 060D6F0000B1B64B and the short network code is 1606. Stick and Circle+ can talk, other nodes can be added.

Categories: Domotica Tags: ,

Plugwise Protocol Analysis, Part 3

15 May 2011 3 comments

Adding a Module

Found that a Circle Module that is not part of the network advertises itself by periodically broadcasting it’s MAC with an associated CmdID of “0006“.

The Source Software responds with a “0007” message”, accepting or rejecting the Module. This could be a way to detect unconfigured plugs in your network.

Example (about every 75 seconds):

RECV 0006 002A 000D6F0000B1A240
SEND 0007 00 000D6F0000B1A240
RECV 0000 007C 00C1

A random ‘sequence number’ (002A) is used in the 0006 command, and the reply 0007 command has a regular sequence number (007C). The 0007 00 means that the module is rejected, but if the 0007 01 is send back, the module is added to the network, which is confirmed with an 0061 message from the module.

Here some samples from the analysed capture where a new module is accepted in the network:
RECV 0006 002B 000D6F0000D3595D
SEND 0007 01 000D6F0000D3595D
RECV 0000 00B0 00C1

Some time (and many unrelated messages) later:
RECV 0061 FFFD 000D6F0000D3595D

Seems the module is in the network. Some time (and again many unrelated messages) later, the module is already queried for usage data:
SEND 0023 000D6F0000D3595D
RECV 0000 00D3 00C1
RECV 0024 00D3 000D6F0000D3595D 0B051B43 00044D90 01 85 653907014023 4CCEC0C2 02

I have the impression that at the end of the current scan loop, the restart command 0008 01 is sent to finish this adding, but I an not sure if that is related to this Module Add.

Stil have to analyse more of the data I gathered while joining those plugs and what happens when you (re)configure the network. I already know that the commands 0001 to 0005 are used to create the network and associate the Stick to a Circle+, but that is for a later post.

To help analyse the capture logs I created with portmon,I wrote an (initially) small script in VBS to filter and format the request and reply messages I got.  The data between <5><5><3><3> and <cr><lf> is now nicely organized, the rest is disposed off. Now I’m adding to it formatting for the commands I know the structure of.


I see this kind of ‘resets’ in my logs, but still unsure why and what it does. Just documenting for now.
SEND 0008 01
RECV 0000 020F 00C1
RECV 0000 020F 00D9 000D6F0000B1B64B

I’ll ignore those until I see a patern.

In the plugwise source folder, there is a diag util. Nice to see what hapens in your network, and see how the plugwise developers named some of the data.

Categories: Domotica Tags: ,

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: , ,