I have a Z-Wave door/window sensors from Cyrus (the thing is a NAS-DS01Z door/window sensor).
The battery life of the sensor was less than 2 days. I’ve seen this with 3 batteries (two different battery providers). The sensor is only 1 meter away from a roller shutter, but maybe 10 meters from the controller. The controller is located in another room and on a different floor.
The window with the sensor was opened twice a day.
The parameter minimum polling period and the parameter wakeup interval are set to 86400 seconds. The command polling period is set to 0 ms. I also tested it with 1500ms with the same result.
Is this normal for such a device or what is going wrong here?
I can only talk about my zigbee sensor.
It has been with me for close to 5 years now. Ive actually moved once since I got it and it’s still the same battery.
It’s just a basic xiaomi zigbee door sensor. So from my experience that is definitely not normal at all.
1 Like
Not normal
I use zwave. Door/Window sensors sleep all the time, they wake when triggered and go right back to sleep. My front door is an Aeon Labs Door/ Window Sensor Gen5. It has a cr123 battery. I last replaced it Dec 18 2021.
1 Like
In case your sensors are new: have a look at the settings. Maybe something is set per default in a way it prevents the sensor from going to sleep most of the time. I had such a behaviour with a Fibaro flood sensor: after including it the battery was drained by 40% in just 2 hours.
1 Like
This video may be of interest to you… specifically 12:25 onwards.
Whilst there is no fix given, in the video there’s a suggestion of some kind of issue/bug (paraphrasing) that’s causing his Z-wave network to be firing a lot of traffic around for no good reason (Im sure there will be an update at some point). Perhaps you have a similar thing going on with yours, causing the batteries to drain down quickly.
1 Like
Would agree it is not normal and is probably related to not sleeping
Maybe the “action” button is stuck, the case is ajar, or the device is bad or confused thinking it is supposed to be always on.
Even if the device does not get a go to sleep message from the binding the Silabs specification is that it goes to sleep in 10 seconds without a command.
2 Likes
One thing I’ve seen not mentioned is I’ve seen reported that if you pair a device that can be either battery powered or mains powered while it’s mains powered, it will configure itself as if it were mains powered and set itself up as a relay and turn off all the power saving features.
Did you, by chance, join this node to the controller while mains powered?
4 Likes
That’s interesting. But this sensor is purely battery-powered.
I think that the battery has a capacity of 1430 mAh, so at a constant current of 35mA, the battery should have a maximum lifespan of 41h. That was about the time I saw. I think you are right about that. The device must always or at least almost always be turned on.
The question is why?
I don’t think, that the “action” button is stuck, because the sensor detects the open and close state correct. The housing was always closed.
Is it possible to explicit send a “go to sleep message” to the sensor?
After you tried resetting it? Like… I dunno. This behavior is weird.
What parameter was the reason for this?
To maybe get more information put the zwave binding in Debug long enough to open/shut the window/door and then to press the action button to “wake” the device. The logs might show something including the “go to sleep” message.
Also on the UI page for the device under thing properties it does show zwave_listening **false** right?
1 Like
Yes, zwave_listening is set to false.
I’ve set the zwave binding logging to debug, put a new battery in the sensor, opened the window and closed it and at last pressed the action button. After that I’ve uploaded the log file openhab.log to the logviewer. The log for the sensor starts at 23:56:38.949 with a RX REQ BATTERY_REPORT and ends at 23:58:45.770 with a Node is ASLEEP. So it seems, that the sensor was going to sleep after 2 minutes and 2 seconds after changing the battery. This is ok - isn’t it?
There are also three Neighbor update FAILED and two THING STATE OFFLINE messages with the same node. Could this be the reason for the short battery lifetime?
Those all tend to indicate communication issues of some sort. Did the log viewer show response times in red? The node should not be awake for more than 10 seconds.
Edit: post the unaltered log file if you can.
It was the temperature report in my case, but it can be anything that is being sent from the device without a schedule, e.g. something that is being sent after there was a measurement that differs from the one beforehand.
Anyway, Bob already pointed you in the right direction to investigate your issue further. I suggest to follow his advice.
There is a red marked response time, but it is not the window sensor - it’s a thermostat in another room.
Here is the log file. The interesting node has the number 46.
openhab-2022-12-05.log (649.9 KB)
I feel the pressure is on after @stefan.oh comment 
Anyway I think we are going to need a higher power @chris. I do see the device choking on the update neighbor command. What looks odd is the device fires off 11 “open door” messages right after the neighbor update request and then pretty much stops responding. The reason the sleep message is delayed is the update neighbors message is a controller queue priority and it has a long timeout (75 seconds) and is set to run three times. Actually the controller (your zstick) seems to give up after 35 seconds. Anyway it is not obvious to me why your battery life is poor except maybe the open/close sensor is overactive. Make sure the battery is close to sensor and firmly attached. EDIT: On occasion I have created item to count updates (ie. if sensor channel updated (not changed) count + 1) Could see how frequently this device is reporting.
As other general observations, you really should try to reduce power reporting (Watt = volt * amp) and I find a daily KWH is sufficient. All this traffic while a device is trying to go through the heal routine can’t help (but is not likely the root cause). From a Zwave expert I picked up a 10 frame per second rule and you have periods that exceed that. Also I’d suggest at least OH3.3. There were some changes with battery devices that will help battery life (But again not of the magnitude to explain your problem)
Sorry I could not help more
Bob
2 Likes
So this is a rebranded Neo cool cam?
CR14250 battery?
manufacturer claims 2 year battery life. Maybe unit is defective?
Another thought-
Although it is hard to know from the log, besides the report counting idea, is to disable the network heal for a while at least until node 46 has 5 lines at the bottom on the UI page.
If you haven’t moved powered devices around and since the device is Zwave plus and battery. It is probably not doing much to help performance and the network heal (when working properly) does can use 10-15 seconds of battery time (equivalent to 4-5 days of sleeping).
I’m also leaning in this direction as well
2 Likes
It seems so, because it looks very similar to the NEO and OpenHAB thinks also, that it is one.
The battery is a CR2, but this maybe only another name for a CR14250.
You are probably right and the sensor is defective.
1 Like