class 0x41 Prepayment Encapsulation

[piet66]

I have a question of understanding.

According to my Z-Wave Sniffer, Z-Way all the time sends packets with class=0x41 and command=0x7F to all possible devices, example: 0x0B0B0B0B018104122C0B1027417F7F7F7F3C.

According to the specification, class 0x41 is Prepayment Encapsulation.

Is my analysis correct? And what's the purpose of that behavior? In some cases, there are several hundreds of those packets per hour.

These packets do not appear to show up in the Zniffer history.

[lanbrown]

If you look at the Z-Wave docs, it is under metering. So while prepayment doesn't make much sense, it is probably just a reuse of an existing class. Then the command of 0x71F states this:

Command SwitchBinary Set
Syntax: Set(value, duration = 0xff, successCallback = NULL, failureCallback = NULL)
C Syntax: ZWError zway_cc_switch_binary_set(ZWay zway, ZWNODE node_id, ZWBYTE instance_id, ZWBOOL value, ZWBYTE duration, ZJobCustomCallback successCallback, ZJobCustomCallback failureCallback, void* callbackArg)
Description: Send SwitchBinary Set
Parameter value: Value
Parameter duration: Duration of change:. 0 instantly. 0x01...0x7f in seconds. 0x80...0xfe in minutes mapped to 1...127 (value 0x80=128 is 1 minute). 0xff use device factory default
Parameter successCallback: Custom function to be called on function success. NULL if callback is not needed
Parameter failureCallback: Custom function to be called on function failure. NULL if callback is not needed
Report: level updated

I believe the Zniffer history is also what say Z-Way has requested compared to to say what the Z-Wave protocol does behind the scenes.

[piet66]

After one more digging into the Z-Wave specification, I think I found the explanation:
It's only a route ack with extended header. What I thought to be the command class is simply a part of the extension.

[lanbrown]

Z-Wave is a very ACK happy protocol. It really is the only way it knows that what was sent was received. If you look at the 300, 500 and then 700 series specs, there is very little memory. So all it really can do is send a packet and wait for an ACK before the next packet. One reason why OTA can take sometime on remote devices as well; one packet, then when it gets received, the destination needs to send an ACK back to the destination so the next packet can be sent. So the longer the RTT then longer the OTA is going to take.

Glad you found your answer.

[Fantini Dzherardo]

Thank you for the explanation, it helped a lot to understand!