checksums?

[Mirar]

Is the checksums checked properly? I'm seeing a lot (well, several times a day) incoming data looking like this:

Code: Select all

[2015-02-08 19:50:21.465] [D] [zway] RECEIVED: ( 01 0C 00 04 00 02 06 31 05 03 0B 03 E9 25 )
[2015-02-08 19:50:21.465] [D] [zway] SENT ACK
[2015-02-08 19:50:21.466] [D] [zway] SETDATA devices.2.data.lastReceived = 0 (0x00000000)
[2015-02-08 19:50:21.466] [D] [zway] SETDATA devices.2.instances.0.commandClasses.49.data.3.deviceScale = 1 (0x00000001)
[2015-02-08 19:50:21.466] [D] [zway] SETDATA devices.2.instances.0.commandClasses.49.data.3.scale = 1 (0x00000001)
[2015-02-08 19:50:21.467] [D] [zway] SETDATA devices.2.instances.0.commandClasses.49.data.3.val = 256293.000000
[2015-02-08 19:50:21.480] [D] [zway] SETDATA devices.2.instances.0.commandClasses.49.data.3.scaleString = "Lux"
[2015-02-08 19:50:21.480] [D] [zway] SETDATA devices.2.instances.0.commandClasses.49.data.3 = Empty

This looks like something that should be caught by the checksum.
Is this check done in the Sigma controller or in z-way-server?

(I would try to say that it's only the Aoen Labs Multisensor that's buggy, and it might be, but I've also seen this kind of crap from a Philio Door Sensor and I think from the power meters, and that would be everything I have that gives numbers.)

(
The above session immediately continues with:

Code: Select all

[2015-02-08 19:50:21.516] [D] [zway] RECEIVED: ( 01 0C 00 04 00 02 06 31 05 03 0A 03 E8 25 )
[2015-02-08 19:50:21.517] [D] [zway] SENT ACK
[2015-02-08 19:50:21.517] [D] [zway] SETDATA devices.2.data.lastReceived = 0 (0x00000000)
[2015-02-08 19:50:21.517] [D] [zway] SETDATA devices.2.instances.0.commandClasses.49.data.3.deviceScale = 1 (0x00000001)
[2015-02-08 19:50:21.518] [D] [zway] SETDATA devices.2.instances.0.commandClasses.49.data.3.scale = 1 (0x00000001)
[2015-02-08 19:50:21.518] [D] [zway] SETDATA devices.2.instances.0.commandClasses.49.data.3.val = 1000.000000
[2015-02-08 19:50:21.521] [D] [zway] SETDATA devices.2.instances.0.commandClasses.49.data.3.scaleString = "Lux"
[2015-02-08 19:50:21.521] [D] [zway] SETDATA devices.2.instances.0.commandClasses.49.data.3 = Empty

So it's easy to spot the bit errors:

[2015-02-08 19:50:21.465] [D] [zway] RECEIVED: ( 01 0C 00 04 00 02 06 31 05 03 0B 03 E9 25 )
[2015-02-08 19:50:21.516] [D] [zway] RECEIVED: ( 01 0C 00 04 00 02 06 31 05 03 0A 03 E8 25 )

)

[pofs]

Checksum is calculated by XOR-ing all the bytes in packet, and (0x0B ^ 0xE9) == (0x0A ^ 0xE8) == 0xE2, so resulting checksum will be the same for both packets. Unfortunately, one-byte checksum is not really reliable.

This might happen not only because of buggy devices, but also because of some radio noise. We would be happy to get rid of it, but there's pretty much nothing we actually can do.

[Mirar]

Checksum is calculated by XOR-ing all the bytes in packet, and (0x0B ^ 0xE9) == (0x0A ^ 0xE8) == 0xE2, so resulting checksum will be the same for both packets. Unfortunately, one-byte checksum is not really reliable.

This might happen not only because of buggy devices, but also because of some radio noise. We would be happy to get rid of it, but there's pretty much nothing we actually can do.

Gah. You mean the designers of z-wave use one of the more useless checksums there is? That explains the crap packets I'm seeing all the time. Couldn't they at least have gone for a normal CRC16, if they didn't feel like investigating modern checksums?

I guess there's zero chance this will be improved in the future, since it's so deep in the protocol.

I guess z-way-server can't request a re-send either by not sending an ACK? It should be possible to at least use heuristics to spot double-one-bit errors comparing the current packet to the previous.

If not, can the data packet be exposed in the Zwave JSON API so I can do it myself? It'll be more reliable than using a median filter and cutting away sensors that doesn't exist.

[pofs]

You mean the designers of z-wave use one of the more useless checksums there is?

Yeah, they are

Couldn't they at least have gone for a normal CRC16, if they didn't feel like investigating modern checksums?
I guess there's zero chance this will be improved in the future, since it's so deep in the protocol.

There's a CRC16 command class for that, but currently only a few devices actually support it. But it is a requirement for ZWave+ certification, so it's likely new devices could be more reliable.

I guess z-way-server can't request a re-send either by not sending an ACK?

It is a firmware who sends radio ACK. Serial API ACK is actually only for serial communication, so it is impossible to pretend the packet was not delivered on software level (and probably even on firmware level too).

If not, can the data packet be exposed in the Zwave JSON API so I can do it myself?

Unfortunately, no. Would be too much overhead.