I found the Parameter Config UI of OH3 to be far less clear and reliable than the old ‘HABMin’ UI from OH2. Habmin is really well designed… just some feedback
Submit an Issue on GitHub for the ui with examples in order to get this considered as a feature request.
Hi Bruce, I’d need to take another close look and make sure I’m being reasonable and balanced…it may have been a coloured impression because parameters were rejected (which was frustrating me 
) or there was conflict between parameter values entered via the little text boxes and those done via the code tab nearby. I’ll hold off nagging on this till I’m sure and maybe others have had similar reactions. Also, I don’t currently know how to post an issue on Github 
… so much to learn…
I do not know why they were rejected. That parameter needs to be between 100 & 170.
The entry is here.
Perhaps @chris has more ideas why it is not working as expected in OH3.
Yes the entry is allowed to be anywhere between 100 & 170. The text entry boxes kept stubbornly defaulting to -121 (yes a negative number). I entered the 135 I wanted for dimming in the ‘code’ tab entry area. It seemed to stick for a moment or two but then flipped back to -121 Bizarre… 
Guess it’ll take a few months to weed out all these gremlins.
BTW, there was similar obstinate behaviour when trying to set the Poll interval of Battery Devices to NO POLL. (battery devices should not be polled).The text box kept picking up the WAKEUP interval value. When I deleted it, it came back but yet the ‘code tab’ area showed ‘null’… this was all very flaky. There should be a simple menu option to choose ‘no poll’.
It might well be that there are other device parameter configs are being affected so hopefully the community might cross-check these values they had coming from OH2 and see if they are held stable in OH3.
I think this must be an error with the UI - I’m not sure why it would present a default of -121 or why it wouldn’t allow entries in the range of 100 to 170. The parameter definition in the database (and resulting XML) looks fine (see below).
I’d suggest to raise an issue in the webui repository -:
Hopefully @ysc can take a look.
<parameter name="config_20_1" type="integer" groupName="configuration"
min="100" max="170">
<label>20: Minimum level of the Dimmer</label>
<description>
<![CDATA[
Enable decreasing the minimum level of the Dimmer<br /> <h1>Overview</h1>
<p>This function will enable decreasing the minimum level of the Dimmer by extending the control impulse. [100 - 170] </p> <p>By changing the minimem level, the user may completely dim LED bulbs.</p> <p>Not all LED bulbs available on the market have the dimmm</p>
]]>
</description>
<default>110</default>
</parameter>
Thanks, Chris
Me neither. I can’t easily test with this particular parameter but I found another similar one on my instance - both positive min & max constraints and a default value inside the range - and it behaves as expected:
I suspect the polling time is one of those parameters with options allowed outside the range, this is currently not well supported - in that case the range check will be disabled to allow values from the options to be set - and they won’t be presented nicely, this is still todo.
Yannick & Chris, pretty sure I didn’t imagine it… … in fact it was happening on TWO separate FGD211 devices… it’s weird ok.
To be honest, I’m wondering why the ‘code’ tab is there at all exposing the details of the parameters… why not just keep text boxes for entering the values we want? …and a drop down menu or checkbox for having NO POLL if we want that?
The database options permit that but we only use that for parameters with a few discrete options. Manually entering them in the database gets tedious. You are welcome to try though. Here is the database guide.
I didn’t say you did, it’s just that I reasonably tried to reproduce it and couldn’t.
If you open an issue in the webui repo the template will suggest you some tools to take a screencast of what’s happening and guide you on what to provide to help debugging.
The code tab is actually useful for other types of things besides Z-Wave where you have many similar things and just want to copy-paste the configuration from one to another.
Guys… chill… can’t you see I was joking… it’s just a turn of phrase… I guess ye don’t ‘get’ the Irish sense of humour… 
I’d have to relaunch OH3 and delve back into those devices and to be honest I’m reluctant to do so since it appeared to alter wakeup intervals also on some battery devices. I’d prefer to leave the whole thing alone for the moment.
I can see the convenience of the code tab from what you say but I found it confusing because I didn’t know which to use, especially given there were conflicts.
Humour does not usually communicate well on an international forum. I have sometimes used links explaining any jargon I occasionally use too.
I’m pretty chill, don’t worry 
It’s just that sometimes when you face backlash about your volunteer work every other day when it’s supposed to be fun and games you learn to grow some skin
No harm done… 
… yes humour can get ‘lost in translation’.
Seriously though, I do understand and appreciate that a whole cohort of people do this development voluntarily and no criticism is ever intended. My issue was a small one, I didn’t want to make a big deal of it really and I was happy to just raise it and see what happened. regards,
@ysc @chris
135 = 256 - 121 so it’s probably just a display thing (interpretation as byte vs. short int) although dunno where, in UI or the DB. I had seen that at times earlier in 2.5/habmin.
Then again I also have FGD-211 with that parameter and itdisplays fine at least in OH2.5.10/habmin, in OH3 I cannot check as that seems to require ZWave to be up.
Hi Markus, yes it’s funny I thought the same as you about an arithmetic connection with 256 Everything is fine in OH2.5.10/HabMin. You would have to allow allow OH3 to take over the zwave stick (having shutdown OH2) to see if it happens for you.
Either way, it means the setting is correct. You can validate with changing to similar values.
Hi Markus, I’ve just noticed that the same erratic behaviour is happening in OH 2.5.10 !!!
It could have been going on with earlier versions of OH2 and gone unnoticed because one wouldn’t usually be poking around with config parameters once they are setup.
So I set 135 for Parameter 20 in both FGD211’s and the next day, possibly after a nightly heal, (I’m not sure), the value has reverted to -121.
I tried setting via both the PaperUI and HabPanel and both appear to accept the 135 but it reverts later to -121. So it’s not just an OH3 issue.
Did your reply mean that it’s just an erroneous display issue and the value behind the scenes really is 135? But why can’t a simple thing like this be straightforward?
