openHAB 3.0.0.M1 Eurotronic Spirit Zwave LCD display timeout cannot be set to 0

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.

Temperature Offset has the same problem.
It cannot be set to 128 (special value for external sensor), but only from -50 to +50

I cannot imagine this didn’t work for previous versions of openHAB, so my guess it is a openHAB 3 issue.

Fixed.

Whoever originally entered it likely did not use those values.

Are you sure updating the DB is the correct solution?

Shouldn’t openhab not accept all listed option values and the range instead of only the range?

The parameter should be options or any value within the range.

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.

1 Like

@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.

That depends on when @chris next exports the database. He exports the database and then the binding build after that will have the changes.

I did the last export an hour or so ago…

That was before my changes, unfortunately. I changes things about 35 minutes ago.

@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…

@chris what is your take on this issue?

I don’t think so.

1 Like

Just extending the minimum range on one parameter & the maximum range on another should not break anyone.

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…

Hmmm - I don’t think this will work now…

The above has removed the limitToOptions - so I think this now defaults to true, and if so, I think now you will only be able to select the “Use ext temp sensor” option.

I know there was an issue open in OH3 as the inputs weren’t selecting data correctly. Probably the database was ok previously.

This has now been fixed.

Sorry - I don’t see any ticket for this though? Do you have an account?

should be there with username rogierhofboer
I got a notice about the ticket. But no email, if I try to login,it shows the login screen again (without any error)

There is no ticket hat has been opened, so I don’t think you’ve opened one? Anyway, it doesn’t matter, I’ll have a look to see if I can find your account.