can this event be added to show end-of-life in the events and be checked for in rules.. just had my 2nd set of smoke detectors bo eol.. i think there ther 4 quick beeps .. at least i remembered this code from last time. hubitat still doesnt detect it as anything but alarm type 14.
1 Like
That seems to be a weird alarm type for it to use (Siren Alarm type), but if it does - it does!
I have a ZCombo driver I have like 99% done but never posted it since we figured out the users issue after I made it.
I was going to just have all the extra status messages be warn type logs with the code translated to text via the zwave standards docs.
Good idea to have it be an attribute but what do we call it? I can add it my driver and publish it. It will probably work for any zwave smoke / co alarm.
1 Like
Interestingly enough, it appears to be a (sort of) documented use in SDS13713:
| Notification name | Value | Required Version | Event/State parameters | Detailed description and requirements |
|---|---|---|---|---|
| State idle | 0x00 | V6 | Notification value for the state variable going to idle. (V5) | |
| Siren active | 0x01 | V6 | This Event indicates that a siren or sound within a device is active. This may be a Siren within a smoke sensor that goes active when smoke is detected. Or a beeping within a power switch to indicate over-current detected. The siren may switch Off automatically or based on user interaction. This can be reported through Notification Type Siren and Event 0x00. |
1 Like
@tony.fleisher and @JasonJoel where are you finding this info?
I am looking at
Application Work Group Z-Wave Specifications
Release 2022B
I think I looked into this before, and the Alarm command class is depreciated and was basically unregulated. There is no standard for what AlarmReport Type 14 means, it was up to the vendor. Probably why it is depreciated, since most everything is standardized in Z-wave now.
So prior to my other statement, this alarm would probably not be supported properly by my Z-Combo driver I created.
@jtp10181 : The Notification Command Class supersedes the Alarm Command Class.
[ Z-Wave Application Command Class Specification; Document No.: SDS13781]
The info I provided above was from: SDS13713 - Notification Command Class, list of assigned Notifications
Note: Since Notification and Alarm both were assigned Command Class value 0x71 [see: SDS13548 - List of defined Z-Wave Command Classes], the report comes in as "AlarmReport" even if it is from a device using the newer Notification Command class.
1 Like
Ah yes, I was just looking at that, but the Report from the device is not a NotificationReport, it is an Alarm Report. The AlarmReport v2 added some additional fields that can reference the codes defined for the notification class but those are all blank in the posted messages. The only info being received is an Alarm Report v1 style, type 14 and level 255. Neither of those are specified by Z-Wave to have distinct meanings.
Interesting, I will have to check this out, so it may just depends on how the driver is parsing it.
@tony.fleisher
Ok so the raw command should have been
71 05 0E FF
Translated to the Notification Class
That is a Notification Report
Now if we look at the notification Class this still translates to a V1 Alarm Type and Level
So I am still convinced my assessment holds true that this message has no defined meaning in the standards.
So… I had one of these that HE kept repotting “smoke detected”, but I never heard an alarm sound. I wonder if it was sending this eol alarm to the hub. I replaced it since it was about 6 years old.
@Ken_Fraleigh that is possible although 6 years is a short life. Could have been any status message really. According to my investigation any of the old alarms using the V1 Alarm command class could have unique alarm codes so you would need a specialized driver that lines up with the mfg specs of each code.
I think I ran into this with the Zooz 4-in-1 also, possibly the old built in driver was interpreting V1 alarm codes and that is what the original Zooz used. I think it was messing up the alerts on the new 700 series ZSE40 thinking it was getting an all clear notification because the V1 Alarm was all 0x00.
1 Like
When I purchased it from Lowes (on clearance), it was already 2 years old if I am remembering correctly.
@kahn-hubitat we probably asked this last time but I don't remember, what make/model is this smoke alarm? If it is something still in production and I can get a list of all the alarm codes it uses I could possibly add it to my driver so it picks it all up correctly.
I think you are correct... for the "V1 Alarm Type", it is up to the application to define what the type and level values mean.
[I think I confused zwaveAlarmType and alarmType here again. 
]
1 Like
i will fish it out of trash.. but it was the first alert zwave (non plus) smoke and co combo.
i also replaced it with their new zwave plus models.. but there really is no way to test if that is going to do the same thing in 10 yrs?
So it was probably the old ZCombo and the new one is the ZCombo-G (still says ZCOMBO on the back).
If you want to screenshot the "Data" at the bottom of the device page (on the new one) I can confirm if that is the same as the one I built my driver for. I have the current Z-wave spec EOL codes implemented but it will just send a WARN log. I could send an attribute just not sure what to do with it.
I am not sure if they system driver is doing anything with the additional codes or only the smoke/co alert codes.
So i removed it you want the device info for the old or new . If old i will have to re-pair it to get the info?
Misread new one.coming up
I.would just write a rule to.check the attribute whatever you.call it. Or we could stdize.maybe on a prebuilt alarm eol as was as smoke co.clear etc
