They show the right value and persistence already had got the history values after restart. And some rules already changed. So null could not be the problem.
Using Firefox 84.0.2, Just looked in debugger, it shows Error 400 Bad Request
POST http://10.10.10.201:8080/rest/items/OG_Bad_Thermo_Soll_Temp
Status
400
Bad Request
VersionHTTP/1.1
Übertragen623 B (0 B Größe)
Referrer Policyno-referrer-when-downgrade
|||
| --- | --- |
|Accept|*/*|
|Accept-Encoding|gzip, deflate|
| --- | --- |
|Accept-Language|de,en-US;q=0.7,en;q=0.3|
|Connection|keep-alive|
|Content-Length|9|
|Content-Type|text/plain|
|Cookie|X-OPENHAB-SESSIONID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
|Host|10.10.10.201:8080|
|Origin|http://10.10.10.XXX:8080|
|Referer|http://10.10.10.XXX:8080/basicui/app?w=10040002&sitemap=Home|
|User-Agent|Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0|Are you keeping the app open when restarting OH? I think it needs a refresh to re-establish event listeners.
No, a fresh opened browser, fresh startet PC, restart openhab was yesterday.
What I found in Debug Info of Firefox is crucial Content:
XHRPOSThttp://10.10.10.201:8080/rest/items/EG_Kueche_Thermo_Soll_Temp
[HTTP/1.1 400 Bad Request 4ms]
1
18 %unit%
In my opinion %uni% while want to go to 18.0 degrees is wrong causes the error.
I’ll go along with that, Basic UI is sending a command to Quantity type Item with invalid unit.
You’d think that would go wrong forever, but I guess the UI must pick up the correct unit from the Item state sometime afterwards - looks like from a state update (that you provoke from app)
It’s missing getting it from the initial load of all states.
As I saw already OH2 had the issue to make value 4 instead of 4.0 at restore.
Persistence didn’t make difference between int and float. While using a variable item with a numeric status (1-4) I saw that.
But in OH2.5 never got problems with the steppingstones 
I have this too
I don’t think it is related to null values as the values restore from persistence, it’s just the set point doesn’t work
It could not be because of null values! I didn’t restart openhab since two days and today I have the same. I first have to change via App, then able to change via Browser
Because there was no change due to persistence, only by rules, this could not be the problem.
Just a deeper Analysis:
a) No Restart within two days, fresh opened Broswer:
Command per method post with 19.5 %unit% gaves a failure.
b) Using App, then use Browser again: Command method get is successfull.
So the Basic UI working with post before App is used, after usage of App it uses get and all fine.
Because all other Items in Web UI Using GET (just checked), this seems to be the reason, there is a bug in Basic UI causes setpoint after open the sitemap to cause PUT instead of get!
I have (almost) the same issue. The common denominator could be the web GET/PUT, or some server side script on the page that needs to run once to initialise. Perhaps related to browser cache refresh etc.
EDIT: I will do some more bug testing, and report back…
I think it is neither related to the App (since I don’t use it) nor is it related to GET vs. POST. In my case I have the same page open in the browser. And I am clicking on the same UP button on a setpoint control. Sometimes it fails, and then later I can make it succeed. In both cases the browser sends an HTTP POST request, which you can see below are the respective WireShark traces of the two cases.
1. First Attempt: Push SetPoint Up Button (failure)
POST /rest/items/Front_Bedroom_Radiator_Target_Temperature HTTP/1.1
<headers>
Content-Length: 9
17 %unit%
HTTP/1.1 400 Bad Request
2. Second Attempt: Push SetPoint Up Button (success)
POST /rest/items/Front_Bedroom_Radiator_Target_Temperature HTTP/1.1
<headers>
Content-Length: 6
17 °C
HTTP/1.1 200 OK
So the issue is definitely and solely due to the ‘17 °C’ vs. the ‘17 %unit%’.
And so the question is: Why is the exact same button in the exact same browser page first sending a faulty request, and then sending a good one? Please look at the following sequence of screen shots…
- First load of the sitemap page | Press UP button | Fails!
- Move presence switch OFF (setpoint visibility is linked to this)
- Page reloads (setpoint not visible) | Move presence switch ON
- Page reloads | Press UP button | Succeeds!
FACIT: the page reload causes the same UP button in the same web page to go from failing to succeeding…
More over on GitHub…
Displaying a good state like 17 °C while failing by sending nonsense like 17 %unit% shoots down my theory about failing to fetch state.
I tried reload the page to, no change I m out of ideas.
Nearly: We are on the way. But that code lookd good. We have to do deeper search in getUnit
Yes, thats my plan tomorrow 
I m no developer, but looked deeper from function to function until system units in another imported code. Maybe because of metric or what else. I think needs somebody more familiar with Java as I am
The issue has been solved…
As long as the new openHAB version is not released that contains this fix you can just set a label to the widget in the sitemap as a workaround 
Thanks to @AndrewFG for providing the piece within the sourcecode where I started debugging
To be specific you need to set a label that contains a unit format string e.g. “Setpoint [%.1f °C]”
1 Like