Popp Smoke Detector does not report battery alarm in time

tonus · December 24, 2022, 5:05pm

Hi,

I have a Popp Zwave Smoke Detector. It is a nice FLIRS. It works fine when there is a smoke alarm. However, the battery alarm is never given. I do not receive any battery updates. That is a pitty!
After I replace a dead battery, I received the battery alarm (at 18:35:52.772)

18:35:52.770 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 5: Received COMMAND_CLASS_BATTERY V1 BATTERY_REPORT
18:35:52.771 [DEBUG] [ommandclass.ZWaveBatteryCommandClass] - NODE 5: Battery report value = 255
18:35:52.772 [DEBUG] [ommandclass.ZWaveBatteryCommandClass] - NODE 5: BATTERY LOW!
18:35:52.773 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
18:35:52.775 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_BATTERY, value=0
18:35:52.776 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Updating channel state zwave:device:0748817ea2:node5:battery-level to 0 [DecimalType]

In a more graphic way, using the tool of @chris :

I assume that this can be repaired in the database definition
I’m happy to change that , but how to do that? What option to use?

Thanks!

chris · December 25, 2022, 11:28pm

I think it’s unlikely there is anything that can be changed in the database. If the device isn’t sending battery alarms, I’m not sure what can be changed - I assume the lifeline is configured or it wouldn’t send any reports, so I would also expect it to send the battery low reports as well.

anon71759204 · December 26, 2022, 1:55pm

The measurement of the battery voltage is a BS implementation, see Popp Smoke Detector and Siren - #27 by Celaeno1.

Quote from the manual:
“Low Battery Alarm (when the battery of the wireless modules goes low), indicated by yellow LED”

It might be necessary to add your Z-Wave controller to association group 2 (shouldn’t be necessary though) and to add the “low battery alarm” to the Z-Wave database.

Problem:
How to find out the notification type/notification for “battery low alarm”? Just a wild guess: 0x01 (Smoke Alarm) / Replacement required (0x04) - you could use an almost empty battery (make sure the yellow LED in on) and watch the debug log to find the values for “battery low alarm”.

tonus · December 31, 2022, 2:54pm

From this thread I found this interesting remark from @Celaeno1 :

So, the value is always at 100 . If the battery is almost empty , the battery alarm is already triggered . Only very shortly before the battery is completely empty , 0 is displayed.

So, the device just reports very limited battery reports, and unfortunately at a late point in time. That is by design. It is either 0%, 100%, of NULL.

@Chris said:

If the device isn’t sending battery alarms, I’m not sure what can be changed

Would it be possible to let OpenHab ask for the battery status, for instance every day?
I assume that would be possible if it were a normal channel and not an alarm channel?

Thanks!

anon71759204 · December 31, 2022, 3:08pm

As I wrote before: The BATTERY_CLASS in this device is a BS implementation, so it doesn’t make sense to request battery reports.

We would need to see a debug log of a “battery low alarm” from your device. If the manual is correct, a nearly empty battery should trigger a “battery low alarm”. “battery low alarms” and “battery reports” are different things/come from different Z-Wave command classes.

chris · December 31, 2022, 7:49pm

Yes, it should already do that. I know in the past we’ve had some devices that report 100% until they don’t report anything

My guess (and it’s a guess) is that if the battery voltage isn’t reading correctly, then probably the battery alarm is also not going to work since it will rely on a correct battery voltage in the first place.

anon71759204 · January 2, 2023, 7:03pm

I’ll ask the manufacturer for the notification details for:

chris · January 3, 2023, 2:15am

I guess it would be interesting to see if there was a “Yellow LED” on the unit?

anon71759204 · January 3, 2023, 2:48am

The “yellow LED” (if there is one …) leads me to believe that there is a “low battery alarm” even if the implementation of the battery report is crap.

chris · January 3, 2023, 2:57am

From a software perspective, it’s highly likely that any battery voltage reading, and reporting of battery voltage, is linked directly to the battery alarm. It’s unlikely there’s a separate circuit that manages the alarm - most of these sort of devices use a simple voltage divider to read the battery voltage from the ADC and then will send the battery voltage and alarms based on that.

It’s not unheard of for these devices to not report voltage or alarms.

tonus · January 3, 2023, 5:13pm

No, there is nog “Yellow LED” on the unit, only a red LED. It blinks to indicate error situaties (possibly also battery alarm, I will pay attention to that). Also, there is beep when the battery is low.
As reported by @Celeano1 in a different post, the beeps are more frequently when the battery is lower.

Notes to the original log : (see below)

My smoke detector was beeping for at least a few days
Then, I have put new batteries in at approx 18:30 or so**!
AFTER THAT, the first battery alarm came at 18:35:52.550 for my smokedector node5
The battery alarm seems to come twice.
There is also a smoke alarm coming, as a third message

Here the original log:

2022-12-22 18:35:52.541 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 05 03 80 03 FF 88
2022-12-22 18:35:52.543 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=5, callback=0, payload=00 05 03 80 03 FF
2022-12-22 18:35:52.545 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=5, callback=0, payload=00 05 03 80 03 FF
2022-12-22 18:35:52.546 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2022-12-22 18:35:52.547 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 5: Application Command Request (ALIVE:SUC_ROUTE)
2022-12-22 18:35:52.548 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 5: Incoming command class COMMAND_CLASS_BATTERY, endpoint 0
2022-12-22 18:35:52.549 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 5: SECURITY NOT required on COMMAND_CLASS_BATTERY
2022-12-22 18:35:52.550 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 5: Received COMMAND_CLASS_BATTERY V1 BATTERY_REPORT
2022-12-22 18:35:52.551 [DEBUG] [ommandclass.ZWaveBatteryCommandClass] - NODE 5: Battery report value = 255
2022-12-22 18:35:52.553 [DEBUG] [ommandclass.ZWaveBatteryCommandClass] - NODE 5: BATTERY LOW!
2022-12-22 18:35:52.554 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2022-12-22 18:35:52.555 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_BATTERY, value=0
2022-12-22 18:35:52.556 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Updating channel state zwave:device:0748817ea2:node5:battery-level to 0 [DecimalType]
2022-12-22 18:35:52.558 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 5: Commands processed 1.
2022-12-22 18:35:52.560 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 5: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@c6779c.
2022-12-22 18:35:52.561 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-12-22 18:35:52.562 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-12-22 18:35:52.563 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2022-12-22 18:35:52.564 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2022-12-22 18:35:52.579 [INFO ] [openhab.core.model.script.Rule CM-ST] - 🟥 Smokedetector First floor empty!
2022-12-22 18:35:52.761 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 05 03 80 03 FF 88
2022-12-22 18:35:52.763 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=5, callback=0, payload=00 05 03 80 03 FF
2022-12-22 18:35:52.765 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=5, callback=0, payload=00 05 03 80 03 FF
2022-12-22 18:35:52.766 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2022-12-22 18:35:52.767 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 5: Application Command Request (ALIVE:SUC_ROUTE)
2022-12-22 18:35:52.768 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 5: Incoming command class COMMAND_CLASS_BATTERY, endpoint 0
2022-12-22 18:35:52.769 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 5: SECURITY NOT required on COMMAND_CLASS_BATTERY
2022-12-22 18:35:52.770 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 5: Received COMMAND_CLASS_BATTERY V1 BATTERY_REPORT
2022-12-22 18:35:52.771 [DEBUG] [ommandclass.ZWaveBatteryCommandClass] - NODE 5: Battery report value = 255
2022-12-22 18:35:52.772 [DEBUG] [ommandclass.ZWaveBatteryCommandClass] - NODE 5: BATTERY LOW!
2022-12-22 18:35:52.773 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2022-12-22 18:35:52.775 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_BATTERY, value=0
2022-12-22 18:35:52.776 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Updating channel state zwave:device:0748817ea2:node5:battery-level to 0 [DecimalType]
2022-12-22 18:35:52.777 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 5: Commands processed 1.
2022-12-22 18:35:52.778 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 5: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@bd04f9.
2022-12-22 18:35:52.779 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-12-22 18:35:52.780 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-12-22 18:35:52.781 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2022-12-22 18:35:52.782 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2022-12-22 18:35:52.796 [INFO ] [openhab.core.model.script.Rule CM-ST] - 🟥 Smokedetector First floor empty!
2022-12-22 18:35:52.828 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 11 00 04 04 05 0B 71 05 00 00 00 FF 01 02 00 00 00 68
2022-12-22 18:35:52.830 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=5, callback=4, payload=04 05 0B 71 05 00 00 00 FF 01 02 00 00 00
2022-12-22 18:35:52.832 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=5, callback=4, payload=04 05 0B 71 05 00 00 00 FF 01 02 00 00 00
2022-12-22 18:35:52.833 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2022-12-22 18:35:52.833 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 5: Application Command Request (ALIVE:SUC_ROUTE)
2022-12-22 18:35:52.834 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 5: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2022-12-22 18:35:52.835 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 5: SECURITY NOT required on COMMAND_CLASS_ALARM
2022-12-22 18:35:52.836 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 5: Received COMMAND_CLASS_ALARM V5 NOTIFICATION_REPORT
2022-12-22 18:35:52.837 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 5: NOTIFICATION report - 0 = 0, event=2, status=255, plen=0
2022-12-22 18:35:52.838 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 5: Alarm Type = SMOKE (0)
2022-12-22 18:35:52.838 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2022-12-22 18:35:52.839 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_ALARM, value=255
2022-12-22 18:35:52.840 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 5: Alarm converter processing NOTIFICATION
2022-12-22 18:35:52.841 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 5: Alarm converter NOTIFICATION event is 2, type OnOffType
2022-12-22 18:35:52.842 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 5: Alarm converter NOTIFICATION event is 2, channel alarm_general is not implemented.
2022-12-22 18:35:52.843 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 5: Commands processed 1.
2022-12-22 18:35:52.844 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 17 03 25 03 FF 3F
2022-12-22 18:35:52.844 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 5: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1f3b94a.
2022-12-22 18:35:52.845 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-12-22 18:35:52.846 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=23, callback=0, payload=00 17 03 25 03 FF
2022-12-22 18:35:52.846 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2022-12-22 18:35:52.849 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=23, callback=0, payload=00 17 03 25 03 FF
2022-12-22 18:35:52.850 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null

anon71759204 · January 5, 2023, 3:04pm

My inquiry about Popp 009402:

Could you please provide the Z-Wave notification types (0…255) and Z-Wave notiication events (0…255) for the following alarms:
• Smoke Detected (this message will also be issued when the test button is pressed)
• Low Battery Alarm (when the battery of the wireless modules goes low), indicated by yellow LED
• Tamper Detected (ON, when the smoke detector head is removed from the base; OFF, when the detector head is mounted to the base)
• End of Life (issued, when the Detector Main Head has reached its end of life after 10+ years.)

Reply from Popp support:

the POPP Smoke Sensor does not use the CC Notification.

The alarms are displayed as follows.

Smoke Alarm.

CC Sensor Binary

CC Alarm

Tamper

CC Sensor Binary

CC Alarm

The battery level of the 10 year detector is not directly displayed, there is only an alarm message as a fault.

CC Alarm

The battery level of the module is sent via the CC Battery.

My interpretation:
There is no such thing as a ‘battery alarm’ (for the battery in the Z-Wave module). The device is based on command class ALARM_V1 and as such ‘alarm types are specific for each application’. Without proper documentation of alarm types from the manufacturer we are stuck.

My recommendation:
Ditch it (assuming it was manufactured in 2016 and the main battery is near the end of its life).

chris · January 5, 2023, 10:56pm

The battery low warning notification, which I assume is what you refer to, is part of the BATTERY command class. It’s not part of the ALARM/NOTIFICATION command class and there’s no separate alarm that I’m aware of (but of course I might just not be aware of it ).

anon71759204 · January 5, 2023, 11:16pm

In theory, a manufacturer is free to use the (deprecated) ‘Alarm Command Class V1’ and to define a manufacturer specific ‘Alarm Type’ for ‘battery low’ (if my interpretation of the ‘Application Work Group Z-Wave Specifications, Version 1.0’ is correct ).

tonus · January 16, 2023, 7:14pm

Thanks @Chris and @anon71759204 for explaining all this.

So, let’s conclude that OpenHab and the Zwave library get the best possible results regarding the limited design of this sensor. I can live with the idea that the battery warning is always too late and keep an eye (ear actually) on the physical beeps.

What worries me the most is that there are very few smoke detectors that support Zwave, and virtually none that runs on external power (230 V), except for this usual designed type we discussed above. And this situations has not changed really the last few years. So what to wait for then, in IoT land? Switch to Zigbee? Or wait for Matter ?? Or something completely
different??

But that’s an whole different discussion…