Zwave alarms from things

I’m wondering where I can find out what the alarm channels associated with different devices actually mean.
I have some Zwave devices, that in OH have alarm channels associated with them - an example is the aeotec AerQ sensor (ZWA039):

It has 3 alarm channels: heat, power, weather - but what do they actually mean, when triggered. And more importantly, how can I actually find this out myself, so I on my own can do this when I encounter a new alarm on a new device.

What I have tried is viewing the device in the opensmarthouse database, where I can see the device alarms are command_class_alarm types - but nothing about how the alarms are triggered.

The engineering sheet for the device has some clue about it, but I fail to see how this can be directly linked to the specific triggers for these notifications, as there is nothing in the parameters that concern these.

zwave_alarm_ES

For example when the device runs low on battery, the low battery notification works, as I’ve read this is implied by the binding setting battery level channel to 0%, but when the battery level is 0%, the power alarm is still not set to ON, as I would expect.

The link to where the engineering sheet can be downloaded is:

Again, I’d much rather learn how to find what actually triggers these channels, rather than being told for a specific device how they operate. I feel I’ve done a thorough search of the forum, and also any documentation on the devices themselves, the opensmarthome database, and the zwave binding, without finding an answer, so any help expanding my knowledge is appreciated.

Just for reference, these are some other devices, where I have the same questions regarding the alarm channels and actually causes them to trigger:
Aeotec Smart Switch 7: Alarm power, alarm system
Aeotec AerQ v1: Alarm general
Logic Group Power outlet, ZSO7300: Alarm power
Danalock v3: Alarm Entry

Thanks in advance

So I’m exactly sure what you mean, but recently in another post there is some information. There are two key files in the binding. First the Alarm CC and then the Alarm converter.

1 Like

Z-Wave notification (COMMAND_CLASS_NOTIFICATION) 0x08 - 0x0b:


Z-Wave binding source code:

grafik

grafik

Result:
0x8 - 0xb → alarm_battery, type=POWER_MANAGEMENT

Z-Wave database:

Result:
Channel for notification 0x8 - 0xb is missing in Z-Wave database.

1 Like

Thanks Gents, that helped to connect most of the dots.

I’m still a bit uncertain about how the channel type in the binding works and the link to the notification type.
From the example given here, the Alarm (power) channel for the Aeotec AerQ, I assume should be alarm_battery as shown in the code snippet above from the binding? But I don’t understand how that affects the functionality, since it is merely the vessel that is different but the data remains correct.
Or is it since the event is 0xb, which isn’t found under the alarm_power mapping, the channel doesn’t send any data?

The second question is regarding notification event triggers (again):
The SDS doumentation helped clarify alot for me, but is there anywhere else the actual triggers for the events are described?
The example @Ap15e gave showed clearly when the given notification is triggered - but there are others that seem more obscure, for example the Alarm (weather), is just describe as a moisture alarm.

The same goes for the 2 heat alarms (over heat, under heat)

But I can’t find anywhere what values or events actually triggers them, and I don’t see in the engineering sheets any details on this either (it may be there, but I dont see it! :wink:)
There is a reference to a “mould danger notification”, but how do I know that this actually references the weather moisture notification.

For that matter regarding the over/under heat notifications, are as far as I can see not referenced in any way, shape or form in the parameters.

I can now however see that the “under heat” channel is missing from the database - I will get back to how that is taken care of later. I’ve seen there is a blogpost and a guide to it somewhere, but I’d like to feel comfortable with what I’m doing before diving in to that part.

Once again thanks for your inputs!

So let’s do a reverse analysis (Z-Wave database → Z-Wave notification):

Channel alarm_power with configuration POWER_MANAGEMENT stems from Z-Wave Notification Type 0x8 (Power management):

// Power alarms
        events = new HashMap<NotificationEvent, State>();
        events.put(NotificationEvent.POWER_MANAGEMENT__NONE, OnOffType.OFF);
        events.put(NotificationEvent.POWER_MANAGEMENT__OVER_CURRENT, OnOffType.ON);
        events.put(NotificationEvent.POWER_MANAGEMENT__MAINS_DISCONNECTED, OnOffType.ON);
        events.put(NotificationEvent.POWER_MANAGEMENT__MAINS_APPLIED, OnOffType.OFF);
        events.put(NotificationEvent.POWER_MANAGEMENT__MAINS_RECONNECTED, OnOffType.OFF);
        notifications.put("alarm_power", events);

The corresponding Z-Wave notification(s) is the intersection of the above code and

        POWER_MANAGEMENT__NONE("POWER_MANAGEMENT", 0),
        POWER_MANAGEMENT__MAINS_APPLIED("POWER_MANAGEMENT", 1),
        POWER_MANAGEMENT__MAINS_DISCONNECTED("POWER_MANAGEMENT", 2),
        POWER_MANAGEMENT__MAINS_RECONNECTED("POWER_MANAGEMENT", 3),
        POWER_MANAGEMENT__SURGE_DETECTED("POWER_MANAGEMENT", 4),
        POWER_MANAGEMENT__VOLTAGE_DROP("POWER_MANAGEMENT", 5),
        POWER_MANAGEMENT__OVER_CURRENT("POWER_MANAGEMENT", 6),
        POWER_MANAGEMENT__OVER_VOLTAGE("POWER_MANAGEMENT", 7),
        POWER_MANAGEMENT__OVER_LOAD("POWER_MANAGEMENT", 8),
        POWER_MANAGEMENT__LOAD_ERROR("POWER_MANAGEMENT", 9),
        POWER_MANAGEMENT__REPLACE_BATTERY_SOON("POWER_MANAGEMENT", 10),
        POWER_MANAGEMENT__REPLACE_BATTERY_NOW("POWER_MANAGEMENT", 11),
        POWER_MANAGEMENT__BATTERY_CHARGING("POWER_MANAGEMENT", 12),
        POWER_MANAGEMENT__BATTERY_FULL("POWER_MANAGEMENT", 13),
        POWER_MANAGEMENT__CHARGE_BATTERY_SOON("POWER_MANAGEMENT", 14),
        POWER_MANAGEMENT__CHARGE_BATTERY_NOW("POWER_MANAGEMENT", 15),

i.e. Z-Wave notification values (notification type 0x8):

  • 0x0 NONE = State idle
  • 0x1 MAINS_APPLIED = Power has been applied
  • 0x2 MAINS_DISCONNECTED = AC mains disconnected
  • 0x3 MAINS_RECONNECTED = AC mains re-connected
  • 0x6 OVER_CURRENT = Over-current detected

In other words:
The openHAB channel named Alarm (power) catches all Z-Wave notifications with type 0x8 and notification values 0, 1, 2, 3, 6. It doesn’t catch 0x8 - 0xb.

1 Like

You can’t. There is no such thing as a Z-Wave ‘mould danger notification’. Ask the manufacturer for the corresponding Z-Wave notification type and the corresponding Z-Wave notification value for ‘mould danger notification’. Don’t buy devices whose documentation lacks basic information.

Edit:
Don’t trust the channel definitions in the Z-Wave database (missing channels, wrong channel definitions, duplicate channels, channel definition too general, …). Mix it with incomplete/erroneous documentation from the manufacturer and different firmware/hardware versions of a particular device - welcome to Z-Wave hell. :slight_smile: To be fair: Other technologies also have their specific hell.

:rofl: So true - thanks for the laugh.

And I don’t mind Z-wave hell :grin: chaos doesn’t put me off - but bad logic sometimes can. Hence I really like to understand the "what"s and "why"s when messing around with these sort of things.
I’ve put in a support ticket with aeotec asking them to explain the other notification triggers - once I have a satisfactory answer, I’ll start looking towards learning correcting or adding to the zwave database for the devices that I have.
For the faulty channel type in the device, if you haven’t made the correction please don’t, as I’d like to try and do that myself (since nobody has done it, I assume no one else has requested it to be done, so I figure it can wait a couple of days), and as for the lacking notification discriptions I’d like to add those as well for future users which i understand would go under the overview tab

1 Like