Firmware version 2 Plugwise protocol and POL 2.0

[zonique]

Please find a couple of additions below:

• The stick initialization command actually seems to be a command to verify whether the stick and Circle+ (plugwise stack) are up and running. It will return three values:
  - Up (yes/no) (2 bytes boolean 00 = false, everything else = true)
  - Extended pan ID (16 bytes)
  - Pan ID (4 bytes)
  PAN = Personal Area Network, that uniquely identifies the network. Zigbee devices make the decision on what radio networks to join based on their Pan ID.The Pan ID is determined by the Pan coordinator, the ZigBee device which is responsible for starting the formation of a ZigBee network. For as far as I understand, the Circl+ is Pluwise' Pan coordinator. There is only one ZigBee PAN Coordinator in any ZigBee network; it’s ZigBee address is always 0.

• The power information response indeed reports both power usage and production. Please find the returned data below:
  - 1s data - 4 bytes
  - 8s data - 4 bytes
  - Tick-count consumed - 8 bytes
  - Tick-count produced - 8 bytes
  - Remainder - 8 bytes

• The device information request indeed returns the fields you mentioned, the last field seems to indicate the module type. 01 indicates a regular plug-to-socket module.

• When you send a command to the Plugwise stack, it will produce two responses, the first one is an almost instantanous response from the Zigbee stack (in your document you called this response an acknowledgement). Usually this response is C1, which means Okay. There are other responses as well though. E.g. if you send an invalid command you will receive C2 or C3. The second response is the response from the module you sent the command to, which is not always that instantanous.
  
  This behaviour almost demands a certain threaded programming model. When a command is fired, the process should wait for the response from the Plugwise stack (synchronous) so that it can keep track of the request. It should not wait for the module response though, but should try to receive the module response asynchronously. This allows for commands to be sent off, while waiting for the various module responses (slow) to be received at the same time.

Maarten, perhaps it would be a nice idea to open-source this document, by uploading it to Google docs or something, so that all other experiences with the Plugwise protocol can be added to the document as well.

[RDNZL]

@Maarten, thanks.

Almost done coding the new stuff in DomotiGa, I have one comment, and two questions regarding the document.

In the chapter Calibration Request it says "The send request consist of the request code and the CRC checksum value.." this needs to be "The send request consist of the request code followed by the MAC address of the plug and the CRC checksum value..."

For the calculation of the current power usage, which pulses value do you use in the calculations?
I guess only the number of pulses based on a 1 second interval? Is this correct?

And which values are used for the timespantarget and source in the python example?
Anyone has converted this routine to vb yet and willing to share it?
I can read all values just fine now from my circle, but the calculation is not correct yet, the readouts are way off...

[RDNZL]

Is it correct that I get the same amount of pulses (the per second one) as the old firmware from the circles?
I thought it was more precise, like a 1000th of a watt?

[Bwired]

Anyone has converted this routine to vb yet and willing to share it?
I can read all values just fine now from my circle, but the calculation is not correct yet, the readouts are way off...

Hi Ron,
Perhaps this will help you:

Code: Select all

' Returns a corrected pulse value for later convert to kWh
Private Function PulseCorrection(pulses As Long, timespansource As Long, timespantarget As Long, GainA As Single, GainB As Single, OffTot As Single, offnoise As Single) As Single
    Dim res As Single
    Dim value As Single
    Dim temp As Single

    ' Check amount of pulses
    If pulses > 0 Then
        value = pulses / timespansource
        temp = value + offnoise
        res = timespantarget * ((temp ^ 2) * GainB + temp * GainA + OffTot)
    Else
        res = 0
    End If
    PulseCorrection = res
End Function

' Get KWh from Pulses
Private Function GetKWhFromPulses(pulses As Long, timespansource As Long, timespantarget As Long, calData As clsCircleCalInfo) As Single
    Dim res As Single

    ' Check pulses
    If pulses > 0 Then
        With calData
            res = 3600 * PulseCorrection(pulses, timespansource, timespantarget, .GainA, .GainB, .OffTot, .OffRuis)
            ' Now convert to KWh
            res = (res / 3600) / 468.9385193
        End With
    Else
        res = pulses
    End If
    ' Return result
    GetKWhFromPulses = res
End Function

[RDNZL]

@Bwired.
Thanks, it looks very similar to what I had in DomotiGa already, but a minor difference can have a big change ofcourse, will investigate more.

Where do you get timespansource and target from?
An example value?
How many pulses is 50 Watt roughly? Is it plm 19 or more than that?

[Bwired]

@Bwired.
Thanks, it looks very similar to what I had in DomotiGa already, but a minor difference can have a big change ofcourse, will investigate more.

Where do you get timespansource and target from?
An example value?
How many pulses is 50 Watt roughly? Is it plm 19 or more than that?

Code: Select all

res = PulseCorrection(CLng(pLatestPowerInfo), 8, 1, .GainA, .GainB, .OffTot, .OffRuis)

[RDNZL]

Ah, thanks...

[Bwired]

I see at random 0061 coming in without having to request for it.
It looks like a heartbeat (last Seen) for every Circle in the network
Looks like its pushed to the comport
So this could be very handy to check if all your circles are available without a request!

Can somebody confirm or test this also?

0061.png

[zonique]

Yup, have seen the same thing after upgrading to the latest firmware.

[Bwired]

OK Thanks Zonique
That is good News!
I will do some more testing when I'm at home (still in Italy now)
But I think Maarten can add this to the document.

[zonique]

I found something else interesting when you're interested in reverse engineering the Plugwise protocol.

Try to start the app using:

Code: Select all

"C:\Program Files\Plugwise\Plugwise Source\PlugwisePC.exe" /debug /trace=commands /trace=errors /trace=ports

If you do so, a nice suprise that obsoletes your serial port sniffer, will await you in directory:

Code: Select all

C:\Users\<username>\AppData\Local\Plugwise\Source\DB\tracing

Btw, the extra indicators in the center-bottom of the source app don't make sense to me yet. I'm strill trying to figure out their meaning.

[Bwired]

Thanks I will try out, let you know my findings in a while.
remote working is not that handy for these things, i'm in Italie now
If you have find any intrestings thing in there.......

[daromer]

How is it going with POL for v.2?

[JMcL]

Many thanks for all the hard work Maarten.

Some more observations on the version 2 protocols:

Firstly, there's an error response similar in format to the ACK:

Code: Select all

0000rrrr00E1cccc

   rrrr = response handle as returned by ACK
   cccc = CRC16 checksum


This indicates that the circle in question is not contactable (out of range, unplugged, etc)

Secondly, there seems to be a limit in the number of commands the MC can keep track of at a time when it's congested.

I'm working on a multi-threaded app which as it stands makes a number of simultaneous requests for power data (not by design as such). Sending the command and waiting for the ACK are synchronous, and the actual response is dealt with asyncrhonously when it arrives (based on response handle) leaving the app free to send other commands in the meantime, i.e. as soon as the ACK for the first command is received, the second command can then be sent.

This works well up to about 3 or 4 commands being queued simultaneously, but at that point responses seem to sometimes get dropped randomly. My current development setup is Circle+ and 5 Circles so 6 commands get queued simultaneously. All get sent and ACKed but I almost invariably have to retry 1 or often 2 of these as no response arrives. They almost always work on the first retry. From looking at the Domotiga source, I'm guessing the commands are completely synchronous, so issues shouldn't arise

I'm not sure what the cause is, perhaps it's due to the MC being swamped, or maybe wireless interference. I'm going to continue working on it as I need to make it a bit more robust, but if anybody has any insights, I'd be happy to hear them!

Regards,

John

[richard naninck]

Finally got my set and got most of it working. However I don't see the 0061 at all. Do I need to trigger something first?
Right now I am testing with the Circle+ and one extra Circle. Maybe it starts working when more Circles are attached. In that case I will get there later today..

I also see the Source software send a 004A000D6F0000xxxxxx3C01 -> Anybody?

I see at random 0061 coming in without having to request for it.
It looks like a heartbeat (last Seen) for every Circle in the network
Looks like its pushed to the comport
So this could be very handy to check if all your circles are available without a request!

Can somebody confirm or test this also?

0061.png