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.
Roel's technical notepad 
Interesting.
Roheve, ever captured the communication that goes on when you select “broadcast” switching in Source? it seems to be possible to switch On/Off groups of devices using a broadcast mechanism
Yes I did. But I am not sure about what I captured, as there where 2 types of groups when I defined those. I do not remember exactly what type of group was I used when switching the group in that capture.
I now only seem to use schedule-groups. On thing I do know; For the group a new ‘fake mac-address’ is generated and used in the same way as for circles, just that more than one circle responded to it. But that was a year ago, and before the firmware update. Things might have changed (as there are now more types of group).
It appears that the Circle plugs can store a set of on/off switch times and turn themselves on and off without having the Source running (no USB stick in operation).
Do you know what the commands are to set up the table of timings? (I assume it is some sort of table, and that the settings can be interrogated).