This will not do anything. The wakeup time is set on the device, so the time cannot be set until the device wakes up (some time in the next 60 days).
This is normal - it will ALWAYS do this - every time. It is not a problem - the device should be online, and it should work if the device sends any reports. The REQUEST_NIF is just part of the startup routine that the binding goes through - it is not an error in any way.
Again, this is normal. The device is not listening. Moving it will not change anything - it still won’t be listening no matter where you put it. The only time it will listen is for a few seconds every 60 days when it wakes up.
hmm…
I manually woke it up a few times (with the Strip specific magnet procedure).
It acknowledged it with the LED - but did not report something.
(nor on opening / closing the window).
Ok, if you are manually waking it up, then you should see the wakeup messages in the log?
If it’s reporting battery etc, then it should report the state. If it’s reporting battery, then most likely the lifeline is configured, and the device should send all reports.
If it’s reporting 0% battery, maybe there’s a problem with the device (eg the battery is flat) and it’s no longer sending state reports.
And I greatly appreciate this.
Your guessing is definitely more helpful than my thinking
By the way: I just started my old messed up system.
(unfortunately I don’t have access to the old influxdb data)
However, it turned out, that opening the window created an update.
So, I will revert “forward” and see if the strip will still report its state.
Strange. Given that this has nothing to do with openHAB (assuming that previously there was nothing showing in the log), I’m not sure how changing the runtime would change what the device does. I can only assume it’s a coincidence?
I don’t know. Maybe the device itself was in an undefined state and the “old” system brought it back to life?
Now, back on the actual system (just changed the SSD) it was still reporting changes OPEN/CLOSED.
So, the major issue seems to be solved.
There is no battery update though - but I will keep monitoring this.
But that’s not possible. As I’ve mentioned above - the device is sleeping - all the time. The binding doesn’t send anything to the device - that’s why it is “stuck” in the REQUEST_NIF state (it’s not really “stuck” - it’s just waiting for the device to wake up).
Really the binding has not changed in a long time and I’m pretty confident that the binding had no influence on this given the device is just sleeping (unless there’s other things going on that you’ve not mentioned).
Nothing that I can think of.
Of course I cannot be 100% sure.
But as far I can say:
I did not change the system (no rule / items / things changed, no update / upgrade, no new zwave devices) since at least two weeks. And yesterday the OPEN/CLOSED state did work.
No HW change except the HW upgrade to RPi 4 few weeks ago.
(after that upgrade the state OPEN/CLOSED did also work - but I don’t know about the Battery value though).
Just a quick update and follow up question
The bath window Node 8 went back to not reporting changes.
Furthermore I have put the Battery level manually to 30% and it went down to 0% after a while.
So I assume, it’s really about the battery being exhausted.
That brings me to another question:
Is it possible to re-arrange the connections or is this totally based on distance and signal strength?
Because my network below does look “vulnerable” especially if Node 8 will completely disappear.
It’s not possible to change the routing. This is configured by the controller. Note that this graph does not show routes - it shows neighbours, so the controller will then decide what route to use.
