When a command packet is sent to the stick, the first reponse from the stick is a line in the form:

PutFifoUnicast 33 : Handle 129 : 000D6F0000xxxxB3

The ‘129′ in the line above is specific to the command sent. From what I’ve implemented it’s as follows:

PowerChange (code=0017) : 33
PowerInfo (code=0012) : 23
Calibration (code=0026) : 60

I presume other commands will also follow this pattern.

The handle returned is the value (in decimal) of the packet sequence Deep refers to and will be used on the subsequent ACK and data packets, so the conversation is now along the lines of (leaving out frame start/ends and inserting spaces for clarity – CCCC represents CRC):

SEND: 0017 000D6F0000xxxxB3 CCCC
RECV: PutFifoUnicast 33 : Handle 129 : 000D6F0000xxxxB3
RECV: 0000 0081 00C1 CCCC (note ‘0081′ = 129)
RECV: 0000 0081 00D8 00D8000D6F0000xxxxB3 CCCC

I guess this could be useful to optimise access to plugs. Fire a command, get the handle, and then keep track of responses received, leaving you free to send other commands in the meantime (Note: I haven’t tried this yet, it’s purely speculation!!!)

I would like to receive more information on the new protocol version :)
Can you perhaps e-mail me some code, so I can adjust my Perl scripts ?
I am using XPL-Perl with plugwise.pm and already made some adjustments.

Thnx,

Ronald

If you want this info, reply to me via PM

i have analize the protocol deep and have discovered a number of things not documented (or documented as unkown) in your describe.

by example, you miss ack from stick in pol.py code and yor describe

Send code
003E000D6F000055XXXXBF07

but, you miss ack data
00000D5200C11699 [len=21]

0000 in first pkt after send instruction means ACK

0D52 is pkt sequence #

00C1 looks like status = OK

1699 = CRC

Look next packet…

003F 0D52 000D6F0000552XXX 13 25 35 04 01 457A 0EFF

003F = resp code

0D52 = same as pkt seq above

So, correct processing is:

TX CMD:

003E000D6F000055XXXXBF07

RX ACK:

00000D5200C11699

RX RESP:

003F0D52000D6F0000552XXX1325350401457A0EFF

but look at ACK and RESP pkt, 0D52 is common in chars 4..8

Look at long sniff, you see chars 4..8 increment 1 by one this is packet sequence.

So protocol is 3 packets:

Send to stick
Stick ACK
Data returns

can also be OOB datas – valid RX packet is:

PACKET DATAS

you can also RX datas without , and these are OOB data’s

I have pythn script to find this and strip

ALso, if you send invalid command to stick, you get error response

do send packet like 004A000D6F000055XXXX

and you get ack with SEQ number

then error packet

000000Ex1699

where 00Ex is error code of some type – if good request, is 00C1

I have more infos from dig – maybe you like to pm me and I tell more.

Oh, I also know how to detect association plugs like Olli wants

bye

Does anyone know if there is a command to get the mac addresses for the plugs in the first place? Or is it always case of manually adding them in from the stickers on the plugs?

very interesting information! Currently I’m using the Plugwise devices with the old firmware in combination with MisterHouse to control some devices in my home.

Were you able to read out the power consumption history of the Circles with the new version of the firmware? I’d like to be able to get hold of this info so that I can add some monitoring to my automation environment.

Keep on the good work!