The configuration in the binding has been exported from our community maintained database. Although the community can change entries, they are reviewed prior to export to insure the changes are valid and will not break other users
In this new device database there are not details listed for the configuration properties,
I am not sure if I cannot see them or if they are not present at all.
My knowledge of OH3 zwave is not good enough (yet) to determine if a device cannot be defined like this. So 0 is an option and the default value, but the allowable range is 5-30.
The current openHAB 3 M1 milestone cannot handle it and does not accept 0.
So should openHAB be changed so it understands option 0 is valid and 5-30 is valid?
Or should the device database be updated values 0-30 are valid (and the user has to be sure note to use 1-4)?
Or should the device database definition be updated so multiple ranges can be defined (seems overkill to me only for this specific use case)?
I think you need to be logged in there to see them. They should be the same. That data has not changed since OH version 2.5.6.
I just checked the new database. The description indicates like you mention but the minimum value was incorrect. I just updated that and, the snapshot after the next database export will have the updated parameter.
You then need to delete the Thing ( NOT exclude) from OH and rediscover to get the new settings after updating the binding.
Then there is no need to change the DB, but openHAB should be fixed.
I am pretty sure external temperature used to work. People reported it works in openHAB in the past.
No mention of not being able to set value 128. Also the default LCD timeout would have been reported.
You now cannot even change the name of the Thing without setting a non-default LCD timeout of 5-30.
So if you say value in the range (5-30) AND the listed options 0
(or 128 and -50 - 50 for the Temperature Offset) should work, openHAB needs to be changed to allow this. I a new to openHAB, but will have a look where this is coded.
Don’t get me wrong,. I really appreciate your help and promptness to change the DB, but the more I am thinking and reading about it the more I get convinced the solution is to keep the DB as is and change openHAB so it allows all option values and the range (even if some of the option values are outside of the range)
You might have misunderstood, there was an error in the database causing the binding not to accept those values. Definitely no code changes needed, just wait for the next SNAPSHOT including the DB update.
@hmerk So to be sure… it will be in the next yet to be built zwave snapshot? Because the current snapshot does not allow option values outside of the defined range. Also there is not difference between the master branch and the current snapshot.
@Bruce_Osborne Please revert the database changes if you didn’t already do so.
@Bruce_Osborne But are you sure these changes are needed? Did you extend the range (which I think now should not be done) or something else… I am will now make an account for the new DB so I can also see more…
I agree it does not break things… But I think the best solution is for openHAB to allow all the listed option values (even if outside of the range) and all values within the range.
So with the config range -50 - 50 and the option value 128 it accepts 128 AND -50 - 50
And with range 5-30 and the option value 0 it accepts 0 AND 5 - 30.
This way the DB also reflects the real possible options.
I think openHAB did this in the past…
Unfortunately I cannot access the new DB yet (someone has to approve the account).
Maybe one of you can share the previous and current definitions so I can understand what was wrong with the DB as @hmerk is suggesting…