Archive
Plugwise Protocol Analysis, Part 6 (Firmware update observations)
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
- Network ID changed (modified circle+ address)
- Before update
- LongPAN:060D6F0000B1B64B
- ShortPAN:1606
- After update
- LongPAN:8A0D6F0000B1B64B
- ShortPAN:3B8A
- Before update
- 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
RECV 0060 00DE CircleMAC FFFFFFFFFFFFFFFE
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
Conclusion
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.
Plugwise Protocol Analysis, Part 5 (Date/Time)
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"
Else
DecodePWpackeddate = "0000-00-00 00:00 UTC" '* no date
End If
End FunctionDateTime 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.
Plugwise Protocol Analysis, Part 4 (Create Network)
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:
SEND 000A
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
SEND 000A
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
SEND 000A
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
SEND 000A
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 0002 0019 0F FFFFFFFFFFFFFFFF 520D6F0000B1B64B FFFFFFFFFFFFFFFF 520D6F0000B1B64B 5D52 01
RECV 0003 0019 00CE
SEND 000A
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 0002 0002 0F FFFFFFFFFFFFFFFF 060D6F0000B1B64B FFFFFFFFFFFFFFFF 060D6F0000B1B64B 1606 01
RECV 0003 0002 00CE
SEND 000A
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
SEND 000A
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.
Plugwise Protocol Analysis, Part 3
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.
NB.
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.
Plugwise Protocol Analysis, Part 2
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! no reply received!
r 0000 0312 00C1
! 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).
Plugwise Protocol Analysis, Part 1
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.
Initialisation
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
R 0049 0054 000D6F0000B1B5B6 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 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.
Timing
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.
Roel's technical notepad 