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

security
zwave
Tags: #<Tag:0x00007fd311e3d370> #<Tag:0x00007fd311e3d1b8>

(Scott Rushworth) #3196

Currently 7 dead nodes and growing. All battery.


(Chris Jackson) #3197

Can you fire me over another log? Thanks.


(Mark) #3198

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.


(Scott Rushworth) #3199

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


(Mark) #3200

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.


(Harald Resch) #3201

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:
https://community.openhab.org/t/popp-smoke-sensor-4001-no-wakeup-configuration-settings-and-no-last-wakeup-time-in-z-wave-things-available/38737

Shuld i post the issues on Github?


(Chris Jackson) #3202

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: ?


(Harald Resch) #3203

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.


(Chris Jackson) #3204

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.


(vossivossi) #3205

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?


(Chris Jackson) #3206

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.


(Harald Resch) #3207

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


(vossivossi) #3208

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?


(Harald Resch) #3209

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…


(Chris Jackson) #3210

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?


(Harald Resch) #3211

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.


(Chris Jackson) #3212

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.


(Harald Resch) #3213

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.


(Chris Jackson) #3214

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.


(Harald Resch) #3215

Polling Period: 2 Day
Command Poll Period: 3600