Zwave HSM02 channel not updating

Add-ons Bindings
1

I’m using a door/window sensor that’s labeled Hawking HRDS1, which is being detected by the zwave binding as an Everspring HSM02.

When the HSM02 contact closure is activated or deactivated, the channel is not being updated. Here’s the debug for the HSM02.

2016-06-11 14:48:28.379 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 08 03 20 01 00 D8
2016-06-11 14:48:28.381 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2016-06-11 14:48:28.382 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 04 00 08 03 20 01 00 D8
2016-06-11 14:48:28.382 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 04 00 08 03 20 01 00 D8
2016-06-11 14:48:28.383 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 08 03 20 01 00
2016-06-11 14:48:28.383 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 8: Application Command Request (ALIVE:DONE)
2016-06-11 14:48:28.384 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 8: Starting initialisation from DONE
2016-06-11 14:48:28.384 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@ff31dd already registered
2016-06-11 14:48:28.385 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 8: Incoming command class BASIC
2016-06-11 14:48:28.385 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 8: Received Basic Request
2016-06-11 14:48:28.386 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 8: Basic Set sent to the controller will be processed as Basic Report
2016-06-11 14:48:28.386 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 8: Basic report, value = 0x00
2016-06-11 14:48:28.386 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2016-06-11 14:48:28.387 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2016-06-11 14:48:28.387 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got a value event from Z-Wave network, endpoint = 0, command class = BASIC, value = 0
2016-06-11 14:48:28.388 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=8, callback=113, payload=08 02 84 08
2016-06-11 14:48:28.389 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 08 03 20 01 00
2016-06-11 14:48:28.389 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationCommandHandler, callback id=113, expected=SendData, cancelled=false MISMATCH

In comparison, with my Fibaro FGK-101 door/window sensor, the channel is being updated. Here’s the debug log for the FGK101.

2016-06-11 14:00:09.392 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 0C 03 30 03 FF 31
2016-06-11 14:00:09.394 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2016-06-11 14:00:09.395 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 04 00 0C 03 30 03 FF 31
2016-06-11 14:00:09.396 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 04 00 0C 03 30 03 FF 31
2016-06-11 14:00:09.397 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 0C 03 30 03 FF
2016-06-11 14:00:09.398 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 12: Application Command Request (ALIVE:DONE)
2016-06-11 14:00:09.398 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 12: Starting initialisation from DONE
2016-06-11 14:00:09.399 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@e7135a already registered
2016-06-11 14:00:09.400 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 12: Incoming command class SENSOR_BINARY
2016-06-11 14:00:09.400 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 12: Received SENSOR_BINARY command V1
2016-06-11 14:00:09.401 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 12: Sensor Binary report, type=Unknown, value=255
2016-06-11 14:00:09.402 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveBinarySensorValueEvent
2016-06-11 14:00:09.403 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 12: Got an event from Z-Wave network: ZWaveBinarySensorValueEvent
2016-06-11 14:00:09.403 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 12: Got a value event from Z-Wave network, endpoint = 0, command class = SENSOR_BINARY, value = 255
2016-06-11 14:00:09.404 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 12: Updating channel state zwave:device:154acc671d8:node12:sensor_door to OPEN [OpenClosedType]
2016-06-11 14:00:09.407 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=12, callback=236, payload=0C 02 84 08
2016-06-11 14:00:09.408 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 0C 03 30 03 FF
2016-06-11 14:00:09.409 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationCommandHandler, callback id=236, expected=SendData, cancelled=false MISMATCH
2016-06-11 14:00:09.411 [INFO ] [marthome.event.ItemStateChangedEvent] - zwave_device_154acc671d8_node12_sensor_door changed from CLOSED to OPEN
2016-06-11 14:00:09.418 [INFO ] [marthome.event.ItemStateChangedEvent] - Kitchen_FGK101_DoorSensor changed from CLOSED to OPEN

Note that there is no updating “updating channel state” line for node 8 like there is for node 12.

I’m running the OH2 build from 6/9/2016 and Habmin version 0.1.6, 2016-06-05.

2

Looking at the thing definition (sorry for the poor formatting), it appears the channel is defined using SENSOR_BINARY, whereas the device is generating a BASIC_SET.

@chris If you think this is a bug, I can open an issue on GitHub.

Thanks for pointing me to your handy log viewer. I immediately was able to see what was going on. :slight_smile:

{“statusInfo”:{“status”:“ONLINE”,“statusDetail”:“NONE”},“label”:“Z-Wave Node 8: HSM02 (Driveway Motion)”,“bridgeUID”:“zwave:serial_zstick:154acc671d8”,“configuration”:{“action_heal”:“-232323”,“config_1_2”:255,“config_2_1”:1,“action_reinit”:“-232323”,“wakeup_node”:1,“action_failed”:“-232323”,“wakeup_interval”:14400,“group_1”:[“node_1_0”],“action_remove”:“-232323”,“config_3_1”:0,“binding_pollperiod”:“1800”,“group_2”:},“properties”:{“zwave_class_basic”:“ROUTING_SLAVE”,“zwave_class_generic”:“BINARY_SENSOR”,“zwave_neighbours”:“”,“zwave_frequent”:“false”,“zwave_version”:“1.0”,“zwave_listening”:“false”,“zwave_deviceid”:“1”,“zwave_nodeid”:“8”,“zwave_routing”:“true”,“zwave_wakeup_time”:“2016-06-11T16:54:27Z”,“zwave_beaming”:“false”,“zwave_class_specific”:“ROUTING_SENSOR_BINARY”,“zwave_manufacturer”:“96”,“zwave_devicetype”:“514”},“UID”:“zwave:device:154acc671d8:node8”,“thingTypeUID”:“zwave:everspring_hsm02_00_000”,“channels”:[{“linkedItems”:[“Driveway_HSM02_MotionSensor”,“zwave_device_154acc671d8_node8_sensor_binary”],“uid”:“zwave:device:154acc671d8:node8:sensor_binary”,“id”:“sensor_binary”,“channelTypeUID”:“zwave:sensor_binary”,“itemType”:“Switch”,“label”:“Binary Sensor”,“defaultTags”:,“properties”:{“binding::OnOffType":“SENSOR_BINARY”},“configuration”:{}},{“linkedItems”:[“zwave_device_154acc671d8_node8_battery_level”,“Driveway_HSM02_BatteryLevel”],“uid”:“zwave:device:154acc671d8:node8:battery-level”,“id”:“battery-level”,“channelTypeUID”:“system:battery-level”,“itemType”:“Number”,“defaultTags”:[],“properties”:{"binding::PercentType”:“BATTERY”},“configuration”:{}},{“linkedItems”:[“zwave_device_154acc671d8_node8_alarm_general”],“uid”:“zwave:device:154acc671d8:node8:alarm_general”,“id”:“alarm_general”,“channelTypeUID”:“zwave:alarm_general”,“itemType”:“Switch”,“label”:“Alarm”,“defaultTags”:,“properties”:{“binding:*:OnOffType”:“ALARM”},“configuration”:{}}]}

3

If you can edit the database, then just go into the editor, and in the SENSOR_BINARY command class, tick the box that says “Treat as Basic”. This way, either command class will be used for this channel. While the device might report using BASIC now, at other times, it might use SENSOR_BINARY. This ensures both are supported.

4

I don’t think I have the ability to edit.

Note that this needs to be done for both the HSM02 and the SM103.

5

Ok - no probs. I’ll update today and it should be in tomorrows snapshot.

6

For reference, it’s in this PR -:

7

Much appreciated. Thanks for doing that.

In the future, if you’re comfortable giving me edit rights, I could make these changes. There likely will be some additional devices that I’ll want to add to the database as well.

8

Sure - no problem. I’ve updated your access…

Thanks.
Chris

9

One last question. Once I’ve installed the latest build, what do I need to do to have the changed reflected in the thing. Do I need to do an exclude/include on the device, or is there another way to accomplish it without having to do that? Thanks.

10

Nevermind, I see. In Habmin, just delete the thing, then run discovery again.

11

Exactly what I would have said :wink:.