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?
