First Alert Zcombo-G - channel alarm_system is not implemented

Hi @chris

Thanks for adding the Z-Combo-G Smoke and CO detector to the database so quickly. I updated the binding and the device is discovered properly and I see the expected channels:

  • Alarm (System);
  • Alarm (Smoke)
  • Alarm (CO)
  • Battery-level

The item attached to the Battery-level channel updates properly, but I am not getting data in the other items. Each hour, I see a log entry for the detector’s heartbeat with a message: channel alarm_system is not implemented. I’m not sure how to handle this.

2020-09-30 13:34:07.955 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 16: Received COMMAND_CLASS_ALARM V8 NOTIFICATION_REPORT
2020-09-30 13:34:07.956 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 16: NOTIFICATION report - 0 = 0, event=5, status=255, plen=0
2020-09-30 13:34:07.956 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 16: Alarm Type = SYSTEM (0)
2020-09-30 13:34:07.956 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2020-09-30 13:34:07.956 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_ALARM, value=255
2020-09-30 13:34:07.956 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 16: Alarm converter processing NOTIFICATION
2020-09-30 13:34:07.956 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 16: Alarm converter NOTIFICATION event is 5, type OnOffType
2020-09-30 13:34:07.956 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 16: Alarm converter NOTIFICATION event is 5, channel alarm_system is not implemented.
2020-09-30 13:34:07.957 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 16: Alarm converter processing NOTIFICATION
2020-09-30 13:34:07.957 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 16: Alarm converter NOTIFICATION event is 5, type OnOffType
2020-09-30 13:34:07.957 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 16: Alarm converter processing NOTIFICATION
2020-09-30 13:34:07.957 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 16: Alarm converter NOTIFICATION event is 5, type OnOffType
2020-09-30 13:34:07.957 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 16: Commands processed 1.

The binding defines each alarm channel as a switch but the device sends more than on/off messages:

Event of device Channel Notification Type Notification Event
Test detected Alarm (Smoke) 0x01 0x03
Test clear Alarm (Smoke) 0x01 0x00
Smoke detected Alarm (Smoke) 0x01 0x02
Smoke clear Alarm (Smoke) 0x01 0x00
Smoke silence Alarm (Smoke) 0x01 0x06
CO detected Alarm (CO) 0x02 0x02
CO clear Alarm (CO) 0x02 0x00
CO silence Alarm (CO) 0x02 0x06
CO End-Of-Life detected Alarm (CO) 0x02 0x05
Malfunction detected Alarm (System) 0x09 0x01
Malfunction clear Alarm (System) 0x09 0x00
Heartbeat Alarm (System) 0x09 0x05

I appreciate your guidance on how I should proceed.
Thanks,
Bruce

The Z-Wave specification in the database lost me. @chris will need to interpret forus.

I looked through the ZWaveAlarmConverter class on GitHub and it looks beyond what I should be trying to address.

It seems there is a mapping that is created to covert the Notification events received from the detector. The mapping relates events received to the ON/OFF state of the device channel in OpenHab. If I understand this correctly, I won’t see the details of the event in OpenHab. For instance, if the smoke alarm changes from ON to OFF I won’t know if this is because smoke is no longer detected or if someone pressed the snooze button.

From other discussion topics in the forum, there seems to be an alarm (raw) channel on some door locks. Is this something that I can create in the z-wave database for the Zcombo-G in addition to the existing channels or would I create it in place of the existing channels? Something like this:

Yes, you should be able to do this. It doesn’t need to replace existing channels.

That said, what are you wanting to do? Generally, the raw channel is not useful - you can use it in rules, but that is it. If you want to see the alarms, and use them in a UI, or rules, it is best to define the alarms as alarm channels and not just the raw channel. The raw channel was added to allow locks to report things like who opened the door - I don’t see the need for that here.

Why do you want to handle it? It is not something you should worry about - just because a device sends a message, does not mean that the user needs to do something with it.

Right now I see the event in the logs but the related item has no value - I was assumed (maybe badly) it was tied to the channel not implemented message. I was thinking that a rule to notify if the heartbeat has not been heard in a while might be a good idea. It also looks like the alarm_system channel will report if the device detects a malfunction. I thought writing a rule to notify me of the event is a good idea.

I’d like to distinguish between events in rules. Is the alarm on because it is a test is running or smoke is detected? Is the alarm off because the snooze button was pressed or smoke is no longer detected?

I don’t think there is a related item for this message, and I don’t think there should be one - it’s not really a user oriented feature.