ZWave Corrupted payload?

Tags: #<Tag:0x00007faed338b790>

Hi All

Having issues with a Aeotec ZW132 latest firmware.

It doesnt report the manual switch state, but works just fine otherwise.

When I use the manual switch, I see a corrupted payload message in the binding. I am using Hail CC for the Parameter 80 but ive tried the other settings also and still no switch state

Im using the latest development binding 2.5

Any thoughts as to why?



@ihp:/etc/openhab2$ tail -f /var/log/openhab2/zwave.log | grep "NODE 30"
25-Jul-2019 07:09:54.295 [TRACE] [nhab.binding.zwave.internal.protocol.SerialMessage] - NODE 30: Message payload = 00 1E 06 60 0D 02 01 82 01
25-Jul-2019 07:09:54.295 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 30: Application Command Request (ALIVE:DONE)
25-Jul-2019 07:09:54.296 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 30: resetResendCount initComplete=true isDead=false
25-Jul-2019 07:09:54.296 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 30: Decapsulating COMMAND_CLASS_MULTI_CHANNEL
25-Jul-2019 07:09:54.296 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 30: COMMAND_CLASS_MULTI_CHANNEL corrupted payload 60 0D 02 01 82 01
25-Jul-2019 07:10:03.344 [TRACE] [nhab.binding.zwave.internal.protocol.SerialMessage] - NODE 30: Message payload = 00 1E 06 60 0D 02 01 82 01
25-Jul-2019 07:10:03.345 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 30: Application Command Request (ALIVE:DONE)
25-Jul-2019 07:10:03.345 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 30: resetResendCount initComplete=true isDead=false
25-Jul-2019 07:10:03.345 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 30: Decapsulating COMMAND_CLASS_MULTI_CHANNEL
25-Jul-2019 07:10:03.345 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 30: COMMAND_CLASS_MULTI_CHANNEL corrupted payload 60 0D 02 01 82 01

When I set it to Basic CC

I see this:

kris@ihp:/etc/openhab2$ tail -f /var/log/openhab2/zwave.log | grep "NODE 30"
25-Jul-2019 07:13:41.294 [TRACE] [nhab.binding.zwave.internal.protocol.SerialMessage] - NODE 30: Message payload = 00 1E 07 60 0D 02 01 20 03 FF
25-Jul-2019 07:13:41.294 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 30: Application Command Request (ALIVE:DONE)
25-Jul-2019 07:13:41.294 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 30: resetResendCount initComplete=true isDead=false
25-Jul-2019 07:13:41.294 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 30: Decapsulating COMMAND_CLASS_MULTI_CHANNEL
25-Jul-2019 07:13:41.294 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 30: Incoming command class COMMAND_CLASS_BASIC, endpoint 2
25-Jul-2019 07:13:41.294 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 30: SECURITY not supported
25-Jul-2019 07:13:41.294 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 30: Received COMMAND_CLASS_BASIC V0 BASIC_REPORT
25-Jul-2019 07:13:41.294 [DEBUG] [ernal.protocol.commandclass.ZWaveBasicCommandClass] - NODE 30: Basic report, value = 255
25-Jul-2019 07:13:41.294 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 30: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
25-Jul-2019 07:13:41.294 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 30: Got a value event from Z-Wave network, endpoint=2, command class=COMMAND_CLASS_BASIC, value=255
25-Jul-2019 07:13:41.294 [TRACE] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 30: Checking channel=zwave:device:4296a94a:node30:switch_binary, cmdClass=COMMAND_CLASS_SWITCH_BINARY, endpoint=0
25-Jul-2019 07:13:41.295 [TRACE] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 30: Checking channel=zwave:device:4296a94a:node30:scene_number, cmdClass=COMMAND_CLASS_SCENE_ACTIVATION, endpoint=0
25-Jul-2019 07:13:41.295 [TRACE] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 30: Checking channel=zwave:device:4296a94a:node30:meter_voltage, cmdClass=COMMAND_CLASS_METER, endpoint=0
25-Jul-2019 07:13:41.295 [TRACE] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 30: Checking channel=zwave:device:4296a94a:node30:meter_watts, cmdClass=COMMAND_CLASS_METER, endpoint=0
25-Jul-2019 07:13:41.295 [TRACE] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 30: Checking channel=zwave:device:4296a94a:node30:meter_kwh, cmdClass=COMMAND_CLASS_METER, endpoint=0
25-Jul-2019 07:13:41.295 [TRACE] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 30: Checking channel=zwave:device:4296a94a:node30:meter_current, cmdClass=COMMAND_CLASS_METER, endpoint=0
25-Jul-2019 07:13:41.295 [TRACE] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 30: Checking channel=zwave:device:4296a94a:node30:meter_reset, cmdClass=COMMAND_CLASS_METER, endpoint=0
25-Jul-2019 07:13:41.295 [TRACE] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 30: Checking channel=zwave:device:4296a94a:node30:alarm_power, cmdClass=COMMAND_CLASS_ALARM, endpoint=0
25-Jul-2019 07:13:41.295 [TRACE] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 30: Checking channel=zwave:device:4296a94a:node30:alarm_heat, cmdClass=COMMAND_CLASS_ALARM, endpoint=0
25-Jul-2019 07:13:41.295 [TRACE] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 30: Checking channel=zwave:device:4296a94a:node30:time_offset, cmdClass=COMMAND_CLASS_CLOCK, endpoint=0
25-Jul-2019 07:13:41.295 [TRACE] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 30: Checking channel=zwave:device:4296a94a:node30:switch_binary1, cmdClass=COMMAND_CLASS_SWITCH_BINARY, endpoint=1
25-Jul-2019 07:13:41.295 [TRACE] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 30: Checking channel=zwave:device:4296a94a:node30:meter_voltage1, cmdClass=COMMAND_CLASS_METER, endpoint=1
25-Jul-2019 07:13:41.295 [TRACE] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 30: Checking channel=zwave:device:4296a94a:node30:meter_watts1, cmdClass=COMMAND_CLASS_METER, endpoint=1
25-Jul-2019 07:13:41.295 [TRACE] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 30: Checking channel=zwave:device:4296a94a:node30:meter_kwh1, cmdClass=COMMAND_CLASS_METER, endpoint=1
25-Jul-2019 07:13:41.295 [TRACE] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 30: Checking channel=zwave:device:4296a94a:node30:meter_current1, cmdClass=COMMAND_CLASS_METER, endpoint=1
25-Jul-2019 07:13:41.295 [TRACE] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 30: Checking channel=zwave:device:4296a94a:node30:switch_binary2, cmdClass=COMMAND_CLASS_SWITCH_BINARY, endpoint=2
25-Jul-2019 07:13:41.295 [TRACE] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 30: Checking channel=zwave:device:4296a94a:node30:meter_voltage2, cmdClass=COMMAND_CLASS_METER, endpoint=2
25-Jul-2019 07:13:41.295 [TRACE] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 30: Checking channel=zwave:device:4296a94a:node30:meter_watts2, cmdClass=COMMAND_CLASS_METER, endpoint=2
25-Jul-2019 07:13:41.295 [TRACE] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 30: Checking channel=zwave:device:4296a94a:node30:meter_kwh2, cmdClass=COMMAND_CLASS_METER, endpoint=2
25-Jul-2019 07:13:41.295 [TRACE] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 30: Checking channel=zwave:device:4296a94a:node30:meter_current2, cmdClass=COMMAND_CLASS_METER, endpoint=2
25-Jul-2019 07:13:41.295 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 30: Commands processed 1.
25-Jul-2019 07:13:41.295 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 30: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@64a70cca.

But still no state report

Regards

This is not mapped in the template to endpoint and channel. I don’t own one to test but it needs the template changing

There is no data in the encapsulated message from the device, so this is why it’s giving this error. This is a device error - you could try resetting it (ie power cycling) and it might start working.

I’ve now updated the newer version of this device to fix this.

Hi Chris

the corrupted was when i was using Hail, at the suggestion of Aeotec. I swapped back to Basic CC and no error, but it doesnt work.

Are you saying you have just made a binding change to resolve it and I need to update the binding ?

Cheers

Strange - I’m not sure why they would recommend that, but I’ve not really looked at your application. HAIL is not really a nice CC and isn’t really used a lot these days… Hey-ho…

I’ve just checked though and there is a bug with the length detection that prevents it working for HAIL which has a short payload - I’ll update this.

I’ve updated the database so you can use the BASIC option, but the binding is not updated yet.

1 Like

Thanks Chris, ill look out for the update of the binding. Appreciate the fast fixes!

Look here to see when it is updated

Then look here to get the binding if it is updated after the previous link.

1 Like

Its not the firmware, its a binding issue Chris is solving.

1 Like

If you use basic Chris has updated the template. There is no bug in the binding for Basic.

It was just the checkbox on the template needed setting. You could download and manually install if you want it working now.

You can see the 255 came through fine

but this checkbox was not set

so basic was not mapped to SWITCH_BINARY

Unfortunately, there was a bug in the way the short command classes (such as HAIL) were processed when encapsulated in the MC encap CC.

Anyway, it’s been fixed now :slight_smile:

Thanks gents I’ll update the binding tonight :+1::+1:

Unfortunately the issue is the same for me, the manual switch usage does not report the state :frowning: after updating to the latest binding

@robmac are you saying there is still an issue as it certainly appears there is

I’m not sure if the binding has been updated yet as builds have been broken for a couple of days.

ohhh

@chris It looks to me you last pushed 3 days ago & the snapshot was built a little over a day ago.


image

I haven’t checked - I know that the distribution has been broken for the past few days as we’ve been trying to fix it - parts of the build might have been successful, but parts are failing and I’m personally not sure how this comes together for the distribution these days.

Maybe @dastrix80 can provide a new log and I can take a look at what’s happening with the hail.

Im not using hail, i’m using basic cc. I will get a log for you:grinning:

The item is node 30, hopefully this shows something useful

zwav.txt (185.0 KB)