Zwave binding - alarm_general

Zylle · February 16, 2023, 1:42pm

I’m beginning to venture into adding/editing things in the zwave database.

But before i cause havoc in there, there are a few things I’d like to understand first:

I’ve seen a few devices that use the alarm_general channel - one example is the Aeotec Multisensor 6.
The documentation states that it has the following notifications

However in the database the only notification that is sent is alarm_general:

Yet I still get the notifications for motion. But according to the documentation, as far as I understand, there should be 2 channels for the binding to work. 1 with alarm_motion, and 1 with alarm_tamper.

I’ve tried looking looking at the alarm converter in the Zwave binding: [org.openhab.binding.zwave/ZWaveAlarmConverter.java at main · openhab/org.openhab.binding.zwave · GitHub]
And I cannot find anything regarding the alarm_general - where can I see how this works?

And if I edit the database, remove the alarm_general, and add 2 entries, for alarm_motion, and alarm_tamper, will that mean everybody that have a Multisensor 6, when they download a new version of the database, they have to make changes to their OH setup to have these 2 new channels?

apella12 · February 16, 2023, 2:36pm

The situation is a little complex because there are 4 versions of the Multisensor 6. Three of which are set up as you describe. I see no issue in changing the version 1.6 if that is the model you have.

When the binding is changed you have to delete (not exclude) the device and rescan to pick up the changes. So anyone with the 1.6 device will not “see” the changes unless they do that.

I’m not a super expert, but in setting up a channel the CAPITALIZED item is the first Byte (see the AlarmCommandClass and the lower case channel with the underline is the second (Alarm converter). I’m not sure the event=x is needed (if there is no ambiguity with the lower case channel type) because I have seen it both with and without, but doesn’t seem to hurt. In the case below the binding will process hex 07 03 notification message
Alarm question1

Hope that helps

Zylle · February 16, 2023, 3:36pm

Yes - that did help…mainly in that i haven’t noticed the other 3 versions of the multisensor .
But mine is running v1.10 - which is setup correctly. So no need to change that. Bad example on my part, but valuable lesson to learn - thanks!
I’ve still left to figure out how the binding handles alarm_general channel, as I can’t find that anywhere in the binding code.

So perhaps a better example here is the Aeotec ZWA009:
From the documentation the notifications are as follows:

The database entries are below:

Again the “Alarm alarm_general” is there, doing something…or is it?

apella12 · February 16, 2023, 4:27pm

I probably should have said “I only have a basic knowledge”…

the general alarm code (0) is in the internal/protocol/commandclass/ folder. I haven’t analyzed the code to see how it reacts to the various sub codes. It might just trigger on all of them. Also note there are different versions of alarm. V1 and V2 are more limited in what they can do, so that might have been the historical reason for general.

anon71759204 · February 16, 2023, 6:14pm

TBH, the Z-Wave specification for alarms/notifications is a complete mess:

grafik

The alarm types for the alarm command class are defined in org.openhab.binding.zwave/ZWaveAlarmCommandClass.java at main · openhab/org.openhab.binding.zwave · GitHub.

Zylle · February 16, 2023, 6:26pm

So do I understand it correctly, that the alarm_general is an umbrella term to catch all the prior alarms that are somehow not compatible with newer versions or are not specifically mapped?

Or put in another way - if I come across a newer device (using Notification CC V8), that has alarm_general, then it is fine to edit the entry to provide the correct alarm type - and this will not make breaking changes in the channels within OH so any triggers, rules etc still will work as intended?

The latter part in breaking changes is not so much for my sake, but I’d hate knowing that any changes I make may cause others setups to not work, without letting them know of the breaking changes, and how to remedy them.

anon71759204 · February 16, 2023, 6:58pm

I’m afraid only reading the source code will tell …

I get the impression that the community doesn’t like changes that cause previously working equipment to fail - even if there are workarounds that could be applied to accomodate the changes.

apella12 · February 16, 2023, 7:00pm

So I admire your enthusiasm. Maybe I’m too conservative, but I do not edit the DB unless I have the device or if there is an issue in the forum, generally with a Debug so I can see the byte string. Kind of “if it’s not broke philosophy”. That way I never have to worry.

anon71759204 · February 16, 2023, 7:04pm

Well said.

@Zylle
Could you point us to a device in the Z-Wave database that claims to support ALARM_VX, X > 3, and has a channel alarm_general?

Zylle · February 16, 2023, 8:06pm

@apella12 but I do not edit the DB unless I have the device or if there is an issue in the forum

Just for reference, nothing in my discussion is about devices I don’t have - it is only concerning channels that in my regard are not working as they are intended for devices I, also own. And to me that implies understanding the mechanism at work within the binding so I know what changes, before I change them.

@anon71759204
These 2 devices:
Aeotec AerQ v1
https://opensmarthouse.org/zwavedatabase/1336

Aeotec AerQ v2
https://opensmarthouse.org/zwavedatabase/1437

I assume it is becuase they use the weather notification which is not supported by the binding currently. At least the channel does not work as intended, which is why I’d like to know what the alarm_general does, because it may mean the channel is used for more than just the weather notification, and changing this in the database, may then break things for other users.

apella12 · February 16, 2023, 9:24pm

Apologies. The way I read your post was that you were going to through all the devices and change alarm_general.

Anyway I think we need a higher power @chris to weigh in regarding Alarm Converter & the channels. For instance take the Alarm type=WEATHER of the ZWA039. It is in the Alarm CC, but there are no sub variations in the AlarmConverter. So will the channel alarm_general (or any of the other channels) pick up when the device sends (02-Moisture Alarm)? Would defining the type=WEATHER, event=2 and then using the alarm_general channel work any better? I’ve always been unsure if the channels map to a specific event within an ALARM type or can they be used for multiple events.

EDIT: Trying to explain my last comment, consider post number two above. Is type=BUGLAR, event=3 redundant when the channels is alarm_tamper because alarm_tamper is ALWAYS event =3?

anon71759204 · February 16, 2023, 9:29pm

Weather Alarm - Moisture Alarm (0x10 - 0x02) (>= V7)
Power management - Replace battery now (0x08 - 0x0b) (>= V3)
Heat Alarm - Overheat Unknown Location (0x04 - 0x02) (>= V2)
Heat Alarm - Underheat Unknown Location (0x04 - 0x06) (>= V2)

Source code:

Weather Alarm: not handled by AlarmConverter
Power management: → alarm_battery / POWER_MANAGEMENT
Heat Alarm: → alarm_heat / HEAT

Z-Wave database:

alarm_general / type=WEATHER
alarm_power / type=POWER_MANAGEMENT
alarm_heat / type= HEAT

Summary:

Wrong definition for ‘Replace battery now’ notification in the Z-Wave database
Not sure about the Weather Alarm …

Zylle · February 17, 2023, 6:42am

I’ve already made the changes in the database to correct this for the alarm_power.

For the heat alarm, there are 2 events on this channel - so an answer to this I’m also keen on knowing how this is handled.

Zylle · February 17, 2023, 7:31am

On a side note - absolutely no need to apologize - I reach out, you try and help, that is the buttom line, and I appreciate the insight and help!

Here I would disagree, as when looking at the handling of alarm_tamper in the binding code:

There are some entries of type BURGLAR, but alarm_tamper is also enabled by type=SYSTEM:

And as to the event, alarm_tamper channel is activated with all these events, so these may be type=BURGLAR and event= 3/4/9 will all set this channel ON, the same goes for type=SYSTEM, event=6, and as far as my understanding goes, the alarm_tamper channel does not, and can not, distinguish between which events trigger the channel. It will regardless of trigger be send command ON. As a consequence, if a device is to implement a tamper alarm with a notification type=BURGLAR, event=3, and notification type=SMOKE event=3 (smoke alarm test), and a type=SYSTEM event=6 - the binding, and therefore the user could not distinguish between them, as they would all be ON the same channel in OH (I have not seen a device which does implement the same alarm types for different physical events - which is also why I think the smoke alarm test was added to this alarm type
Please correct me if I am wrong.

chris · February 18, 2023, 3:01am

I’ve not read through everything here, so apologies if I’ve missed something (almost certainly)…

For the most part, the channel type is irrelevant when it comes to matching the notifications from a device - it is used to send the notification to the OH side, but mostly isn’t used to decode/decide on the alarms being processed. That uses the configuration data that you see in the database. IF there’s no config data (as I think might often be the case for the alarm_general case) then probably it will match all alarms (but that’s a guess as I’ve not checked this recently).

Now I did say “mostly” above - as you have seen there are some direct links between channel types and notifications for some of the more standard notifications.

The alarms/notifications in ZWave is unfortunately a bit of a mess as the spec was changed from ALARM to NOTIFICATION, and there was a bit of an attempt to try and standardise data at that point, but devices can still use the old notifications and their use is generally up to the manufacturer.

Zylle · February 18, 2023, 9:06am

BLUF:
There are 2 issues:

Issue 1:
I have 2 items in the database that have alarm_general:
Aeotec AerQ v1
https://opensmarthouse.org/zwavedatabase/1336

Aeotec AerQ v2
https://opensmarthouse.org/zwavedatabase/1437

This should be a Weather Notifcation class, but that class is not implemented in the binding:

Will the alarm_general of the items, catch this, and only this, so it can be distinguished from the other notifications?

Issue 2:

If a device has several notifications of the same type in the binding eg. the heat alarms above, the types are the same, but different events. They both (should) trigger the alarm_heat notification within the binding. As far as I understand, there is no way for OH, and the user to distinguish between the 2 notifications, because they only trigger the channel to send the command ON. But as a user I’m very interested in knowing whether the heat alarm is Overheat or Underheat.

anon71759204 · February 18, 2023, 3:12pm

Excerpt from Blog Posts :

A referral to OH1 items doesn’t help much nowadays. What is missing is a description of the Config settings.

apella12 · February 18, 2023, 5:50pm

I wasn’t sure about my request above since @chris can be quite busy with his real job, so I put alarm_tamper through its paces on an Zooz ZSE43. I can verify that it does not matter if Config is empty, has type=BURGLAR or type=Burglar, event=3 they all work. Also trying to force another alarm type as the channel (I used alarm_burglar or alarm_general) will not work even if the config is type=BURGLAR, event=3.

I also ran a test on a Zooz ZSE44 (Humidity and Temperature) that has both high and low triggers. In the DB the Alarm is alarm_heat for temperature and alarm_general for humidity. The alarm_heat works, but again the alarm_general does not. The device is using WEATHER (0x10) (event=6) for low humidity and that is not in the binding at this time. The debug file is below.

Temp & heat alarm

2023-02-18 10:44:14.614 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0F 00 A8 00 01 12 06 31 05 01 2A 02 C5 00 A5 30 
2023-02-18 10:44:14.616 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=BridgeApplicationCommandHandler[168], type=Request[0], dest=18, callback=0, payload=00 01 12 06 31 05 01 2A 02 C5 00 A5 
2023-02-18 10:44:14.617 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=BridgeApplicationCommandHandler[168], type=Request[0], dest=18, callback=0, payload=00 01 12 06 31 05 01 2A 02 C5 00 A5 
2023-02-18 10:44:14.617 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2023-02-18 10:44:14.618 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Application Command Request (ALIVE:DONE)
2023-02-18 10:44:14.618 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: resetResendCount initComplete=true isDead=false
2023-02-18 10:44:14.618 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: Incoming command class COMMAND_CLASS_SENSOR_MULTILEVEL, endpoint 0
2023-02-18 10:44:14.619 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: SECURITY not supported
2023-02-18 10:44:14.619 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 18: Received COMMAND_CLASS_SENSOR_MULTILEVEL V10 SENSOR_MULTILEVEL_REPORT
2023-02-18 10:44:14.619 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 18: Sensor Type = Temperature(1), Scale = 1
2023-02-18 10:44:14.620 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 18: Sensor Value = 70.9
2023-02-18 10:44:14.620 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Got an event from Z-Wave network: ZWaveMultiLevelSensorValueEvent
2023-02-18 10:44:14.620 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SENSOR_MULTILEVEL, value=70.9
2023-02-18 10:44:14.621 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Updating channel state zwave:device:0e58ddeb14:node18:sensor_temperature to 70.9 °F [QuantityType]
2023-02-18 10:44:14.623 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Commands processed 1.
2023-02-18 10:44:14.624 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@cdf82d.
2023-02-18 10:44:14.624 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2023-02-18 10:44:14.624 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2023-02-18 10:44:14.625 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2023-02-18 10:44:14.625 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2023-02-18 10:44:14.654 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 12 00 A8 00 01 12 09 71 05 00 00 00 FF 04 02 00 00 A5 77 
2023-02-18 10:44:14.656 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=BridgeApplicationCommandHandler[168], type=Request[0], dest=18, callback=0, payload=00 01 12 09 71 05 00 00 00 FF 04 02 00 00 A5 
2023-02-18 10:44:14.658 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=BridgeApplicationCommandHandler[168], type=Request[0], dest=18, callback=0, payload=00 01 12 09 71 05 00 00 00 FF 04 02 00 00 A5 
2023-02-18 10:44:14.658 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2023-02-18 10:44:14.659 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Application Command Request (ALIVE:DONE)
2023-02-18 10:44:14.659 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: resetResendCount initComplete=true isDead=false
2023-02-18 10:44:14.661 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2023-02-18 10:44:14.661 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: SECURITY not supported
2023-02-18 10:44:14.662 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 18: Received COMMAND_CLASS_ALARM V8 NOTIFICATION_REPORT
2023-02-18 10:44:14.662 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 18: NOTIFICATION report - 0 = 0, event=2, status=255, plen=0
2023-02-18 10:44:14.663 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 18: Alarm Type = HEAT (0)
2023-02-18 10:44:14.663 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2023-02-18 10:44:14.664 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_ALARM, value=255
2023-02-18 10:44:14.665 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 18: Alarm converter processing NOTIFICATION
2023-02-18 10:44:14.666 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 18: Alarm converter NOTIFICATION event is 2, type OnOffType
2023-02-18 10:44:14.666 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Updating channel state zwave:device:0e58ddeb14:node18:alarm_heat to ON [OnOffType]
2023-02-18 10:44:14.670 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 18: Alarm converter processing NOTIFICATION
2023-02-18 10:44:14.671 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 18: Alarm converter NOTIFICATION event is 2, type OnOffType
2023-02-18 10:44:14.672 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 18: Alarm converter NOTIFICATION event is 2, channel alarm_general is not implemented.
2023-02-18 10:44:14.673 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Commands processed 1.
2023-02-18 10:44:14.673 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@19394c2.
2023-02-18 10:44:14.674 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2023-02-18 10:44:14.675 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2023-02-18 10:44:14.675 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2023-02-18 10:44:14.677 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
----------------------
Humidity & alarm_general

2023-02-18 10:45:16.164 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0E 00 A8 00 01 12 05 31 05 05 01 24 00 A5 FE 
2023-02-18 10:45:16.166 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=BridgeApplicationCommandHandler[168], type=Request[0], dest=18, callback=0, payload=00 01 12 05 31 05 05 01 24 00 A5 
2023-02-18 10:45:16.167 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=BridgeApplicationCommandHandler[168], type=Request[0], dest=18, callback=0, payload=00 01 12 05 31 05 05 01 24 00 A5 
2023-02-18 10:45:16.167 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2023-02-18 10:45:16.168 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Application Command Request (ALIVE:DONE)
2023-02-18 10:45:16.168 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: resetResendCount initComplete=true isDead=false
2023-02-18 10:45:16.170 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: Incoming command class COMMAND_CLASS_SENSOR_MULTILEVEL, endpoint 0
2023-02-18 10:45:16.170 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: SECURITY not supported
2023-02-18 10:45:16.171 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 18: Received COMMAND_CLASS_SENSOR_MULTILEVEL V10 SENSOR_MULTILEVEL_REPORT
2023-02-18 10:45:16.172 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 18: Sensor Type = RelativeHumidity(5), Scale = 0
2023-02-18 10:45:16.172 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 18: Sensor Value = 36
2023-02-18 10:45:16.173 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Got an event from Z-Wave network: ZWaveMultiLevelSensorValueEvent
2023-02-18 10:45:16.174 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SENSOR_MULTILEVEL, value=36
2023-02-18 10:45:16.174 [DEBUG] [erter.ZWaveMultiLevelSensorConverter] - NODE 18: Sensor conversion not performed for RELATIVE_HUMIDITY.
2023-02-18 10:45:16.175 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Updating channel state zwave:device:0e58ddeb14:node18:sensor_relhumidity to 36 [DecimalType]
2023-02-18 10:45:16.176 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Commands processed 1.
2023-02-18 10:45:16.179 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@33274b.
2023-02-18 10:45:16.182 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2023-02-18 10:45:16.182 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2023-02-18 10:45:16.183 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2023-02-18 10:45:16.184 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2023-02-18 10:45:16.246 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 12 00 A8 00 01 12 09 71 05 00 00 00 FF 10 06 00 00 A5 67 
2023-02-18 10:45:16.248 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=BridgeApplicationCommandHandler[168], type=Request[0], dest=18, callback=0, payload=00 01 12 09 71 05 00 00 00 FF 10 06 00 00 A5 
2023-02-18 10:45:16.249 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=BridgeApplicationCommandHandler[168], type=Request[0], dest=18, callback=0, payload=00 01 12 09 71 05 00 00 00 FF 10 06 00 00 A5 
2023-02-18 10:45:16.250 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2023-02-18 10:45:16.250 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Application Command Request (ALIVE:DONE)
2023-02-18 10:45:16.251 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: resetResendCount initComplete=true isDead=false
2023-02-18 10:45:16.251 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2023-02-18 10:45:16.251 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: SECURITY not supported
2023-02-18 10:45:16.252 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 18: Received COMMAND_CLASS_ALARM V8 NOTIFICATION_REPORT
2023-02-18 10:45:16.252 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 18: NOTIFICATION report - 0 = 0, event=6, status=255, plen=0
2023-02-18 10:45:16.253 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 18: Alarm Type = WEATHER (0)
2023-02-18 10:45:16.253 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2023-02-18 10:45:16.253 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_ALARM, value=255
2023-02-18 10:45:16.255 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 18: Alarm converter processing NOTIFICATION
2023-02-18 10:45:16.255 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 18: Alarm converter NOTIFICATION event is 6, type OnOffType
2023-02-18 10:45:16.255 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 18: Alarm converter NOTIFICATION event has no notification for WEATHER
2023-02-18 10:45:16.256 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 18: Alarm converter processing NOTIFICATION
2023-02-18 10:45:16.256 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 18: Alarm converter NOTIFICATION event is 6, type OnOffType
2023-02-18 10:45:16.256 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 18: Alarm converter NOTIFICATION event has no notification for WEATHER
2023-02-18 10:45:16.257 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Commands processed 1.
2023-02-18 10:45:16.257 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@118ef80.
2023-02-18 10:45:16.258 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2023-02-18 10:45:16.258 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2023-02-18 10:45:16.258 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2023-02-18 10:45:16.259 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

As to multiple alarms on one channel (Heat high and low) the Zooz has an Association group for the low alarm and another for the high alarm. Likewise for Humidity. The other option might be to use the alarm_raw that returns a JSON string with the high/low.

apella12 · February 21, 2023, 11:02pm

I don’t want to hijack your project (and fun), but I have enough data to put together a PR to fix the problems (as I understand them). I did testing on a Zooz ZSE44 Humidity and temperature sensor that I think uses the same Alarm information as your devices. I have this working locally, so I can hold off to allow you to put together a PR yourself on your own timeline. Let me know. Of course, no guarantee it will get merged anyway and the database will still need to be modified also.

Zylle · February 24, 2023, 5:09pm

Good job! By all means go ahead and make the PR

Could I get you to post the changes you’ve done here, so I can try them out on my end too. Or once you make the PR will I be able to pull the changes from github? (I’m not that experienced with github…)
I’m keen to see what changes you made to implement the wweather alarm class.