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.
Perfect! That is the plan.
Thanks again for all the help.
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?
I ll check then when new Snapshot.jar found.
That will reduce battery life. I had one of these devices with wake up time of 300 seconds and battery life was about six month.
If you send a value to a battery device you definitely have to wait until the device wakes up to get the data transferred. In this case 5 minutes 
I am afraid that maybe it is not an individual fault on my side that can easily be fixed as a beginner’s mistake, but an issue with the Z-Wave binding. I listed some similar cases here:
Additionally, the latest post in that topic by @Mohamed_Negm one hour ago mentions that the issue is since the latest release version.
Could some developer (@chris?) comment if this is possible? In case a careful tracing is required, please let me know and I will do my best to support the finding of a solution. A first log is contained in the link above.
Could you PLEASE stop cross-posting your problem to several different topics! Thank you.
I think I am in trouble. My docker OH installation was updated by watchtower and now with the latest snapshot, I do not even have the usual UI present. This was just as I hard reset my z wave controller
I do have backups(thankfully). Should I just install the 2.4 OH, or wait for the next stable 2.5 snapshot before I start all over again. I see only the addition of the binary sensor channel comparing the 2.4 OH and the 2.5 OH snapshot for my coolcam contact sensors. But I have been advised to go with 2.5 snapshot for my mqtt binding requirements.
I would recommend not using a snapshot release at the moment due to the work to reintegrate ESH back into openHAB. If you need to install a new build use 2.4 stable, or the 2.5 Milestone 1 release.
To be sure: deleting an re-adding does not mean to exclude and to te-include, does it?
Correct. Don’t exclude/re-include, just delete the Thing from PaperUI and autodiscover again.
So do I go with the z wave binding in 2.4 stable , or just put the latest zwave snapshot in the addons?