[bug] Page Item State does not update, after a visit to Settings Model

[leif (Leif Claesson)]

OpenHAB 3.1.0 arm64 docker on arm64 Pi4 RaspiOS Bullseye
Client: Windows 10 20H2, Firefox 94.0.2, Chrome 96.0.4664.93

I’ve used OH2 for 3 years but I now have a brand new OH3 setup with simple test device, just trying to familiarize myself with the new platform and to wrap my head around how to make it work with my devices.

Right now I’m testing with an ESP8266 on a breadboard with 7 colored LEDs which present themselves as a single-node Homie device with 7 properties (all booleans) which are presented in openHAB as 7 switch-channels, and again 7 items. So, it’s a very simple test setup.

I’ve found the following reproducible bug (at least in my setup):

The switches on the Overview or Equipment Page, namely these ones:

Or these ones:

After you have visited Administration - Settings - Model, the above controls stop working properly!
They work once but the reflected state on the page does not update.

Imagine that the LED is OFF, and the button state is OFF.

When in failure mode, if I click on it, the LED turns ON, but the button state remains OFF. At that point, clicking on it again will not turn the led OFF. The LED will remain ON, and each time I click the button, openHAB sends an on command (well, true, actually) through the MQTT server to the homie device. The openHAB item state in the web browser UI never updated, so when you click on it, it keeps sending the state it’s already in.

When in failure mode, if the LED was ON to begin with, then in failure mode it goes OFF, and keeps going OFF, never turning ON.

If you reload the page, it magically “solves” the problem and the controls work again.
But, if you go to Administration - Settings - Model, and back to the overview page, again they are broken. You don’t even have to click on anything on the Model page! Just visiting that page breaks the controls.

I guess this won’t matter that much once my setup is fully done (as if that will ever actually happen!) but it’s sure going to be annoying during setup.

I’ve tried with both Chrome and Firefox, behaves exactly the same on both.

Has anyone else experienced the same issue?

[JustinG]

Have you configured anything on your model page yet? This sort of behavior has been seen in the UI when there is something that causes an error in one of the pages.

Some errors during UI page rendering cause the connection to the events stream to silently fail and then you get the observed disconnect between widgets and items. I’m currently having the same issue with one of my custom pages which means there’s an error in one of the widgets I have included on that page, but I haven’t had the time to track it down in the last few days.

If the problem happens when you navigate to the Model page then the error is in some model configuration that the UI is failing to read because it is a faulty config.

[leif (Leif Claesson)]

Thanks for your reply @JustinG,

As far as I know, I have not configured anything on the model page yet – I’ve only added a couple of Homie devices (MQTT binding).

This isn’t a custom page as far as I know, this is the settings - model page.

Here is the entirety of the settings - model page. All the items are working on this page, toggling them correctly changes the state of the device. I’m not seeing any errors. If there’s an error, that would be a good thing to clearly display, instead of failing silently?

There certainly may be an error but I haven’t knowingly configured anything, i’m trying to take the smallest possible steps in the beginning to make sure I can make things work one by one, and this is the very first thing I came across after adding a device and trying to make controls on a custom page – and all of those do work, if I make sure not to reload after visiting the Model - Settings page.

This seems like too big a bug to slip through even the most cursory testing… am I doing something wrong? Or is it just an edge case?

Maybe I ought to be working with the latest 3.2 milestone so I can report things there, where developers may pay more attention?

[leif (Leif Claesson)]

This issue appears to be FIXED in 3.2.0 Milestone 5!