OH3.1 Basic UI not updating

Setup, Configuration and Use Items & Sitemaps
#1

I have recently updated from OH 2.5 to OH 3.1 successfully. (running in a docker container on a Synology NAS)

I am now seeing a somewhat weird phenomenon which I didn’t have before (or mabye I didn’t notice).
I have a setup where everything is configured through files and I am primarily using the Basic UI.
The overall system seems very responsive. If I turn a switch (light switch or just a dummy switch from openhab) the reaction is immediate, meaning the light turns on or off immediately and the logfiles refelct that event change right away.
But when I have the Basic UI open (regardless if browser or android app) I notice the following. Everything works perfectly fine between xx:xx:25 and xx:xx:59 seconds, but starting with each full minute I do not get updates on the Basic UI. I have tried disabling rules and uninstalling bindings (not all of them yet) but so far no change.

I am wondering about any debugging tools that might help me with this. Is there anything on the karaf console? I read about rules threads and quartz threads, but it seems on OH3 some of them don’t even exist anymore.

I will probably continue to strip down my system until its almost naked to find the root cause, but maybe there is a smarter approach to this with the right tooling?

Thanks a lot in advance!

#2

Given that I do everything via files, I figured it would be easy just to move away my files step by step and see what impacts this.
(Re)moving the rules files didn’t do anything. Removing the items however made this go away. I left only my dummy switch and the Basic UI was always updating fast. I then started adding some item files which led to a situation where the system was only unresponsive between 03-11 seconds. That timeframe increased to the total of almost 30 seconds when I readded all of them.
Obviously each item file is somehow related to a different binding which might cause issues. But the fact that I didnt find like the one file that caused this, but rather each of my 20 files contributed 5% to this, I am wondering whether this is not about any of the particular bindings but some general openHAB mechanism that updates all items once a minute or something like this??

#3

Kind of documenting my progress :slight_smile:
Whether the sitemap actually contains all my items or not does not make a difference. If the items exist, it is slow.
I also tried 3.2 M2 but no difference.
When I use the new “page UI” everything is fine and updating immediately. That is kinda good, because it gives me a workaround, but also not that great because I do love the Basic UI for its “basicness”.
If I don’t figure this out though, I will probably migrate to the new UI…

#4

What persistence have you got operating? OH3 introduces a new default, you get rrd4j like it or not and everything is persisted every minute by default. Feels a possibility.

#5

That’s probably going a bit far. You get rrd4j by default but you can remove it like any other add-on. And if @El_Duderino is using addons.cfg then rrd4j won’t be installed at all unless it’s listed in addons.cfg.

Similarly, all persistence add-ons now have a default strategy that is used when there is no .persist file. But that can be overridden by creating an rrd4j.persist file.

Needs more information. Unresponsive how? Just BasicUI or OH over all? What do you see in the openhab.log and events.log? Does MainUI have the same problem or just BasicUI? What’s top tell you the CPU and memory are doing?

There is no such mechanism for updating Items. rrd4j will potentially save the state of each Item once per minute. But that happens in parallel and shouldn’t impact BasicUI or anything else, unless for some reason it’s causing problems to the whole machine (which top should tell you).

All the UIs work by subscribing to an SSE feed for all events from Items. Based on this feed it updates the UI as Items change state. My suspicion is that there is either something going wrong with the whole machine causing it to run out of resources, or there is something wrong specifically with that SSE feed.

OK, that points to a problem specifically with sitemap UIs only. Do you happen to have a phone app to test and see if it’s just the browser or sitemaps in general?

#6

Ok, regarding the “unresponsive how”
It is just the Basic UI not updating. Everything else is fine. The actual action triggered is happening right away (even from the basic ui). Also logfiles (openhab as well as events) are all good. IT is just that Basic UI is not updating. I can manually update (dragging down in android app or f5 in browser) and then it shows the current state, but it doesnt update automatically. It does do so after that timeframe without any intervention.

I am using jdbc/mariadb and have also changed the default persistence to that. I am however only persisting very few items and most of them only end of day.

I created a simple page with the new ui and that one always updates immediately when Basic UI doesnt.
Here is a video showing both UIs (I also added the time in the new one):
Video
I used the android app on my phone (basic ui) to turn the switch…

#7

Caution: ‘default persistence’ means ‘use this one’ for charts etc.
It does not mean you cannot have multiple services installed, it does not mean that you didn’t get rrd4j anyway. Find out, be sure.

1 Like
Unit mismatch - where do I start finding the issue?
#8

Wow, that was it!!
I uninstalled rrd4j (not sure if there is an easier way to disable it) and everything works!!!
I have like 668 items and even though I understand that it doesnt persist Strings, I guess it was enough have this effect.

Thanks alot!!!

Unit mismatch - where do I start finding the issue?
#9

But now the problem is why it didn’t work. 668 Items is not that many really. There should have been no problem caused by rrd4j on this, especially one that would cause only BasicUI to lose events but not the other UIs. It doesn’t make a whole lot of sense. I’d be wary as this point to the fact that you are running on the very edge of what your hardware can support.

1 Like
#10

It’s sharp observation on your part to see the “every minute” effect.

It certainly would be interesting to understand this more, there may well be many folk suffering poor performance without really recognizing it.

In your particular case, it could have something to do with updating files in docker/NAS environment, can’t imagine what.

Something about hogging HTTP resource perhaps.

#11

That was my first idea any way. So I started to give the docker image more cpu priority and more RAM.
But that had 0 effect.
Also the Synology NAS is decently powerful (DS918+ with 4 gig) and does not show significant cpu or mem usage for the docker or in general…
I doubt that it is the bottleneck.

#12

Not sure if this helps at all, but I did reinstall the rrd4j persistence and did another test where I watched the network traffic of the website. I was actually curious whether after that timeframe all of the “lost” events were actually transmitted or whether they were actually lost.

image
image1554×988 113 KB

As you can see before the full minute it is swichting back and forth. Then after the timeframe elapsed a couple of messages are being sent at once, but not with alternate states as I would have expected but only multiple ones of the current state ON (most likely that fits to how often I toggled). When the current state was OFF it’s the other way around.

#13

That looks like a queue of “send the state” tasks built up. Then when the queue is released, all the tasks send the current state (which is a reasonable thing to do, for this UI purpose). Maybe the underlying issue is more like persistence putting a lock on the Item; competing for access to Item rather than system resource.

You might add a rrd4j.persist with a handful of Items, which should kill the default ‘everything I can’ processing. That should show if problem is related to the mere presence of the rrd4j service (which is doing its own compression from time to time, I don’t know when) or to active persisting.

#14

Hmm, I put like a 100 items into that persist file (everyMinute) and surprisingly there was no delay at all.
Almost as if this is caused by some specific items?

#16

You understand these are not wildcards in a xxx.persist file? This says persist all members of Group ‘a’, all members of Group ‘b’, etc. No Group by that name, or no members, no action no complaint.

#17

Yeah that was my bad. I was looking for a way to add a big chunk of my items.

It took me some time to come to another conclusion or theory for now. I believe that my rrd4j persistence is not working at all as none of the settings in my rrd4j.persist file did anything.
When I look at the API explorer at

http://192.168.178.34:8080/rest/persistence/items?serviceId=rrd4j

it gives me an empty result, no matter what I configure, even if I remove the file, which should enable the default behaviour.
So I’m wondering if my rrd4j persistence service runs into some kind of error, or possibly lots of errors (for all my items), doesn’t even end up doing anything but causes my performance issues.

#18

That’s quite possible; 600 odd requests all waiting to time out. Look in /userdata/persistence/rrd4j I think for individual archive files for each Item. As simple as a permissions issue perhaps. You should still have 600 odd from ‘default’ setup, but any still active should be given away by their datestamps.
That would give us a new mystery of why it’s not spamming your openhab.log

OH3 Page's loading slow
#19

I don’t really get what is going on.
When I install rrd4j, it creates the files for each item and it also seems to update them. And my best guess is that the whole Synology NAS Docker Container setup is rather slow when it comes to updating or touching a couple hundred files in a folder mounted to it. And maybe there isn’t much that can be done about it (which is fine for me as I don’t need the rrd4 persistence).
I am still confused by what I saw in the API explorer as it never shows any items when I specify rrd4j as a service. So there might be errors in the background but nothing visible to me in logfiles.

#20

It was like that in OH2 as well. Querying individual Items via REST should work, but take care that number of records would vary by period requested due to rrd4j archiving structure.

Seems possible.