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?
You could install the 2.4 stable release, or the 2.5 Milestone 1 release. In either case, after doing that, you could upgrade the zwave binding to the latest by following my post here.
Hi, just for completeness, my HS1DS sensors are working great now in one of the later snapshots (I’m running 2.5.0.201901231358)
The sensor_door channel is updated via the alarm and this no longer suffers from being reported as closed when polled 
Thanks very much for resolving this @chris
May I ask, why @chris and Mark (@mhilbush) recommend to manage things/ devices via Habmin instead of PaperUI?
Sure. When you make config changes in Paper UI, it saves all parameters irrespective of whether or not the parameter was changed. This can sometimes have unintended consequences. For example, if you save a config change in Paper UI during initialization, and the binding has not yet retrieved the config parameters from the device, the default config parameter might be sent to the device, possibly changing the value in the device.
In contrast, HABmin saves only the parameter(s) that changed.
Edit: I should also note that the Paper UI behavior is especially troublesome with battery-powered devices, whose initialization can span multiple wake-up intervals (i.e. take several hours to complete).
To elaborate on this: deleting or adding Things is not affected, that is the reason I did not explicitly recommend HABmin.in this case.
So to summarise: Add and delete the Z wave battery thing in Paper UI ok, but configure the specific parameters of the z wave things in Habmin?
There is one general rule: everything regarding zwave should be done through HABmin.
I disagree, not everything. I am not able to modify the COM Port setting of my Z-Wave stick with Habmin, but it works with PaperUI.
For configuration parameters I agree, but that’s it.