OH2 Z-Wave refactoring and testing... and SECURITY

Currently 7 dead nodes and growing. All battery.

Can you fire me over another log? Thanks.

That’s interesting I have fewer battery devices than you (I have 16), only 1 was offline briefly since yesterday morning when I installed the binding from this post.

I have 53 of them. Home Depot was dumping the Linear door, motion, siren bundles. Averaged out to $4/device!

Wow. If I had know about that, I would’ve bought a bunch, too!

My one device that was initially offline is known to be a problem. It’s a dry contact sensor located inside a mailbox. In hindsight it was not a good idea to surround the device with metal. :roll_eyes: :man_facepalming: It has only one neighbor compared to all my other devices (mains and battery) that have at least a dozen.

Hi, with the development binding the Popp smoke sensor 4001 was not handles as battery device. There is no “wakeup configuration settings” and no “last wakeup time” in z-wave things available. Also i must replace the Battery every two month.

There also is a Topic:

Shuld i post the issues on Github?

Looking at the images, it is being treated as a battery device (listening = false). Not all battery devices support the wakeup command class. Most do, but it is not mandatory in the standard.

The Github issue list is used to report bugs - if you know there’s a bug, then yes, it should be reported, but at the moment I can’t see that there is any bug to report :confused: ?

The smoke sensors ar always online. I change to the development binding starting this Jear, since then I have to change the batteries very often. Long time i dont know why, then i found this topic.

The binding can not impact the battery use. Given that the device doesn’t support wakeup, but the device is not listening, I would expect that the binding will never communicate with the device.

Edit: I should clarify my point above before someone asks. The binding may impact battery use on devices it communicates with, but given that on this device there is no WAKEUP class implemented, the binding can’t communicate with the device, and therefore for this device it can’t impact battery life.

The POPP 4001 is a FLiRS (Frequently Listening Receiver Slave) device. So it is possible to use its sirene also for other purposes than smoke detection.
Maybe the fact that it is a FLiRS is the cause that it is treated different than other battery powered devices?

Good point - I’d not spotted that…

FLiRS devices are treated the same as non battery devices. So yes, if for example polling was set at a high rate, then it would cause a lot of communications that could shorten the battery life.

i have ask the popp support, they tell me that FLiES devices like popp 4001 should/must have polling turned off.

That is interesting as I am totally frustrated with battery life of the device used with OH2.

Because it eats battery life? Or what is the reason for this recommendation?

Yes, he told me with polling on the devices does not go into power save mode

I think with 2.2 the lifetime of the battery was better. With 2.3 it’s really frustrated…

Clearly this should not be the case as it should go into low power mode after a short delay. A device uses FLiRS so that it can be communicated with - the battery life will definately be less than a standard battery device as it needs to have the receiver on a LOT more than a normal battery device.

So long as the polling is sufficiently long, it should be fine. Just set the polling to a long period - I think the binding allows it to be set to 2 days which should be fine.

Can you quantify this? I don’t see why it should be any different between versions. What is different?

It seems to me that I have to change the batteries much more this year. So this would have been better in version 2.1 … hmm I hope I do not mess up now.
A year ago I have Vera and here it was better with the battery.

Can you quantify what is happening? How have you configured the polling? Are you doing anything with rules to refresh any data?

The binding should not send anything to the device unless you have configured it to do (other than binding startup). What do you actually see? Have you checked what’s actually happening? At the moment, you’ve just said that it seems worse battery now, but unless you can quantify what is different, then I’m afraid I can’t help.

The polling was 1 Day and 1500. Now i hav change to 2 Day and 3600. I hav no rules that ask my devices for data, only if device changed… I must check the logs for the communikation to the smoke sensor.

What do the two numbers refer to? Isn’t there just a single polling period :confused:?

I wouldn’t have expected 1 day versus 2 days to make much difference to the battery life. I would suggest to check the logs to see if anything else is happening.

Polling Period: 2 Day
Command Poll Period: 3600