Is there a way to change these times? I’ve nothing found.
Good idea, I’ll give it a try - although I don’t think that happens very often. The window is opened maybe once or three times a day. Even if 11 messages are sent each time, that can’t really be a big power consumption in total.
You’re right, but I can’t see any parameter to reduce this. Is it a device parameter or a controller parameter?
The controller has a parameter called Default Wakeup Period, which is set to 3600s. Is this value to short?
Very interesting information. I will update my system near Christmas day.
Nevertheless, thanks for your help - also to the others. I have learned a lot.
No they can’t be changed. I could not determine from the logs if the device was in an active state for all this time. If it was, that would go a long way to explaining the battery life issue (105 seconds active = 43 days of sleeping). If disabling the heal extends the battery life, then maybe that is what is happening. The mystery would be why the device can’t find its neighbors. The normal action is the device sends a message to every node and registers the ones that answer as “neighbors” (maybe a couple of seconds start to finish). What does the UI for the device show as neighbor nodes and how many?
Device parameter. Could be hidden as “advanced”, so check that.
I believe that value is only used if there is not a value on the device, but no harm in moving that to 86400 also. IMO you only need to wake once a day to get a battery reading (which normally should not change much ) anything more frequent and battery life will be reduced for no real information
The sensor has 4 direct neighbors in the network card. One is the roller shutter, which is only 1 meter away from the sensor. I don’t trust the network card much, but if it’s right, the network seems fine.
I think he means the Zwave network map (in english)
If by ‘network card’ you are talking about the zwave network map, not trusting it much is a good assumption but anyhow, it does (I think) show neighbor relationships, I think that is what it mainly shows and that would indicate the network is fine.
Has this device continued to consume batteries?
You said you have changed the battery already and even different batteries so to eliminate a bad batch of batteries
Is this your first door/window sensor? I really think unless you buggered with the parameters right out of the box and somehow screwed up the configuration, this sensor is a brick. If you remove the battery, the device will reset. It should have sensible parameter setting from factory to not clobber the battery in two days. I’m guess you just purchased this sensor and can return or exchange. I think it’s a brick
Yes, in the meantime I used 5 different batteries from 3 different manufacturers.
It is the second one. The first one is still running with its second battery since the 21. November, but the associated window was only opened twice since the last battery change and the sensor is near the controller. I started with both sensors at first with the factory settings.
I hope that it is not a fundamental problem of this type of sensor, since even the first sensor with the original battery did not last a month.
But however, I think you’re right. I’ll try to return or exchange the sensor.
that ain’t right either. Like I said, I have a Aeon labs which was branded differently on Amazoo and it was less then $30 usd. Batery goes a year and it’s the furthest from the controller, down a flight of stair and it’s the front door so opens daily
I’m not sure I can add a lot here. I would suggest that the device may simply be faulty. It could be staying awake for some reason known only to itself, but the binding is telling it to go to sleep, and apparently (based on power consumption) it isn’t doing that.
The log does show a lot of repeats of a door report (event 22) - that’s also suspicious since it may indicate that the device isn’t receiving the response, or something isn’t right somewhere with the device (or possibly the network).
Besides the defective device idea, Chris is suspicious of the “open” repeats for a different reason than I had noted. When a device sends a message it needs to ‘hear’ an acknowledgement (ack) message from the device it sent it to, or it will send the message again (and again and again). So although the controller is getting the message the device may not be getting the ‘ack’ from the controller, despite 4 neighbors (which is not a lot). I should have asked if these 4 neighbors are powered, as only powered nodes are involved in routing?
Assuming the sensor is based on a Reed relay:
Use a really strong magnet to ‘push’ the sensor into the ‘closed’ state and check whether this sedates the sensor. The Reed relay may be failing …
Yes all 4 neighbors are powered by wire. The shortest path from the sensor to the controller has 2 other (powered) devices between the sensor an the controller.
Interesting point, but I think that such a sensor only sends a signal when there is a change of state and not as long as the state is open - or am I wrong?
No, you are not wrong. I was thinking of a loose contact (“Wackelkontakt”) inside the Reed relay. If you open the device, you could bypass the Reed relay to force the device into a defined state.
Yes, my idea is quite far-fetched, but who knows …
) anything more frequent and battery life will be reduced for no real information