No autoupdate in basicui after sitemap update

  • Platform information:
    • Hardware: RPI3
    • OS: Openhabian V1.4
    • openHAB version: 2.2
  • Issue of the topic:
    The issue was alredy existing with previous versions of OH.
    When starting the system the Basicu gets automatically updated when values change (Clock, Voltages…), as it should.
    After editing sitemap file and saving this gets updated as indicated in the log. No errors in the log.
    But then the update of the Basicui stops in the browser. I always need to press F5 to see the update.
    This happens in Chrome and also Firefox on my Win10 PC.

How can I fix this behavior?

Currently I need to sudo shutdown -r to get it back to work.

Holger

Has anybody else seen this behavior?

Yes, Having the same issue. Anybody have any ideas?

I have had this and still have this on occasion. Usually clearing the cache did solve it

Ctrl+F5 should solve the problem, shouldn’t it ?

Yes, refreshing the page works fine. But I would have thought the page would update dynamically as changes occur. I have setup a temp sensor that is working great, but same issue. Unless I manually update the page then the temperature number does not update, it does diaply , just not updating dynamically. Or am I missing something. (even tried it with a rule and that did the same thing, rule fired ok, but value on page did not update) - Same thing in mobile app.

1 Like

I just tried in an Eclipse dev environment on a Windows 10 PC + Firefox to run Basic UI on the PC and Chrome to run Basic UI on an Android tablet.
I can update the demo rule file or the demo sitemap and then my 2 Basic UI continue being automatically refreshed automatically. I can see that there is an automatic switch to the home page after the file saving.
So this is certainly not a general problem.

And I even don’t need to use F5 or Ctrl+F5.

I’m not sure if this is related, but my sitemaps are not updating. I have three openHAB instances. All three instances have a sitemap that contains the current date/time, which should update every minute. The NTP binding is online in all three instances.

One instance is running build 1140. On this instance, the date/time on the sitemap updates automatically as it should when the item is updated every minute by the NTP binding.

The other two instances are running build 1160. The date/time does not update on these sitemaps.

In one case, I see no activity at all in the browser console.

The the other case, I see some strange behavior in the browser console. And, I get the “Offline: waiting for connection to become available” message every minute. In the console log below, you can see where the eventsource REST API call blocks for about 50 seconds.

@Lolodomo I know you are familiar with the SSE functionality. Can you shed any light on this?

Maybe you encounter this issue: https://github.com/eclipse/smarthome/issues/4678

I am running snapshot 1140 too and I think I can’t reproduce this issue.
I just opened a Basic UI in Firefox. After few minutes, my date widget is still updated. I will keep the browser opened more time and see what happens after 1 or 2 hours.

What you see in your browser console is very probably normal. The requests ends when a data is received and the last one is in pending state waiting for an update.

@mhilbush: note that your issue would be totally different as the original issue is indicating that the refresh is stopped after an update of the sitemap. This is not your case ?

That’s because 1140 works correctly. :wink: : On 1140, I see this in the console, which is what I would expect. Every minute the state updates through the existing SSE connection.

Based on the above, this doesn’t look normal. It looks more like the page is refreshing?

8afbec7067e2e99c5c339f980dd7d87763c48915_1_690x308

Agreed. It does look more like this one SSE connection crashes on DateTime event updates · Issue #4678 · eclipse-archived/smarthome · GitHub

Snapshot 1140 was built mid December with the last available ESH stable version. At my knowledge, all the next snapshots include the same ESH version. That’s surprising that you can see such difference as it means that there is no change neither in the core framework nor in Basic UI.

What’s odd is that 1140 and 1160 both are running the same version of ESH (from 12/14).

Edit: I must’ve posted this at the same time you posted the above. LOL.

I need to look into this more closely to try to understand why I’m seeing different behavior.

Maybe the problem is already present in snapshot 1140 but only occur in very particular cases, maybe depending on OS or JVM on which OH is running.

Hmm.

These systems are not working

Linux system1 4.4.0-104-generic #127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Linux system2 4.4.0-104-generic #127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

This one is working

Linux system3 4.4.0-101-generic #124-Ubuntu SMP Fri Nov 10 18:29:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Mine is

Linux xxxxxx 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l GNU/Linux

and is apparently working well.

JVM versions are the same across all three systems.

openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)

Not quite sure where to look next…