ZWave DB issue - Aeon Dry Contact Sensor ZW097

I’ve been working on updating the channels for the ZW097, and I’m running into a problem with the device db website. I started making them alarm types, but realized that we’ve got special channels for the newer Notification V3 format, so I switched them over.

According to the _channel.xml file in github I should be able to create channels for all the notification types this device supports, but the website is complaining about six of them (see below). Does the website need updated to support these apparently new channel types or am I doing something wrong?

Channel in endpoint 0 uses an unsupported channel (notification_co_alarm)!
Channel in endpoint 0 uses an unsupported channel (notification_co2_alarm)!
Channel in endpoint 0 uses an unsupported channel (notification_heat_alarm)!
Channel in endpoint 0 uses an unsupported channel (notification_water_alarm)!
Channel in endpoint 0 uses an unsupported channel (notification_emergency_alarm)!
Channel in endpoint 0 uses an unsupported channel (notification_clock)!

This is probably just the database - it sanity checks the list against a static list in the database firmware…

However - I’m not sure this is really what you want. These channels aren’t very useful - if you want to use a switch to show ON/OFF state, then you should use the alarm_co, alarm_co2, alarm_heat … channels with event filters for whatever events this device supports.

The sensor will also send out a sensor_binary report whenever an alarm/notification is triggered. Although there are ten different alarm/notification channels it supports, it will only use the channel that is configured in parameter 122.

Considering that I can bind it to a switch using the sensor_binary channel, and considering that I’d already know if it’s a smoke alarm or flood alarm based on which one I’ve configured it to use, I think that using the notification channels makes more sense as it would give me information that I don’t already know.

Edit: That said, I can see how some users may want to use the alarm types instead. Would it make sense to add both alarm and notification channels to this thing?

It’s fine to add both sets of channels. I’m not really sure I follow you though - if I understand you, you’re saying that if you use the sensor channel, then you know what the sensor is because you set it this way?

I think for sure we would want the individual alarms separated as most people will want to use it this way.

The notification command class is the new way to do things. If you use this, then you get notified of all the events -not just the one you configured. If you use the consolidated notification channel, then you must use a rule to separate out the different reasons for the notification event.

Basically, yeah. It’s is a bridge to integrate a dry contact device into a zwave network. You have to configure the kind of alarm you want it to send, and you can only pick one. (Oddly, it doesn’t support the general alarm.) Since the device will only send the alarm type you choose, the sensor_binary channel will always mirror the triggered/untriggered state.

That’s why I wanted to use the newer notifications, actually. I wanted to know why it was triggered. But as you said, most users probably wouldn’t care why it was trigged, just that it was.

I’ll add both sets of channels then, so we’ll have both the users who want the reasons and the users who don’t really care about the reason covered. Also, I think we may need to add an alarm_emergency and an alarm_clock channel, since I’m not seeing either in the _channels.xml file.

Side note, over the months of using this device I’ve noticed that it doesn’t seem to support GET_CONFIGURATION command. Is there a global “skip this command” option I’m not seeing, or do I have to mark all of the parameters as “write only”?

But you WILL know WHY is it triggered. The notifications separate out the different events - so you get a tamper alarm (notification event), and a separate motion event, and a separate door open event etc. The events are all individual and unrelated - they are just grouped by type but treated individually.

The notification channels were added before I understood this better and I’m really wondering if they have any real use to be honest (other than to confuse things).

I don’t understand your point about “don’t care about the reason” - if I get a tamper alarm, the reason is the device sent a tamper alarm - it explicitly states the reason. If you use the notification channel like you propose, you have to add a rule to do this yourself, but you get exactly the same result in a much more difficult way :confused:.

Really - strange. I think it’s mandatory…

Yes - you can set the command class level options to NOGET. You should be really sure about this first though as it does seem strange.

This is what I get for trying to explain myself on very little sleep. I was trying to say that while I would know if a power management alarm was triggered, I might want to know the more fine grained details about the event. My sleep deprived mind failed to realize that this device can only detect an on/off signal anyway, so I’d only ever get the “AC mains disconnected” and “AC mains re-connected” events.

So, yeah, having actually gotten a good amount of sleep last night, I agree the notification channels are largely in a device such as this. My apologies for all the confusion.

I’m almost 100% positive on this. It keeps failing on the GET_CONFIGURATION step until it finally gives up. You can view a debug log I captured after re-initializing it. It’s node 32.

Should I create a pull request for the alarm_emergency and an alarm_clock channels? I can’t really think of any other channel that’s analogous to the notification_emergency_alarm and notification_clock channels.

There are no more “fine grained details” :confused:.

Most devices only report 1 or 2 events - often you’ll see this in the XML. So, while the notification channel might list 20 different types of events that can happen, only 1 or 2 will ever be reported, and we hook these 1 or 2 events directly to a channel.

The information the user gets is the same in both systems… Anyway - no probs either way :slight_smile: .

Let’s assume 99% sure - just in case ;).

Looking at the log, it does respond to the CONFIGURATION_GET requests -:

So we don’t want to just remove this function. You are right that it’s not responding to parameter 122 though - requesting this parameter results in a NIF -:

I suspect that it might do this to try and tell the gateway to update its configuration since you’ve changed the notification that it’s sending - we don’t do this though so it’s something I might need to think about as we move toward dynamic channels…

So, I think we need to set this parameter to write_only in the database, but leave the command class options as they are since it is responding to most configuration requests.

I hope this helps :slight_smile: .