Thank you so much for your quick response.
I don’t have any node 2 or 3. Its the Aeotec Z Wave Controller stick, and nodes 4-9
Node 8 is a repeater. Node 4,5,6,7 and 9 are battery contact sensors
Does my z wave setup look warped? should I hard reset the controller and start all over again?
It is very frustrating to have a need to USE one’s Openhab only to discover it is no longer functional because a faulty update was designed so that applying the update breaks the system. I’m getting the “UNINITIALIZED - HANDLER_CONFIGURATION_PENDING” on everything, and now I have a research project to figure out how to fix it. Thanks, just effing great work.
If an update is KNOWN to destroy functioning systems, the update should never have gotten out. The tools to make an update work should be included as part of the update, otherwise you are no better than Microsoft, and your update is arguably malware.
I mean this criticism in the best most positive and constructive manner possible, but I still mean for it to be harsh criticism. Its well deserved. I mean, who would think its OK to push out something that you know is gonna break everything?
Now, I get to spend a few HOURS this week figuring out what the update did to crater my system and how to undo it. Really, really appreciated, developers.
Sorry to hear that. OTOH, maybe you should show a little more consideration for the people who spend hundreds of hours of their own free time to work on this software.
@mhilbush, @chris
I followed your guidance to clear up my Z-Wave network and did a hard reset. Now, I have a proper network again. Thanks for the hint!
Still, the root cause of the trouble is unresolved (thread with logs):
Would you have a solution approach for me? Some others have the same issue for thermostats, but in the respective discussions, there is no solution presented. @chris was involved in the discussions - maybe there is some solution I did not see?
mhilbush the fact that people volunteer lots of time to work on the software does not excuse the fact that you put KNOWINGLY out an update that destroyed my functioning system. I believe that’s inexcusable, and if you think that’s acceptable approach to managing an open source app, then you need to look in the mirror for the problem and I need to find a replacement for openhab.
I respect the effort. I have no respect at all for cutting corners and pushing out something with a sick excuse of well, they will figure it out. Keep the darned update until it can go out with the necessary mechanisms to ensure with some reasonably high probability that OPERATING FUNCTIONAL systems that people depend on the tool will continue to work.
Your update is, from my perspective, destructive malware because you (and all those wonderful volunteers) didnt finish the job and pushed it out too soon.
I have about reached the end of my rope with openhab.
My openhab implementation is over 100 miles away from me. And its busted now and does not work. And cannot be fixed (because of the obtuse design of openhab, read my other rants) so I cannot fix it until I can get there to work on it.
Great, its free, love the work of the volunteers, but MAYBE the job should be completed before pushing it out next time.
Just to be sure: What’s the meaning of the WakeUp-Interval? I set it to 300sec. I thought the device will store the set value when it arrives and if the WakeUp occurs, the set value will be “executed”, i.e. applied.
Am I wrong?
Hmm. So does the WakeUp interval only hold for administration (parameter settings), or also for the set point values? This remains unclear from that page (and also other sources that I found)…
Any command you send to the device is queued, then sent to the device when it wakes up. Note that the queue is volatile, meaning that if you restart openHAB or the zwave binding, whatever was in the queue is lost.
In my case, the transmission is fine (from what I read from the logs) but still the values are not accepted. Only when I manually wake up the device and send a new set value in that moment, the value is accepted.
Otherwise, the next report from the device resets the item I use for set point values back to the old value stored in the device.
In Z-Wave, most battery devices spend the majority of the time sleeping, and they only wake up very occasionally to allow commands to be sent to them.
This is true for ALL commands - the device has no way to know if commands are administration or set points. If it is sleeping, then it is sleeping and unable to accept ANY command.
So normally, my set points values would be queued in the controller, and then on wake up transfered to the device. That would mean that I should find my value stored in the device latest after 5min.
But in my case, I assume that the device wakes up: It sends its old set value and overwrites my value in OH. That again is strange, but at least two threads describe a similar behavior (see Devolo MT 2650 ignores setpoint value sent via Z-Wave, also with logs)
Or is it simply a wrong item definition on my side?
I use
and write my set point value to that item. But after some minutes, the item value returns to its original value and the thermostat still has its old setting.
Is this the right way? Or is the behaviour normal and my item (or my expectation how the item works) are wrong?
Dear @sihui,
you are right, thanks for the hint. Indeed, this was an item I created while I had troubles with the Z-Wave Network itself. Clearly, it can’t work - and it is also assigned to a node 7 which does not exist in the current setup (with a new Z-Wave network from scratch).
I will correct this tonight. I am not too optimistic as I tested also in PaperUI control and the items used there are automatically created - but still, this needs to be corrected to work in BasicUI and elsewhere. I will report if this does the trick
Should I reduce the updateInterval from 300 to a lower value? Maybe this is why the set point value is not correctly transferred?