When I configure a new item and want to write (initial) values with “oh-stepper-item”-widget, it does not work.
I have to give the item a value first. This for example I do with “oh-slider”-widget. After the value is set I can change the value with “oh-stepper-item”-widget. But not when the value is “NaN”.
Is there a way that the item initializes with “oh-stepper-item”-widget?
Thanks, BR
There are a number of ways to intialize your Item state for use with a stepper. Your slider idea is good, or use API Explorer for one-time setting, if persistence restore-on-startup will cover you at the next reboot. Or a startup rule,
The problem with a stepper type widget is that it does add/subtract, and cannot work without a starting point. It is not safe to assume any particular starting point should be used if the linked Item state is NULL/UNDEF.
A slider is different - if you put it halfway, you mean half value, it doesn’t matter where you started from.
Hi rossko
Thank you. I fully agree with you from a programmers view.
But form an end user view this is horrible an very difficult to understand.
When using a setpoint widget in a sitemap (BasicUI) the initialization can be done. It just uses the upper and lower value as starting point, which could also be with “oh-stepper-item”-widget I think.
I just did some more tests. A slider in default goes from 0 - 100. This just an assumption I guess. Half value from a number item would be different…?
I think it would be worth to open an github issue for this. What do you think?
I don’t think it is a feature worth having, but not my decision. How often do you create Items manually and add stepper widget?
You’d better clarify exactly what you want to happen - e.g. make an assumption that min value is the pretend starting value? What if no min value specified? What if linked Item already has a state that is outside max-min range?
An alternative user friendly feature might be to allow users creating Items manually to have an option to set the initial state atthat time.
Yes, or from 200-300 or whatever you choose.
The point is that if you set the knob to halfway you are commanding a set value 50 (or 250 etc.) and there is no ambiguity about what you want.
It does not matter what the value was before. Except for showing the slider knob in some position - a nice slider might grey out the knob or something with a start value of NULL/UNDEF.
A stepper is different - the function is to add or subtract 1 (or 10 or whatever) from the starting value. You can’t add one to “undefined”, it’s not the same as zero. So it can only be ambiguous what you wanted to happen, and many users will not like something unexpected happening instead. Just as you didn’t like nothing happening
It’s not unreasonable to have some kind of default behaviour, but it will not please everyone.
I want to act the “oh-stepper-item”-widget act like a setpoint widget in a sitemap
All the scenarios you said are already perfectly handled when you use a setpoint widget in a sitemap…
So I don’t see a point why the stepper in the mainUI should not act the same way.
I did not choose anything. No configuration was done. It seems to be “default” from 0 to 100.
Sure. My point is that when you come up with ideas for changing OH you have to take into account other people’s use cases, not just your own. Other people can and do set other options for max/min. If you choose not to do that, you have chosen to accept a default of 0-100 because that is a common use for e.g. Dimmers.
Just consider how your idea affects those users, does it need some refinement or clarification about what is wanted?
For an example, if the assumed value for NULL/UNDEF were taken as zero, that would mess up users with 100-200 scales. So it needs some other definition. This is your chance to see that this other definition does what you want.
(There’s a pretty obvious use case for steppers for thermostat setpoints, where you’d want values 10 to 30 say, and never zero)
I’m trying to help you. If you want some developer to write code for what you want, say what you want in your Github request. Else you’ll get what the developer wants. You already have that and don’t like it.
Don’t get me wrong. It is not about me, or that I want to put something into a direction that fits for me. I am using OH since years so I can handle this thinks pretty well.
It is more about the experiance for new users. It could be frustrating and it is not self-explanatory that a stepper-widget does not work out of the box.
So I like your idea:
Maybe in general it would be nice to have a parameter for all item types that defines an initial value.
But I have no idea about the carrying width in the development.
