Eurotronic_spirit_00_000 - channel alarm_system is not implemented

Hi.
Environment:
Linux/Docker/OPANHAB3.1/Eurotronic Spirit

Problem:
In accordance with eurotronic_spirit_00_000.xml

     <channel id="alarm_system" typeId="alarm_system">
        <label>Alarm (system)</label>
        <properties>
          <property name="binding:*:OnOffType">COMMAND_CLASS_ALARM;type=SYSTEM</property>
        </properties>
      </channel>
      <channel id="alarm_power" typeId="alarm_power">
        <label>Alarm (power)</label>
        <properties>
          <property name="binding:*:OnOffType">COMMAND_CLASS_ALARM;type=POWER_MANAGEMENT</property>
        </properties>
      </channel>

These channels are never updated.

openhab.log part:

2022-04-21 19:10:50.631 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 12 00 04 00 0A 0A 71 05 00 00 00 FF 09 03 01 04 B5 00 D8 
2022-04-21 19:10:50.633 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=10, callback=0, payload=00 0A 0A 71 05 00 00 00 FF 09 03 01 04 B5 00 
2022-04-21 19:10:50.635 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=10, callback=0, payload=00 0A 0A 71 05 00 00 00 FF 09 03 01 04 B5 00 
2022-04-21 19:10:50.635 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2022-04-21 19:10:50.636 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 10: Application Command Request (ALIVE:DONE)
2022-04-21 19:10:50.637 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 10: resetResendCount initComplete=true isDead=false
2022-04-21 19:10:50.638 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 10: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2022-04-21 19:10:50.639 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 10: SECURITY NOT required on COMMAND_CLASS_ALARM
2022-04-21 19:10:50.640 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 10: Received COMMAND_CLASS_ALARM V8 NOTIFICATION_REPORT
2022-04-21 19:10:50.641 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 10: NOTIFICATION report - 0 = 0, event=3, status=255, plen=1
2022-04-21 19:10:50.643 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 10: Alarm Type = SYSTEM (0)
2022-04-21 19:10:50.644 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2022-04-21 19:10:50.645 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_ALARM, value=255
2022-04-21 19:10:50.646 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 10: Alarm converter processing NOTIFICATION
2022-04-21 19:10:50.647 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 10: Alarm converter NOTIFICATION event is 3, type OnOffType
2022-04-21 19:10:50.648 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 10: Alarm converter NOTIFICATION event is 3, channel alarm_system is not implemented.
2022-04-21 19:10:50.649 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 10: Alarm converter processing NOTIFICATION
2022-04-21 19:10:50.650 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 10: Alarm converter NOTIFICATION event is 3, type OnOffType
2022-04-21 19:10:50.651 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 10: Commands processed 1.
2022-04-21 19:10:50.651 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 10: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@70aa0823.
2022-04-21 19:10:50.652 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-04-21 19:10:50.653 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-04-21 19:10:50.654 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2022-04-21 19:10:50.655 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

There are 2 issues there:

ZWaveAlarmConverter is called twice probably due to eurotronic_spirit_00_000.xml contains 2 channes with property “class=COMMAND_CLASS_ALARM”.

Expected to be called only once due to “COMMAND_CLASS_ALARM;type=SYSTEM” and not “COMMAND_CLASS_ALARM;type=POWER_MANAGEMENT”

channel alarm_system is not implemented

Patching eurotronic_spirit_00_000.xml brings “more/less” desired behavior.

      <channel id="alarm_system" typeId="**alarm_number**">
        <label>Alarm (system)</label>
        <properties>
          <property name="binding:*:**DecimalType**">COMMAND_CLASS_ALARM;type=SYSTEM</property>
        </properties>
      </channel>
      <channel id="alarm_power" typeId="**notification_power_management**">
        <label>Alarm (power)</label>
        <properties>
          <property name="binding:*:**DecimalType**">COMMAND_CLASS_ALARM;type=POWER_MANAGEMENT</property>
        </properties>
      </channel>

Test performed for :

  • POWER_MANAGEMENT__REPLACE_BATTERY_NOW(“POWER_MANAGEMENT”, 11)
  • SYSTEM__HARDWARE_FAILURE_MANUFACTURER_CODE(“SYSTEM”, 3) ~ 0x03 Valve closing point could not be detected
    Due to “issue 1)” , the test values(11,3) have been passed every time to both channels.

Any comments?

For a first-time poster, you seem to have some expertise. I’m not the zwave guru here, but I’ll give some info that might help. The zwave db is here and is OH community maintained. As such, the device may not be configured in the best way. I do not have this device but reading the documentation and looking at the binding java class files (can be found here) it might be better to have the system_alarm channel as alarm_number. You can register for the site and then send a ticket to @chris (The zwave guru) for write access, then change that channel. (based on what you have done, you could also modify the xml in the .jar to see if it works first)

The reason I think that way is from these snippets in the alarm converter class. (I’m also not a java expert, but these looks like it might work.

  1. Alarm_number case
    alarm_number.txt (180 Bytes)

  2. Table of codes.
    converter-options.txt (1.4 KB)

  3. Section of code with the message “Not implemented”
    alarmcases.txt (2.4 KB)

Hope that helps a little.

Bob

Thank u Bob for comments.
Ref .device doc.: Spirit_Z-Wave_Plus_Installation-and-Operation-Guide_web.pdf

I tried to identify a problem in the code with github handbook and yes I did the modify jar file prior writing the post as u can read in section “Test performed for:” , but this is just a neutralization of “issue 2)”.

Test “REPLACE_BATTERY_NOW” ( using week/discharged batteries)

2022-04-24 16:18:24.123 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=10, callback=0, payload=00 0A 09 71 05 00 00 00 FF 08 0B 00 AB 00
2022-04-24 16:18:24.127 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2022-04-24 16:18:24.128 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 10: Application Command Request (ALIVE:DONE)
2022-04-24 16:18:24.129 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 10: resetResendCount initComplete=true isDead=false
2022-04-24 16:18:24.130 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 10: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2022-04-24 16:18:24.131 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 10: SECURITY NOT required on COMMAND_CLASS_ALARM
2022-04-24 16:18:24.132 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 10: Received COMMAND_CLASS_ALARM V8 NOTIFICATION_REPORT
2022-04-24 16:18:24.133 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 10: NOTIFICATION report - 0 = 0, event=11, status=255, plen=0
2022-04-24 16:18:24.135 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 10: Alarm Type = POWER_MANAGEMENT (0)
2022-04-24 16:18:24.136 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2022-04-24 16:18:24.137 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_ALARM, value=255
2022-04-24 16:18:24.138 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 10: Alarm converter processing NOTIFICATION
2022-04-24 16:18:24.139 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 10: Alarm converter NOTIFICATION event is 11, type DecimalType
2022-04-24 16:18:24.141 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Updating channel state zwave:device:controller1:node10:alarm_system to 11 [DecimalType]
2022-04-24 16:18:24.143 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 10: Alarm converter processing NOTIFICATION
2022-04-24 16:18:24.150 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 10: Alarm converter NOTIFICATION event is 11, type DecimalType
2022-04-24 16:18:24.151 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Updating channel state zwave:device:controller1:node10:alarm_power to 11 [DecimalType]
2022-04-24 16:18:24.152 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 10: Commands processed 1.
2022-04-24 16:18:24.161 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 10: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@51face1.
2022-04-24 16:18:24.162 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-04-24 16:18:24.162 [INFO ] [g.openhab.core.model.script.Obyvacka] - 23.72|21.0|0%|mode=1|KOMFORT
2022-04-24 16:18:24.163 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-04-24 16:18:24.165 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2022-04-24 16:18:24.166 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

Test “HARDWARE_FAILURE_MANUFACTURER_CODE” (demount TRV)

2022-04-24 15:34:28.796 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=10, callback=0, payload=00 0A 0A 71 05 00 00 00 FF 09 03 01 02 AD 00
2022-04-24 15:34:28.797 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 38: [WAIT_DATA] priority=Immediate, requiresResponse=true, callback: 0
2022-04-24 15:34:28.798 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 10: Application Command Request (ALIVE:DYNAMIC_VALUES)
2022-04-24 15:34:28.800 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 10: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2022-04-24 15:34:28.801 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 10: SECURITY NOT required on COMMAND_CLASS_ALARM
2022-04-24 15:34:28.802 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 10: Received COMMAND_CLASS_ALARM V8 NOTIFICATION_REPORT
2022-04-24 15:34:28.803 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 10: NOTIFICATION report - 0 = 0, event=3, status=255, plen=1
2022-04-24 15:34:28.805 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 10: Alarm Type = SYSTEM (0)
2022-04-24 15:34:28.806 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2022-04-24 15:34:28.807 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_ALARM, value=255
2022-04-24 15:34:28.809 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 10: Alarm converter processing NOTIFICATION
2022-04-24 15:34:28.810 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 10: Alarm converter NOTIFICATION event is 3, type DecimalType
2022-04-24 15:34:28.812 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Updating channel state zwave:device:controller1:node10:alarm_system to 3 [DecimalType]
2022-04-24 15:34:28.814 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 10: Alarm converter processing NOTIFICATION
2022-04-24 15:34:28.815 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 10: Alarm converter NOTIFICATION event is 3, type DecimalType
2022-04-24 15:34:28.817 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Updating channel state zwave:device:controller1:node10:alarm_power to 3 [DecimalType]
2022-04-24 15:34:28.819 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 10: Commands processed 1.
2022-04-24 15:34:28.820 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 10: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@40f6782d.
2022-04-24 15:34:28.821 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 10: Command NOT verified org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@40f6782d.
2022-04-24 15:34:28.822 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 1
2022-04-24 15:34:28.823 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 1
2022-04-24 15:34:28.825 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2022-04-24 15:34:28.826 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.

I found many posts here with attached logs where one single ALARM message updates several channels “issue 1)”.
example:105799

Github also commanded me to write post here first where more people may read it.
When we reach common understanding, I will try to write an issue in github.

Reviewing this fresh in the morning, the good news is I think I understand (better anyway). The not so good news, although more people may read it here (like myself), I think this gets into the details of the zwave binding that only @chris will be able to address. He should see it here as well as on github, so there is no need to duplicate it there.

To recap #1- I don’t know why both alarm channels (power_management & system) are being updated with the same event number. There are many devices with 2 or more channels of a command class that update each channel specifically.

As to #2, prior the change to Decimal in the XML, did the Power_management channel work okay as OnOffType? I’m thinking this code snippet in the file above

       case "notification_power_management":
            return new DecimalType(eventAlarm.getAlarmEvent());

would extract the value 11 as a decimal and update the state. Looking at the bytes of the system alarm above,

FF 09 03

The FF is the ON/OFF, the 09 is the system and 3 is the event

Possibly rather than switch the binding property, something like this could be added

       case "notification_system":
            return new DecimalType(eventAlarm.getAlarmEvent());

To extract the event.

Anyway that’s all I have.

Bob

Bob

As to #2, prior the change to Decimal in the XML, did the Power_management channel work okay as OnOffType? I’m thinking this code snippet in the file above

As u may see in the original eurotronic_spirit_00_000.xml
typeId=“alarm_power” but NOT “notification_power_management” and the channel binding:*:OnOffType
so probably not reaching this case at all if no additional mapping from alarm_power → alarm_number done. Finally channel was not updated probably due to missing conversion DecimalType → OnOffType

Configs are designed to be changed rather then code.

Regarding issue 1)

Potential problem in ZWaveAlarmConverter.java

    private State handleNotificationReport(ZWaveThingChannel channel, ZWaveAlarmValueEvent eventAlarm) {

        // Don't trigger event if this item is bound to another event type
        // if (alarmType != null && AlarmType.valueOf(alarmType) != eventAlarm.getAlarmType()) {
        // return null;
        // }

If designer has same view I suggest to update in

    public State handleEvent(ZWaveThingChannel channel, ZWaveCommandClassValueEvent event) {

and remove from

    private State handleAlarmReport(ZWaveThingChannel channel, ZWaveAlarmValueEvent eventAlarm, String alarmType) {
        // Don't trigger event if this item is bound to another alarm type
        if (alarmType != null && AlarmType.valueOf(alarmType) != eventAlarm.getAlarmType()) {
            return null;
        }

The concern I had with my question is that the report is first an ON/OFF, then the reason. Won’t the power_management channel still update to 11 when the device sends the all-clear (idle) notification (00 08 0B)? from my reading of the zwave Notification CC specifications that message is going to be sent.

As to the “case”:

What I see above is neither. This is the governing property

so maybe, maybe not. The System channel notification definitely goes through that “case” screen because the DEBUG message (channel alarm_system is not implemented) is the default if no “case” is found

Anyway best to wait for Chris at this point.

Bob

I neutralized it.

STEPS(Linux):

  1. download source code
    $ wget https://github.com/openhab/org.openhab.binding.zwave/archive/refs/heads/3.1.x.zip

  2. unzip source
    $ unzip 3.1.x.zip

  3. Modify ZWaveAlarmConverter.java
    $ vi org.openhab.binding.zwave-3.1.x/src/main/java/org/openhab/binding/zwave/internal/converter/ZWaveAlarmConverter.java

  4. Modify spirit_00_000
    $ vi org.openhab.binding.zwave-3.1.x/src/main/resources/OH-INF/thing/eurotronic/spirit_0_0.xml

  5. compile/make a package
    $ cd org.openhab.binding.zwave-3.1.x
    org.openhab.binding.zwave-3.1.x$ mvn clean install

  • this process may take some minutes due to dependencies download
  1. copy xxx.jar to openhab/addon/
    6.1 remove z-wave binding from OH
    6.2 org.openhab.binding.zwave-3.1.x$ cp target/org.openhab.binding.zwave-3.1.2-SNAPSHOT.jar /openhab/addons/

  2. Test

Patches:
spirit_patch.txt (2.1 KB)
ZWaveAlarmConverter_patch.txt (2.0 KB)

Example: