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

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.

If I use a wrong password I get an error, so the account is there…somewhere…

Also I had a better look at the new openHAB 3 admin UI.
The validation errors I am getting are coming from vue.

The integer parameter editor is implemented by the vue f7-list-input and min and max are configured
https://framework7.io/vue/inputs.html

In the code there is nothing done to also allow the option values as input.
I am new to openHAB and also have no previous vue experience, but I will try to have a look at it :slight_smile:

As for the database… I am now sure it should stay as is…
so:

 <parameter name="config_2_1" type="integer" groupName="configuration"
                 min="5" max="30">
        <label>2: LCD Timeout</label>
        <description><![CDATA[
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>
        ]]></description>
        <default>0</default>
        <options>
          <option value="0">No Timeout LCD always on</option>
        </options>
        <limitToOptions>false</limitToOptions>
      </parameter>

and

  <parameter name="config_8_1" type="integer" groupName="configuration"
                 min="-50" max="50">
        <label>8: Temperature Offset</label>
        <description><![CDATA[
Measured temperature offset<br /><h1>Overview</h1><p>-50 ... +50: Offsets the measured temp by -5,0°C ... +5,0°C</p> <p>128: External temp sensor will be used for regulation.</p>
        ]]></description>
        <default>0</default>
        <options>
          <option value="128">Use ext. temp. sensor</option>
        </options>
        <limitToOptions>false</limitToOptions>
      </parameter>

Just the UI should be made more intelligent :wink:

@chris I still get the login screen back after login and no extra options.
And shouldn’t the config details at least be visible without login?

Also I cannot create any more replies for today as new user (I think to prevent spam-bots).
But the account issue should maybe be discussed in a different topic or via PM ?

I updated your access already a while ago so there should be no problem and no need to open the ticket now.

That was false on both the parameters I modified.

It has now been changed so I think it will be unusable. If you didn’t change it, it might mean there’s a bug in the database editor, although I’ve not noticed it before…

1 Like

Yesterday we concluded this is a UI bug.

I should be possible to have a range e.g. -50 to +50 and options which can be outside of that range e.g. 128

The current UI uses a vue f7-list-input control and uses its built-in validation by setting the min and max of the control. It does not take into account all options values are also valid inputs (even if outside of the range). This cannot be done by the built-in validation of the f7 framework and a custom validator should be made.

I’ve created an issue for this bug.

It is somewhat related to issue https://github.com/openhab/openhab-webui/issues/357 but this is a different situation, so after first asking for reopening the issue, I’ve now decided to create new one.