Basic UI items not updating

Add-ons UIs
1

Running openHAB 2.5.0-S1628. Browsing with Firefox.

I realize there are something like a hundred threads labeled “Basic UI not updating”. I’m here to tell you it’s still a problem in S1628. Basic UI is finicky as hell.

If you create an item in the items file, it won’t have a value initially. If you then go to Basic UI to see it, it will be shown, and have no value (as it should). If you then give the item a value, Basic UI won’t reflect it until you hit refresh… and at that point Basic UI will ONLY update that value if you hit refresh – not automatically!

I’m not sure what it takes to make it update – i’ve had to play games like cutting the entire items file, saving, then pasting it back in and saving again. That sometimes gets it working.
I realize this may be akin to blowing on the cartridge edge connector.

If you create an item and make sure it has a value before you try to view it in Basic UI, things work better. Not quite perfectly, but after refreshing a few times it seems to realize that it should be picking up the changes.

But, that’s not the usual workflow when you’re building something.

As a maker, I’ve been conditioned to take small steps and verify my progress after each step, by a lifetime of experiences. It’s always when I skip checking my progress that I miss something that comes back to bite me later.

For this reason, Basic UI’s flakiness causes A LOT of problems – obviously not just for me, judging from the amount of threads about this.

Because Basic UI is simple on the surface, it makes sense to use it to check your work (did i create the item correctly?) before continuing on to other user interfaces. Heck, after three weeks of using openHAB I still have NOT attempted to tackle HabPanel! I need to master the nuts and bolts before then.

Just my two cents.

2 Likes
2

The only problem I see is you did not RTFM, especially the last line below.

image
image.png1024×292 11 KB

from

3

And you, sir, did not RMFP.
I’m not complaining that the item did not appear automatically. I’m complaining that it didn’t automatically update the state even after I manually pushed reload so that it became visible.

1 Like
4

Have you tried any other browser? Many of the not updating threads end up being specific to certain browsers.

I’m not certain that is still the case. I just tested it in Chrome and my visibility Items updated just fine.

Are you working with the “__default” sitemap? Or one of your own creation? The problem with the default sitemap is that it is basically a copy of the Control tab in PaperUI. Only those Items that are linked to Channels will appear. And there very likely could be bugs and stuff in that as almost no one uses the default one.

If you are writing your own sitemap, can you post it?

If it’s not updating, there really isn’t anything you can do as a user to make it update. There is a bug in the code somewhere, perhaps a Firefox specific problem, that is preventing it from updating or processing the updates.

Do you see any errors in the logs?

I just did what you described and everything worked as it should. I’m running in Chrome with a couple day old snapshot.

I agree with the overall approach but not so much with using BasicUI as the means to test progress. There are other places much closer to where stuff happens that are a better place to check.

For example, you’ve added a new Item and updated it. BasicUI is not showing the update. Did the Item update or is BasicUI not working? Instead of adding the extra layers of separation, use events.log, the REST API docs, or the Karaf console directly to verify that your Item changed state when it should have. Use log statements in your Rules to make sure the Rule ran when it should have.

Then once you know the Items are doing what they should you can build up your sitemap and test BasicUI separately.

1 Like
5

Important here. @leif A surprising effect of getting the sitemap filename wrong is a failure to refresh …

1 Like
6

Neither do I at this point! I just hadn’t expected BasicUI to be so finicky :slight_smile:

In this case I was using the demo configuration, with demo.items and demo.sitemap, making absolutely minimal changes since I am not confident in my prowess in this area.

At first, I added my own group and item. Recreating it here as an example, and testing as I go right now.

I’m basing my syntax on the Wifi_Level item from the demo setup, because that one works, and updates on the fly.

Group Homie          "Homie Floor"   <smiley>    ["Homie"]
Number HomieHumidity               "Humidity Level [%d/100]"                 <humidity>        (Homie)

Then I added a group item to the demo sitemap, as the very first line inside the first frame, like so:

sitemap demo label="Main Menu"
{
	Frame {
		Group item=Homie label="Homie" icon="suitcase"
		Group item=gFF label="First Floor" icon="firstfloor"
		Group item=gGF label="Ground Floor" icon="groundfloor"
		Group item=gC label="Cellar" icon="cellar"
		Group item=Garden icon="garden"

	}

At this point I go to Basic UI and see what’s there. Today I will do it in both Firefox and Chrome, in parallel!

image
image2542×249 19.3 KB

So far so good.

Now I edit demo.rules and add a line to the random wifi rule as follows:

rule "Set random wifi variations"
when
    System started or
    Time cron "/20 * * * * ?"
then
    postUpdate(Wifi_Level, (Math::random * 4.0).intValue)
	postUpdate(HomieHumidity, (Math::random * 100.0).intValue)	
end

…and be damned. Both FF and Chrome are updating just fine without me having to reload.
Shroedinger’s cat, anyone? This is not what happened yesterday…

image
image2541×144 15.5 KB

Now, for the first time I managed to link a button to an enum item on a Homie MQTT device!

Switch HomieRawButton "Doorbell Raw Button"   <lightbulb>         (FF_Homie)  { channel = "mqtt:homie300:ab60b3fb:nodeid1#doorbell" [profile="rawbutton-toggle-switch"] }

The log shows the HowieRawButton toggling on (or off) for every PRESSED-RELEASED sequence. Great!
Viewed from Classic UI, it works! The on/off switch in the GUI changes state.
In Basic UI, it’s currently NOT updating. If I hit refresh, it updates, but it still will not update automatically the next time. This is happening in both Chrome and Firefox. Behavior is identical.

Then, for shits and giggles, I tried in Microsoft Edge. I’ve never looked at openHAB through edge before. IT WORKS. Somehow the Basic UI switch is updating on its own. And yet neither chrome doesn’t, nor firefox. I even tried to create a new private window in firefox… Still won’t update on its own!

Visited from Chrome on another computer where I have never used it before… Still won’t update.
It’s not working reliably. I don’t know how much more proof is needed. It would be great if this could be fixed for M2.

Also, since I added that toggle switch, NONE of the items on that page are updating!

image
image1258×904 34.9 KB

Humidity, Precipitation, Wind Speed and Temperature were all updating before! Now they’re all static until I hit refresh.

Update:

After restarting openHAB and refreshing the pages, it works perfectly in both Chrome and Firefox, including the toggle switch! So, it doesn’t seem to me like the problem is in the browser end of the chain.

Is the Basic UI binding still being maintained or is it EOL?

1 Like
7

sometimes its random for me too. not hard to just hit refresh.

8

Thanks for that @Christopher_Hemmings , I’m looking for reliability though. Flaky systems become unmaintainable as they grow.

1 Like
9

Cache problem requiring a restart of the OH server after modifying sitemap. Then live update in basic UI is solid.

10

…yeah. Can it be fixed? I do understand long-time openHAB users may be used to it. I’m here to remind you that this is a bug and it would be great if it could be fixed. :slight_smile:

Look, I’m an experienced software developer and I’m only going to be an enthusiastic new user of openHAB for so long. It can be a useful combinations of things to be, if we choose to take advantage of it.

1 Like
11

You’ll know a simple reproducable example will go a long way.

1 Like
12

You’re right. There seems to be an element of randomness to it… yet, it seems to be failing half the time. If lottery odds were like that, I’d buy a ticket!

I’ll see how reproducible i can make it.

13

We like to call that a Heisenbug.

We never doubted you had the behavior observed. But there is a near infinity of things that could go wrong and what specifically is wrong needs to be isolated. At the moment I’m not sure a fix would be possible until a developer on BasicUI can reproduce the behavior and diagnose the problem. For that to happen an issue needs to be files on the openhab-uis repo. Search to see if an issue is already open.

One thing that I will mention though is almost none of us use Group elements on the sitemap. It only allows the presentation of Items using their default and there is no control over the order the Items are presented. Rarely is this what we actually want so most of us fully define our sitemap Item by Item. Perhaps the behavior you are seeing has to do with the fact you are using Group elements?

Yes and yes. It is still being maintained but it likely will not exist, or at best be considered legacy, when OH 3 comes out. According to schedule OH 3 would come out next January, but I’d not be surprised if that slips six months or more.

I do not believe I’ve seen any similar reports about flakiness with HABPanel. I’ve been doing more with HABot too. I like being able to craft cards dynamically and query for state to show just what I care about at the moment. It takes a little setting up with tags but it is well worth it. It’s a great administration and test tool, as long as you have your Items properly tagged.

Personally, my UIs are strictly for administration and test and I don’t even use them for that much, not because I found them unreliable but because I prefer to look closer to where the action is happening.

2 Likes
14

So I am able to consistently reproduce it. It happens then the id of the sitemap is not in sync with the label.

Following sitemap will not refresh, because demo !== Heating.

sitemap demo label="Heating" {
    Frame label="Downstairs" {
        Setpoint  item=Tado_DS_TargetTemperature  minValue=5 maxValue=25
    }
}

Replace demo with heating, and it works…

15

What is the filename of your sitemap?

This is relevant, because the result of not following the docs -

sitemapname shall always be equal to the Sitemaps file name, e.g. the sitemapname in a sitemap file named demo.sitemap must be “demo”

is that the UI does not refresh.

1 Like
16

Yes, that’s probably the reason.

But … is there any reason not to simply ignore the name of the sitemap from the file and use the name of the file? It would solve loads of the issues. The current design is just asking for mistakes.

17

You would have to ask the authors of the sitemap-using UIs. I would imagine there is a technical reason, yes.

Yes, people don’t always follow the written instructions. Quite often they don’t look in openhab.log, where this mismatch is highlighted by a warning message every time the file is loaded. Like many things, it gets learnt the hard way.
The current sitemap syntax is probably the most archaic part of openHAB, but it works. I do not know if it is likely to be overhauled for OH3 but I do not get that impression.

I don’t think your observation about the label= is true, by the by. It is the sitemap name that is significant. My names and labels don’t match.

18

According to some Twitter posts from Yannick, the old sitemap syntax will be supported but there is now a way to build sitemaps in the browser too which gets saved to JSONDB if I understand correctly. Given that I think this particular problem will go away, at least for UI generated sitemaps.

BasicUI and ClassicUI are going away in OH 3 so I think we can expect some more changes like this in OH 3.

19

I agree. It is about the mismatch of the name of the file with the name of the sitemap inside. But the symptoms were as described - the components don’t update. They don’t update in HAbmin as well.

Thanks for pointing it out.