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

I am trying ppenHAB 3.0.0.M1 with the Eurotronic Spirit zwave thermostats.

The LCD display timeout is defined in:


<parameter name="config_2_1" type="integer" groupName="configuration"
                 min="5" max="30">
        <label>2: LCD Timeout</label>
LCD Timeout<br /><h1>Overview</h1><p>0: No Timeout LCD always on</p> <p>5-30: LCD will turn off after 5 to 30 seconds</p>
          <option value="0">No Timeout LCD always on</option>

As far as I understand things, the value can be 0 or 5 - 30

The parameter cannot be set to 0 however in the settings of the zwave thing.
The error is the value should be >= 5

I am not sure if the above configuration is incorrect or if the openHAB zwave binding is not interpreting the configuration correctly.

If I’d like to try out a different database configuration, what is the best way to accomplish this?

Where is that documented? In the manual?

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

The database is here.

The Database guide is here.

your particular device entry is here.

Yes 0 or 5-30 is from the manual. It is also configured in the old device database.

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)?

For now I’ve solved my acute problem by downloading the snapshot jar:

Then I’ve changed the OH-INF\thing\eurotronic\spirit_0_0.xml file so the LCD display timeout range is 0-30 instead of 5-30.

Then I removed the zwave binding in the UI.

Stopped openhab

I put the patched jar in the addons dir

Then started openhab again.

(strange enough you cannot see this manually added addon in the addon list in the UI, but it does work)

But as mentioned, I don’t know if altering the zwave database is the correct solution for this problem.

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.


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.