Crazy bevavior in Basic UI OH3

Setup, Configuration and Use Items & Sitemaps
,
Tags: #<Tag:0x00007f17374af290> #<Tag:0x00007f17374af1c8>
#1
  • Platform information:
    • Hardware: Dell Server
    • OS: Ubuntu 20.04 LTS
    • Java Runtime Environment: 11
    • openHAB version: 3.0.0 stable

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?

SiteMap 'visibility' tag seems to disable SetPoint Items
#2

This sounds like a subtle bug and an issue should be files on the openhab-webui repo.

#3

Anything I could do to help finding the reason?

#4

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 .

#5

Just a hint, have you tried it in incognito mode or temporary disabled any adblock or noscript extension?

I tried it here with chrome on android and it works like expected, same in app.

#6

See

That may be because Items are still NULL. UI Setpoint widgets don’t work very well without an initial value.

#7

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.

#8

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|
#9

Are you keeping the app open when restarting OH? I think it needs a refresh to re-establish event listeners.

#10

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.

#11

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.

#12

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 :confused:

#13

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

#14

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!

#15

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…

#16

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…

  1. First load of the sitemap page | Press UP button | Fails!

image
image694×388 26.1 KB

  1. Move presence switch OFF (setpoint visibility is linked to this)

image
image694×388 26.8 KB

  1. Page reloads (setpoint not visible) | Move presence switch ON

image
image694×325 23.7 KB

  1. Page reloads | Press UP button | Succeeds!

image
image694×391 26 KB

FACIT: the page reload causes the same UP button in the same web page to go from failing to succeeding…

SiteMap 'visibility' tag seems to disable SetPoint Items
#17

More over on GitHub…

#18

Displaying a good state like 17 °C while failing by sending nonsense like 17 %unit% shoots down my theory about failing to fetch state.

#19

I tried reload the page to, no change :confused: I m out of ideas.

#20

I think I identified the problem see the issue thread on github