Please can you describe the problem? I thought that the limits in parameter 8 (if I remember correctly) were meant to be set to +/- 50?
The strange thing is even the current database and the export on github are not in sync, but ok:
- Parameter 1 should be limited to the options
- Parameter 2 should be min 5 max 30 (no min/max on github, max 30 but no min in database)
- Parameter 3 should be limited to the options
- Parameter 4 should be limited to the options
- Parameter 5 should be limited to the options, min should be 0 (not in the database, but on github, not sure 0 is the default if it is left blank in the database)
- Parameter 6 should be limited to the options
- Parameter 7 should be limited to the options
- Parameter 8 should be min -50 max 50 (this is in the database, not on github)
with “should be limited to the options” I mean there is no:
<limitToOptions>false</limitToOptions>
in the definition of the parameter, assuming the default is true and if no options are present this parameter is ignored.
The above might be even more confusing. It just should be as defined here:
https://raw.githubusercontent.com/openhab/org.openhab.binding.zwave/3.0.0.M1/src/main/resources/OH-INF/thing/eurotronic/spirit_0_0.xml
If you want I can make the needed changes. Just let me know.
The database should be in sync with the binding - I just exported it an hour or two ago. If it’s incorrect, then there is likely an error in the exporter.
I really don’t have time to look at this now - sorry.
No problem. Shall I just edit the DB so it is like it was before this whole discussion?
Sure - I’m not really sure why it all got changed in the first place.
The previous and correct database definition did not work because of an openHAB 3 UI bug.
I started the discussion by asking if it should be all options should accepted even outside of the min/max range (which is yes they should), but @Bruce_Osborne immediately changed the database. He wanted to help out which I highly appreciate, but we should have first finished the discussion, before making any changes.
Can you check if I am doing something wrong?
If I set limit to options for one parameter it is changed for all parameters.
So they need to be all true or all false.
I thought you could set this per parameter.
For now I am setting it to false.
Edit:this might also explain why they are all changed, because @Bruce_Osborne said he did not touch those values…
Is it correct the export function only exports the accepted changes?
When setting min 5 max 30 for display timeout, these values are not in the XML when choosing export to openHAB xml.
Also I am not able to clear a min or max setting (so it is undefined again).
Just did a fresh install of the provided docker container (openHAB 2.5.11 Release Build, binding-zwave - 2.5.11) and it was not able to find the Eurotronic Spirits in the included database. Is the a way to sideload a fixed DB?
I want to stay on stable for the time being.
Not easily. The easiest would be to manually install a snapshot version of the zwave binding containing the new database. This script makes it pretty easy. @5iver has this been tested with Docker?
I am not aware of anyone who has tried. OTTOMH, I can’t think of any reason why it wouldn’t work. Why don’t you give it a shot and let us know 
?
I was not sure how the scri[pt uninstalls the old binding. The REST API would be available but Karaf would not.
Why wouldn’t Karaf be available?
Karaf is running in a Docker container without that port exposed, normally,
That’s odd that the port wouldn’t be available. Is it disabled by default?! The script will not work properly without the console.
I just tried the most recent docker openhab/openhab:snapshot which resolves to a version 3 OH installation. That recognizes the Spirits instantaneously.
Starting OH using docker openhab/openhab:2.5.12-snapshot-alpine caused me some headache. I coundn’t even install my bridge… The container goes down on a fatal error. Will file another bug report for that.
Will now try 5ivers scripts…
OpenHAB recommends the Debian containers because Zulu Java is not available for Alpine. Zulu is also the only one that uses hardware float calculations on arm processors like the Pi uses.
Hi Bruce,
thanks for the fast reply… I didnt know about this recommendation - sorry. Just tried docker openhab/openhab:2.5.12-snapshot-debian which doesnt fault, great. The serial bridge could easily be added and used.
However, I can now confirm that the Spirit thermostat is not in the database of binding-zwave - 2.5.12.SNAPSHOT, grrr.
@5iver: I am struggling getting your zzManualInstaller.sh to work inside the container. Would this make sense anyway, as the binding-zwave - 2.5.12.SNAPSHOT doesnt contain the device?
My current status:
docker exec myname su openhab -c "cd /openhab/addons; ./zzManualInstaller.sh --ACTION zwave"
results in
It has taken more than two minutes to uninstall the Z-Wave binding, so exiting
/openhab/addons contains your script only. Tried both the debian and alpine container…
If it was found in OH3 but not in the latest OH2 then the device is likely not fully discovered. The databases should be almost identical.
I waited now for some hours to no avail. The device was identified as
Z-Wave Node 004 (0148:0003:0001:0.16)
16 properties are populated, so I am pretty confident the discovery was successful.
If I look at PaperUI/Configuration/Binding/Z-Wave Binding I get a list of all supported things. The Eurotronics is not in the list. even though Chris wrote on Nov 7th that it has been updated for 2.5.
@chris: Could this be recurrence of the previous issue?