If new item without value is defined as setpoint not able to change in App.
In basic UI no value is interpreted as 0, so increase and decrease works for new items not having a value yet.
In App increase and decrease (same item, same Sitemap) don’t work if initial value not set (shown as -)
Sounds like an issue for the IOS App, please file it there.
The workaround abviously is to set a value from BasicUI.
I don’t think there’s any reason for a setpoint to handle NULL states. Pretty sure the ClassicUI widget didn’t either.
You’re asking for the UI to make something up out of thin air. Zero may not always be appropriate; what if you have min/max settings?
It’s easy enough to create a ‘bootstrap’ rule. If some Item has a NULL value at startup, then set it to a value of your choice (rather than what a UI author thinks is best for you).
The point is that undefined NULL/UNDEF are not zero nor meant to be, they are undefined. There is no sensible starting point for a +/- setpoint widget.
Well, I think while creating a new item it should work to set a value in App too without doing some rules on boot time.
I use items for preferences like comfort temperature or raise blinds x minutes after sunrise.
All persistent, but if creating a new item for the first use writing a rule to set an initial value sounds some strange for me 
Hope was able to explain, because no native English speaker
Added: in this case example 2 with min=-120 and max =600 and step 30 was used.
I understand what you want; I don’t think its sensible for everyone else.
If you want to set a value one time only, use API explorer, again allowing to set a value with units if needed and not what someone else thinks is best for you.
I could solve for myself, sure. But I’m thinking about user experience for users want thinks just work.
So (just my point of view) such things are easy to integrate and let new users despair should be done. not a Java familiar programmer but a row „if null then 0 at the beginning of setpoint would solve this
That is not the only way. One can create a MainUI widget to enter an initial value. One can update the Item through the REST API or the Karaf console.
What rossko57 is saying is that your proposal for how to initialize the state of an Item using a Slider widget may break a whole lot of other people’s “user experience”. Your particular use case is not privileged over their use cases. A system like openHAB has to necessarily opt for supporting the maximum number of use cases at the expense of “user experience” in some cases because if we choose for you we may choose incorrectly.
As rossko57 indicated, initializing an Item at 0 with the slider could be disastrous in some use cases. So OH forces you to choose the correct initial value for your use case. The alternative is that for those users needing a non-0 initial value are completely unsupported.
Thank you for giving this so much off your time to explain.
If you are right, then basic UI has a bug, because it has got the behavior I would expect at App too. If there is a null value I am able to press increase and in that moment null is interpreted as zero and increasement is done one step.
Sure there are use cases null is important, but in that case no one would increase or decrease setpoint in Sitemap
I didn’t talk about null is allways zero, but at Moment increasing in Sitemap, null in my example should be able to increase to 15
zero is the middle of your Item’s range. There’s an equal argument that an uninitialized value should start at your min, -120.
I don’t think it matters to the argument, but we should remember that UI never directly affects Item states anyway - it issues commands.
I think so, yes. No-one will be interested in it now.
Totally agree, Ui never should affect item states without an action.
If it starts at minimum or zero: for me it’s equal. Just can push increase one time more.
But at the moment there is no way in app to change value from a null value. Equal push arrow up or down: in app there is no way to change via setpoint.
Yes, I understand. I think that is correct behaviour. You can’t add or subtract anything to “undefined”, and it’s not the UI’s job to guess what is meant instead.
Bear in mind that Items can get into undefined states deliberately, say as a result of communication errors. You might not want to hide that.
Hm, so question what is the best solution?
Some examples for setpoint behavior of basic ui (don’t know if ui or backend does the work)
All examples with new item null and behavior of press increase:
Min=5.0 Max 30.0 step 0.5 => increase item becomes 5.5
Min=-60 Max 600 step 30 => increase item becomes 30
In App: increase without function.
So if value is set in the backend as you say: somewhere must be a difference because of different behavior
Don’t want to hide, totally agree. But a pressed increase should be able to come to an acceptable state again
Well yes, this is autoupdate at work. If the UI sends a command, autoupdate will massage it into a state change, and state change then gets reflected in the UI.
In my view, BasicUI erroneously applies an interpretation that “undefined +1” is meaningful, while the app/ClassicUI think it’s still “undefined” and are thus unable to send any meaningful command.
UI sends INCREASE as the command.
That command goes to the Item and then to AutoUpdate and the binding.
AutoUpdate is probably going to say 
when it comes to an initial state of NULL.
If the Item is NULL, that probably means that the binding is also going to say 
because it has no idea what state the device is in so it doesn’t know what state to increase it from. It doesn’t even know if the device is ON. The fact that the Item is still NULL could indicate there is some problem with the device for some technologies.
If the UI element is a Slider though, even if the Item is NULL you should be able to drag the slider to a point in the range and that will send the command to the Item. Now the command is a discrete number so it doesn’t matter that the Item started out as NULL. AutoUpdate says “yep, I can set the Item to that number.” The binding says “sure, I can command the device to move to that number.”
So maybe you can achieve what you are after using a Slider and moving the slider to a specific desired point instead of a setpoint and INCREASE/DECREASE commands.
I don’t think it does, really. The Sitemap Setpoint widgets calculate a new numeric value as command. BasicUI thinks NULL+1=1, other UI think it’s undefined and so no command is sent.
That’s counter intuitive. Shouldn’t it be up to the binding/rules/autoupdate to determine how to interpret that command? What’s the point of INCREASE as a separate command at all then?
These are rhetorical questions really as has been mentioned, I doubt BasicUI will change much.
That’s exact, what I tried to explain. And if pushing a button in UI I would expect a change of the item.
In my case the item is not linked to a binding or channel, so only an item.
Well, the Setpoint widget allows you to specify step size, max, min. This is would not be possible with INCREASE/DECREASE command use. Some other mechanism could be used of course.
Further, Setpoint widgets are not tied to any particular Item type,and are commonly used with Number types that do not accept INCREASE/DECREASE.
Setpoint widget does what it does. There’s no reason some other widget shouldn’t be invented to do a increase/decrease only function.
But I think that’s a sideshow; NULL+INCREASE remains just as undefined as NULL+1 in my view. so I don’t think it matters.