Chris just said he did that 4 days agp
Snapshots are built daily. since it has been 4 days it is assuredly in the latest snapshot.
1 Like
?
It is not there…
And also not in:
repository/org\openhab/addons/bundles/org.openhab.binding.zwave/3.0.0-SNAPSHOT/org.openhab.binding.zwave-3.0.0-SNAPSHOT.jar
OH-INF/thing/eurotronic
To be clear I didn’t say that it had been exported - I said that it was approved and would be in the next export.
So it will be in the binding for the next update. At the moment I’ve not done this for OH3 - only 2.5. I will do this later tonight.
2 Likes
Sorry, I misinterpreted this.
to mean snapshot, not export.
2 Likes
I’ve just triggered the build so it should be done in the next 30 minutes or so…
2 Likes
Unfortunately this is not the “correct” version for the Eurotronic Spirit.
It does not limit to options where it should do so.
It also does not include (all) the min and/or max values for parameters having options outside outside the min/max range.
As discussed here there was nothing wrong with the database definition, but it was a bug in the OH3 UI:
Because @ysc has made a quick fix for this, it works with the original database definition in OH3 M2. OH3 Number input configuration parameters do not allow option values outside of the defined range · Issue #459 · openhab/openhab-webui · GitHub
So all recent database changes should be reversed. The one in the spirit definition in the OH3 M1 build is the correct one:
https://raw.githubusercontent.com/openhab/org.openhab.binding.zwave/3.0.0.M1/src/main/resources/OH-INF/thing/eurotronic/spirit_0_0.xml
@chris Can you revert this easily or should I edit it back to the M1 version?
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,