Bug: ZCOMBO and HOME_HEALTH Alarm Type

Add-ons Bindings
1

I’m nearing completion of my OH2 migration and I started on the smoke detectors today. I’ve got my rules set up and shortly after I added the Items & Links, my whole house went nuts (my rules turn on all lights and set a repeating message on the Sonos system).

There are two different alarms for this device, the APPLIANCE alarm - type 12 and the HOME_HEALTH alarm - type 13. The APPLIANCE alarm is the actual alarm, the HOME_HEALTH alarm is a heartbeat that happens every hour. Unfortunately the current binding seems to support only OnOffType so both alarms set the Switch thing to ON. I know the 1.8 binding could set the Item to a Number which was what my old rule used to determine heartbeat from alarm but that isn’t an option with OH2, the link seems to only allow a Switch.

I don’t see any way to distinguish them in the rule so I’m not sure how to continue. @chris is this a known issue? If I need to file a bug, how would I do such a thing? It seems that the HOME_HEALTH alarm should be ignored.

relavant data:

Actual Alarm going off:

15:01:02.279 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0A 00 04 00 29 04 71 05 0C FF 5B
15:01:02.283 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
15:01:02.285 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0A 00 04 00 29 04 71 05 0C FF 5B
15:01:02.287 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0A 00 04 00 29 04 71 05 0C FF 5B
15:01:02.289 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 29 04 71 05 0C FF
15:01:02.290 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 41: Application Command Request (ALIVE:DONE)
15:01:02.291 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 41: Starting initialisation from DONE
5:01:02.293 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 41: Incoming command class ALARM
15:01:02.294 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 41: Received ALARM command V1
15:01:02.295 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 41: Process NOTIFICATION_REPORT V1
15:01:02.296 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 41: ALARM report - 12 = 255
15:01:02.299 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 41: Alarm Type = APPLIANCE (12)
15:01:02.301 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmValueEvent
15:01:02.304 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 41: Got an event from Z-Wave network: ZWaveAlarmValueEvent
15:01:02.306 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 41: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 255
15:01:02.309 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing ALARM
15:01:02.312 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 41: Updating channel state zwave:device:db95ddc3:node41:alarm_general to ON [OnOffType]

Heartbeat message (node48 is also a ZCOMBO, its just the first one to trigger since I started writing this):

15:40:08.252 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0A 00 04 00 30 04 71 05 0D FF 43
15:40:08.258 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
15:40:08.259 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0A 00 04 00 30 04 71 05 0D FF 43
15:40:08.261 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0A 00 04 00 30 04 71 05 0D FF 43
15:40:08.263 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 30 04 71 05 0D FF
15:40:08.264 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 48: Application Command Request (DEAD:DONE)
15:40:08.264 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 48: Node is ALIVE. Init stage is DONE.
15:40:08.265 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveNodeStatusEvent
15:40:08.266 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 48: Got an event from Z-Wave network: ZWaveNodeStatusEvent
15:40:08.267 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 48: Setting ONLINE
15:40:08.272 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 48: Node Status event - Node is ALIVE
15:40:08.273 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'zwave:device:db95ddc3:node48' changed from OFFLINE (COMMUNICATION_ERROR): Node is not communicating with controller to ONLINE
15:40:08.279 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 48: Starting initialisation from DONE
15:40:08.281 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 48: Incoming command class ALARM
15:40:08.281 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 48: Received ALARM command V1
15:40:08.282 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 48: Process NOTIFICATION_REPORT V1
15:40:08.285 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 48: ALARM report - 13 = 255
15:40:08.286 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 48: Alarm Type = HOME_HEALTH (13)
15:40:08.286 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmValueEvent
15:40:08.287 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 48: Got an event from Z-Wave network: ZWaveAlarmValueEvent
15:40:08.287 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 48: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 255
15:40:08.289 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing ALARM
15:40:08.289 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 48: Updating channel state zwave:device:db95ddc3:node48:alarm_general to ON [OnOffType]

The device XML:
node41.xml (5.0 KB)

2

I don’t have my zcombos back online yet so I can’t test, but when I did have it working I think I used the alarm_simple command class (something like that) and while I would see the hearbeats in the logs from the binding my Switch wouldn’t trigger except for the real alarm.

Of course, they have been offline for a couple months now (still rebuilding) so an update may have changed that (hope not).

Oh, 1.9 version or 2.0 version of the binding?

3

2.0 version which only has a channel for a ON/OFF Switch, I had them working with the 1.9 version on the old system. I tried going back to 1.9 to get my Schlage lock working but that caused so many errors, I think I’d have to delete all my ZWave Things and re-add them to downgrade.

4

The 1.9 version does not support Things.

5

yeah, sorry, typing without brain. I meant delete zwave things and re-add them in a .items file. Which still may be my plan.

6

Recently went back to the 2.1.0 version of the zwave binding and this is still an issue. in the 1.9 version, alarm type 13 was ignored (it put an error in the log whenever this heartbeat would go through).

I’ve uploaded a new xml file to the ZWave database that should hopefully fix this issue, it has 2 alarms in the alarmCommandClass node, one for HOME_HEALTH and one for APPLIANCE.

<entry>
      <commandClass>ALARM</commandClass>
      <alarmCommandClass>
        <version>1</version>
        <instances>1</instances>
        <versionSupported>1</versionSupported>
        <alarms>
          <entry>
            <alarmType>HOME_HEALTH</alarmType>
            <alarmState>
              <alarmType>HOME_HEALTH</alarmType>
              <reportedEvents/>
              <outer-class reference="../../../.."/>
            </alarmState>
          </entry>
          <entry>
            <alarmType>APPLIANCE</alarmType>
            <alarmState>
              <alarmType>APPLIANCE</alarmType>
              <reportedEvents/>
              <outer-class reference="../../../.."/>
            </alarmState>
          </entry>
        </alarms>
        <v1Supported>false</v1Supported>
        <isGetSupported>true</isGetSupported>
      </alarmCommandClass>
    </entry>