I just remember a crazy bevavior of Basic UI sitemaps since updated to OH3:
When opening Basic UI-Sitemap in a Browser, nealry everything works fine, except: Setpoints of heating devices. In OH2 I could push up or down to increase / decrease about 0,5°
Web-Basic-UI dont react on this under OH3. Everything else works fine.
Now the total crazyness:
If I use the App, I can increase and decrease those setpoints.
Right since this moment it works in basic UI too.
But after every restart, I first have to change one setpoint in the App to get sitemap in Web fully functional.
In openhab.log there is no Error at this time, only one error occured about 30 seconds later, don’t believe its the same.
Anybody else can confirm this behavior after a restart of OH3?
When you create the issue you will be presented with a form asking for a bunch of information and instructions for how to gather it. That would be the first step. Beyond that, answer any questions the developers ask in the issue .
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.
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.
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!
