Thanks for the clarification. The process is still a black box to me. I just monitor Jenkins when I’m waiting for a change (or build one from the GitHub code).
Bob
1 Like
My guess is that Jenkins is configured to only keep the last X PR builds, and X seems to result in a short life. I guess on a Sunday there might be a lot of PRs etc, and this might push things down the list quite quick.
This is how it can be done in detail
On the openhab server
always do a backup first 
openhab-cli console
bundle:list | grep “ZWave”
377 │ Active │ 80 │ 3.2.0.M3 │ openHAB Add-ons :: Bundles :: ZWave Binding
bundle:uninstall 377
(of course the id will vary on each installation)
Note that all things go to “Error Handler” which marks a failure for the time being
- copy the file org.openhab.binding.zwave-3.2.0-SNAPSHOT.jar to the mount openHAB-sys/addons
On http://myserver-ip:9001/ you should see something like “Starting ZWave controller” and all things should go back to ONLINE
I checked the latest JAR-file and it indeed it does contain the changes OH-INF/thing/sensative/1102011_0_0.xml
I installed it and it works. It is interesting that the state when queried (via Rest API or Rule) of the channel is ON or OFF but shown in the UI as “triggered” (which means OPEN) and “untriggered” (which means CLOSED)
so
| State | Meaning | UI Display-State |
|---|---|---|
| ON | Open | Triggered |
| OFF | Closed | Untriggered |
It is weird though (and this most likely has nothing todo with the ZWave Binding) that only once you add the following metadata to the item (Edit Item Metadata: stateDescription)
It then does appear as ON and OFF (and not Open/Closed as I would have imagined)
You can the mitigate that by adding this
though you could have added the last two right away even without the first ones, though it is not intuitive as initially it is being shown as triggered/untriggered.
So basically it seems to me that the default display state for ON/OFF seems to bei Untriggered/Triggered…
Anyways, it works now. 