We have moved at community.getvera.com

Author Topic: Zwave 0x19 messages  (Read 2008 times)

Offline mtf

  • Jr. Member
  • **
  • Posts: 86
  • Karma: +0/-0
Zwave 0x19 messages
« on: February 05, 2012, 10:16:31 am »
I have been digging around for an explanation of the 0x19 zWave function that MiOS appears to generate all the time.

I haven't been able to find an explanation anywhere, but I believe I know what the structure is so I am putting it here for two reasons:

1) To make it easier for other people to follow

2) To ensure that if my understanding is incorrect somebody can correct me

My understanding of a request through this mechanism is as follows

Byte 0: Start of Frame (0x01)
Byte 1: Length of frame (11+n)
Byte 2: Request (0x00)
Byte 3: Function (0x19)
Byte 4: Node ID
Byte 5: Length of command in bytes (n)
Byte 6 onwards: Command
Byte 6+n onwards: Route through nodes (5 bytes with 0x00 padding at the end)
Byte 6+n+5: Callback ID
Byte 6+n+6: Checksum

The first byte of the command is the command class ID.

So for example this command:

0x01 0x0e 0x00 0x19 0x3a 0x03 0x20 0x01 0xff 0x05 0x00 0x00 0x00 0x00 0x6e 0x64

would be:

0x01: Start of frame
0x0e: Rest of message is 14 bytes long
0x00: A request
0x19: Mystery function (I assume it is in fact a function under which MiOS can determine routing of the command through the mesh)
0x3a: Message for node 58
0x03: Message is 3 bytes long
0x20: Command class is Basic
0x01: This is the Basic Command 'Set'
0xff: Set to level 255 (ie on for a switch)
0x05: Route the message through node 5
0x00: No further routing
0x00: No further routing
0x00: No further routing
0x00: No further routing
0x6e: Callback ID for the response
0x64: Checksum

The responses I have seen appear to be of the following forms (can anybody help shed some light?):

Byte 0: Start of frame (0x01)
Byte 1: Length of frame (4)
Byte 2: Response (0x01)
Byte 3: Function (0x19)
Byte 4: 0x01 (not sure what this means)
Byte 5: Checksum

Alternatively:

Byte 0: Start of frame (0x01)
Byte 1: Length of frame (5)
Byte 2: Request (0x00)
Byte 3: Function (0x19)
Byte 4: Callback ID sent previously
Byte 5: 0x00 (not sure what this is)
Byte 6: Checksum
« Last Edit: February 05, 2012, 02:52:48 pm by mtf »

Offline mtf

  • Jr. Member
  • **
  • Posts: 86
  • Karma: +0/-0
Re: Zwave 0x19 messages
« Reply #1 on: February 05, 2012, 06:38:04 pm »
I am no longer convinced that I understand the 5 bytes that I thought represented the route through the nodes.

I still think it probably is related to that if MiOS is supposedly constructing a route for these message, but I am no longer completely convinced, so their exact meaning remains a mystery.

The question is, if you have already constructed a message that incorporates the command to send to a z-Wave device what is left that you might want to send other than trying to define the route to and from the device?

It is perhaps possible that the 0x05 could be a bit field combination based on something like the more standard options where 0x01 would be a request for an ACK and 0x04 is auto route?

Does anybody have any further thoughts?
« Last Edit: February 05, 2012, 06:51:12 pm by mtf »

Offline guessed

  • Community Beta
  • Master Member
  • ******
  • Posts: 5301
  • Karma: +92/-22
  • Release compat is not a bolted-on afterthought
Re: Zwave 0x19 messages
« Reply #2 on: February 05, 2012, 07:30:58 pm »
I've never looked at this stuff in low-level, but on my Vera2 fw2.78, the frequent msgs use 0x13 codes instead of 0x19 like:
Code: [Select]
    41 02/05/12 16:15:42.874 ZWaveSerial::Send XXXX  node 79 using route 0.91.51.54 autoroute: 1 direct: 0 <0xc04>
    41 02/05/12 16:15:42.876 0x1 0xa 0x0 0x13 0x4f 0x3 0x43 0x2 0x1 0x5 0x52 0xbd (#\n##O#C###R#) <0xc04>

If I look at the logs in a more targetted manner, it looks like it's running "races" to see if various paths are functional or not:

Code: [Select]
41 02/05/12 16:26:42.071 ZWaveSerial::Send XXXX  node 79 using route 0.53.51.27 autoroute: 1 direct: 0 <0xc04>
41 02/05/12 16:26:42.325 ZWaveSerial::Send XXXX  node 79 using route 0.0.0.20 autoroute: 1 direct: 0 <0xc04>
41 02/05/12 16:26:42.583 ZWaveSerial::Send XXXX  node 79 using route 0.52.59.49 autoroute: 1 direct: 0 <0xc04>
41 02/05/12 16:26:42.734 ZWaveSerial::Send XXXX  node 79 using route 0.52.59.49 autoroute: 1 direct: 0 <0xc04>
41 02/05/12 16:26:42.934 ZWaveSerial::Send XXXX  node 79 using route 0.52.59.49 autoroute: 1 direct: 0 <0xc04>
41 02/05/12 16:26:43.114 ZWaveSerial::Send XXXX  node 79 using route 0.91.51.54 autoroute: 1 direct: 0 <0xc04>

It's also possible that these are "offsets" into a table of [ZWave] device Id's, so I wouldn't rely upon them being the exact device Id.  You'd probably need to look at a pattern of calls, over time, to see if there's similarity (ie. create a map)

Offline mtf

  • Jr. Member
  • **
  • Posts: 86
  • Karma: +0/-0
Re: Zwave 0x19 messages
« Reply #3 on: February 07, 2012, 08:49:10 am »
It's also possible that these are "offsets" into a table of [ZWave] device Id's, so I wouldn't rely upon them being the exact device Id.  You'd probably need to look at a pattern of calls, over time, to see if there's similarity (ie. create a map)

An excellent point and one I am actively looking into.

As I now recall it the z-Wave documentation does say that a 'controller' must be able to hold a table of routes.  It is easy to forget that MiOS is not the controller, just the software that talks to the controller.

Many thanks for your helpful insight.