ZWave binding updates

I am close to giving up .
For some reason, the 2 z-wave contact sensors (nodes 4 and 5) that were included in OH 2.4 are the only z wave things that are giving periodic signals. The other nodes which were included after I updated to OH 2.5 snapshot appear to be dormant all the time. I must be doing something wrong. Can anyone help me out?

No need for that!

Node 2: Everything being sent to Node 2 is timing out. Move it closer to the controller? Power cycle it?

Node 3: I dunno what’s going on with node 3.

Node 6: Battery device? Delete and rediscover node 6. Try waking it up multiple times to see if it will initialize. Don’t use PaperUI to manage your zwave devices, especially while the binding is initializing the node. Use HABmin instead to manage zwave devices.

Node 7: Battery device? Do the same as node 6.

Node 8: This appears to be working fine, but you may not have any items linked to its channels.

Node 9: Battery device? Do the same as node 6.

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.


Node 2 is an Aeon ZW117 range extender.

Node 8 definitely is not a repeater.

I don’t think you need to hard reset.

  • Review your config so that you have a good understanding what each node is.
  • Make sure your items are defined correctly (e.g. node 8) and linked to the proper channels.
  • Try the suggestions above for deleting and rediscovering the problematic nodes.
  • Use HABmin to manage the devices.

If after you try the above, then maybe a hard reset is warranted.

1 Like

@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.

No need to get personal. You should get your facts right before you make accusations.

Who cares. One of mine is over 200 miles away. It runs fine. Before I make a change, I do a backup. Backup? You know what that is, right?

Getting personal again without the facts? Get a life buddy!


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)…

Thanks a lot!

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.

@mhilbush Dear Mark, thank you.

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.

Is that normal behavior?

As the text says -:

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.

Ok, that helps!

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

Number:Temperature Set_Point_Heating_Office "Heizung Büro" <temperature> (Office) { channel="zwave:device:5fe6dd01:node7:thermostat_setpoint_heating" }

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?

Where did you get the channel id from? It should be thermostat_setpoint:

Hello again,

Thanks for all your help once again. Two more questions please, just to be sure:

  • After the DB update and after the new upgrade to the 2.5 snapshot binding can I start testing the new changes?
  • With the 2.5 snapshot binding updates comes also the DB update?

And to be absolutley sure everything goes smooth I will do the above recommended procedures and always use Habmin to manage the Zwave devices.

Thank you and best regards.

Yes - the database is compiled in to the binding, so updating the binding will use the latest database in the binding.

Note that if a device has had channels updated, then you must delete and re-add the thing so that OH picks up the latest definition.

1 Like