Understanding Z-Wave packet format / logging

Developer's Corner General Dev Discussions
1

Hi,

Can anybody help me understand the Z-wave singlecast message and ACK responses that the Vera 2 is logging?

I have a Z-wave node ID 2 which is a boiler actuator… When that is turned on I see the Z-wave logging (Tx on level 41, Rx on level 42)

Sending On

 ZWaveSerial::Send XXXX  node 2 using route 255.99.114.105 autoroute: 0 direct: 1 <0xc04>
41      12/08/11 17:04:51.582   0x1 0xe 0x0 0x19 0x2 0x3 0x40 0x1 0x1 0x11 0x0 0x0 0x10 0x0 0xc4 0x6c (######@########l) <0xc04>
42      12/08/11 17:04:51.631   0x6 0x1 0x4 0x1 0x19 0x1 0xe2 (#######) <0x1406>
42      12/08/11 17:04:51.631   got expected ACK <0x1406>
41      12/08/11 17:04:51.632   ACK: 0x6 (#) <0x1406>
42      12/08/11 17:04:51.681   0x1 0x5 0x0 0x19 0xc4 0x0 0x27 (######') <0x1406>
41      12/08/11 17:04:51.681   ACK: 0x6 (#) <0x1406>
04      12/08/11 17:04:51.694   <Job ID="1516" Name="HeatOn node 2" Device="3" Created="11-12-08 17:04:50" Started="11-12-08 17:04:50" Completed="11-12-08 17:04:51" Duration="1.153301000" Runtime="1.151106000" Status="Successful" LastNote="Transmit was ok" Node="2" NodeType="ZWaveThermostat" NodeDescription="Combi Boiler"/> <0x803>

The Z-Wave frame format discussed here is as follows

Home ID (32-bit?)
Source Node ID (byte)
Frame Header (??)
Length (byte)
Destination Address (byte)
Data (n bytes)
Checksum

Now the logged transmitted bytes are as follows:

0x1 0xe 0x0 0x19 0x2 0x3 0x40 0x1 0x1 0x11 0x0 0x0 0x10 0x0 0xc4 0x6c

I would guess the 0x01 0x0E 0x00 0x19 is the Home ID
I can see that the 0x02 is the destination node (but it seems to be in the source node byte?)
Also that the 0x03 is the data length
Then the 0x40 0x01 0x01 is the Command Class ID (0x40 - thermostat, 0x01 - set, 0x01 - on)

Q. But then where is the Source ID? Surely it should be 0x01 somewhere?

Q. I also can’t see why the additional bytes are there 0x11 0x0 0x0 0x10 0x0 0xc4 0x6c. Presumably one is a CRC but why the rest?

Q. Further to that I understand the ACKs should be a singlecast message back from the destination node with a zero data length but I don’t see anything like that logged?

From the protocol spec, for the ACK I would expect something like 0x1 0xe 0x0 0x19 0x02 0x0 0x01 0xXX

Thanks, Alex

2

Unless of course the protocol that is logged is some dongle specific version that is subtly different from the Z-Wave protocol itself?

3

I see, it looks as though the logging is the same as dongle protocol logging here - ZWave API - LinuxMCE

So an Rx log starting with 0x06 is an ACK and an 0x01 is a response, so I need to be looking at 0x01 lines for status responses to get commands I guess?

4

OK so if I send a thermostat mode command class get request -

41      12/08/11 18:02:43.251   0x1 0xd 0x0 0x19 0x2 0x2 0x40 0x2 0x11 0x0 0x74 0x0 0xc1 0x61 0x6c (#\r####@###t##al) <0xc04>

Then I get some kind of ACK response

42      12/08/11 18:02:43.281   0x6 0x1 0x4 0x1 0x19 0x1 0xe2 (#######) <0x1406>

And then I get some kind of response response

42      12/08/11 18:02:43.330   0x1 0x5 0x0 0x19 0x61 0x0 0x82 (####a##) <0x1406>

And then I get another response response

42      12/08/11 18:02:43.381   0x1 0x9 0x0 0x4 0x0 0x2 0x3 0x40 0x3 0x0 0xb0 (#######@###) <0x1406>

What’s interesting is that the second response contains the 0x40 0x03 0x00 that I’m looking for. The 0x40 being the command class, the 0x03 being the “report” type and the 0 being “off”

So that’s looking good I think. If I do that again with the boiler actuator on to double check I get

42      12/08/11 18:07:02.781   0x1 0x9 0x0 0x4 0x0 0x2 0x3 0x40 0x3 0x1 0xb1 (#######@###) <0x1406>

So there’s the 0x01 indicating the state is on.

The 0x02 is probably the source node, and the 0x03 is the following data length I would think…

If I can do this with the climate mode schedule command then I may be able to work out how to configure these Danfoss LC units…

5

How are you sending these commands over Z-wave?

6

Some more notes from my testing:

First issue a Changed Get to see if there’s anything we need to know about (0x46 0x04)

0x1 0xd 0x0 0x19 0x5 0x2 0x46 0x4 0x5 0x0 0x0 0x0 0x0 0xc4 0x6f

Response is changed report with status 0 (0x46 0x06) nothing changed (so this shows the command class is supported)

0x1 0x9 0x0 0x4 0x0 0x5 0x3 0x46 0x5 0x0 0

Next let’s look at the report for thursday (0x04 - days are 1 relative starting at monday)

0x1 0xe 0x0 0x19 0x5 0x3 0x46 0x2 0x4 0x5 0x0 0x0 0x0 0x0 0xf6 0x5d

0x1 0x24 0x0 0x4 0x0 0x5 0x1e 0x46 0x3 0x4 0x0 0x0 0x7f 0x0 0x0 0x7f 0x0 0x0 0x7f 0x0 0x0 0x7f 0x0 0x0 0x7f 0x0 0x0 0x7f 0x0 0x0 0x7f 0x0 0x0 0x7f 0x0 0x0 0x7f 0xfa

Working through this we’ve got

0x01 - response ?
0x24 0x00 0x04 0x00 - would like to know about these
0x05 - source node ID
0x1E - length
… Data …
0xFA - CRC

Looking at the data:

0x46 - Climate Control Schedule Command Class
0x03 - Report
0x04 - Day (Thursday)
0x0 0x0 0x7f - 0x7F so all unused
0x0 0x0 0x7f
0x0 0x0 0x7f
0x0 0x0 0x7f
0x0 0x0 0x7f
0x0 0x0 0x7f
0x0 0x0 0x7f
0x0 0x0 0x7f
0x0 0x0 0x7f

–

I think the whole “setback” business means the scheduler reduces the temperature by the configured amount from the setpoint

So, if I then set the thursday temperatures to (say)

06:00 Setback 5C (*.1) = 0x32
09:00 Setback 0C = 0
23:00 0x79 - frost protection

That translates to

@intveltr - Use this format. IP address will need to be set to your Vera and the Node ID will need to change, but the rest of the URI should be ok.

http://192.168.1.116:49451/data_request?id=lu_action&DeviceNum=1&serviceId=urn:micasaverde-com:serviceId:ZWaveNetwork1&action=SendData&Node=5&Data=x46-x1-0x4-0x6-0x00-0x32-0x09-0x00-0x00-0x17-0x00-0x79-0x00-0x00-0x7f-0x00-0x00-0x7f-0x00-0x00-0x7f-0x00-0x00-0x7f-0x00-0x00-0x7f-0x00-0x00-0x7f

(we seem to have to set all 9 entries for this to work)

Then request schedule for thursday

http://192.168.1.116:49451/data_request?id=lu_action&DeviceNum=1&serviceId=urn:micasaverde-com:serviceId:ZWaveNetwork1&action=SendData&Node=5&Data=x46-x2-0x4

0x1 0x24 0x0 0x4 0x0 0x5 0x1e 0x46 0x3 0x4 0x6 0x0 0x32 0x9 0x0 0x0 0x17 0x0 0x79 0x0 0x0 0x7f 0x0 0x0 0x7f 0x0 0x0 0x7f 0x0 0x0 0x7f 0x0 0x0 0x7f 0x0 0x0 0x7f 0xd6

So that looks like it is working…

7

Now that I have some vague ideas on how to analyse the Tx and Rx packets that are logged I’m going to move back over to the Danfoss Living Connect thread as that’s what I’m trying to talk to here…

8
Next let's look at the report for thursday (0x04 - days are 1 relative starting at monday) [code] 0x1 0xe 0x0 0x19 0x5 0x3 0x46 0x2 0x4 0x5 0x0 0x0 0x0 0x0 0xf6 0x5d

0x1 0x24 0x0 0x4 0x0 0x5 0x1e 0x46 0x3 0x4 0x0 0x0 0x7f 0x0 0x0 0x7f 0x0 0x0 0x7f 0x0 0x0 0x7f 0x0 0x0 0x7f 0x0 0x0 0x7f 0x0 0x0 0x7f 0x0 0x0 0x7f 0x0 0x0 0x7f 0xfa
[/code]

Here are the results for my Danfoss RA PLUS-w:

0x1 0xa 0x0 0x13 0x8b 0x3 0x46 0x2 0x4 0x5 0x49 0x62 

0x1 0x24 0x0 0x4 0x0 0x8b 0x1e 0x46 0x3 0x4 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0xb

Not sure what to conclude from this. Would be nice to have access to the Z-Wave specification …

[tt]ZWave API - LinuxMCE

9

I’m out of my element here, but I did find this link to a series of articles that might give you some of the information that you’re looking for.

[url=http://www.digiwave.dk/en/programming/an-introduction-to-z-wave-programming-in-c/]http://www.digiwave.dk/en/programming/an-introduction-to-z-wave-programming-in-c/[/url]

Dave

10

Thanks for that Dave, it’s an interesting sequence of articles. It seems primarily focussed on a developer who wants to understand how to put a comms. handler in place in C# implementing the Z-Wave protocol - which is a useful thing itself. I think what I need is the protocol specification for the Z-wave serial communications protocol (which the article mentions). This seems different from the over the air protocol itself, which I guess is to be expected. I can’t spot that anywhere and am wondering if it’s only available with a purchase of a Z-Wave SDK.

Alex

11

I’m trying to figure out the specific command to query the firmware version directly.
I’ve tried something like this , but it doesn’t seem to work.
http://192.168.1.234:49451/data_request?id=lu_action&DeviceNum=1&serviceId=urn:micasaverde-com:serviceId:ZWaveNetwork1&action=SendData&Node=60&Data=x86-x11-25

Any ideas ?

12

Version report: x86-x11

Command class report for class x25: x86-x13-x25

[tt]http://open-zwave.googlecode.com/svn-history/r185/trunk/cpp/src/command_classes/Version.cpp[/tt]