5.1.0.M3: Main UI shows blank screen on Android

Hello Openhab forum.

I migrated yesterday from 5.1.0 M2 to M3.

Now, the Android GUI only shows a blank page either in the OH App or in Chrome.

I could bypass the problem with an invalid target URL. Example https://openhabian:8443/false .

OH displays an error page including a ‘GO HOME’ link that takes me to the main UI.

But if I copy that link and try to use it later I end up to the same blank page.

Anyone having similar issues ?

Try clearing web caches.

Cleared all Chrome history.

Cleared Chrome cache…

… But no luck :slightly_frowning_face:.

Another bypass is to activate ‘Desktop mode’ (works for Chrome, not for the OH App of course).

But this is not great to use.

I am a bit out of ideas what to do, I also have no Android device at hand. I got reports from some early testers that Main UI on Vue 3 works in Android.

We do talk about Main UI? Or what do you refer to as the „Android GUI“?

Which URLs did you try?

I upgraded my test system (very basic very few items, currently no real things).

Snapshot level to 5.1.0 M3. Same problem.

The Chrome URL is:

https://openhabian-test:8443/overview/

The Android App URL in the server definition is https://openhabian-test:8443/

… Both take to a blank page.

Same issue here, on both Android and Brave (chrome) desktop browser. Firefox works OK however, and it seems that a solution is to use the url http://openhab:8080/page/overview instead of just http://openhab:8080 which worked before.
Whether this change is intentional, or a simple typo, will no doubt be addressed by those in the know!

I reinstalled an brand new OH on my test PI5.

Upgraded OH to 5.1.0 M3.

Upgraded the system.

Rebooted.

Tried to access the GUI https://openhabian-test:8443/overview/ .

Works OK.

Then I restored my configuration backup. And rebooted.

Problem comes back.

Also note,I already said it: the same access from my laptop or when using ‘Desktop Mode’ on Android Chrome does work.

And as BEN wrote, adding ‘page’ to the URLs works (works also for properties for example). Thank to him, that gives a clean bypass.

So, the initial launch of https://openhabian-test:8443/page/overview/ takes you to the Overview page and the other, all with the ‘page’ sub URL.

And for the Android App, the server URL to set up must be https://openhabian-test:8443/ and the Main UI start page field /page/overview/ .

Well, the GUI UI, even if I can now access it, fails many times as well on Android (App and Chrome) as on Chrome Desktop.

Often related to going to the previous page.

On Android, the App takes you to the Overview page instead of the previous one, sometimes the display doesn’t fully apear. Sometimes the App gets frozen trying to display the page. Restarting the App bypasses the issue, but very unfriendly.

On Chrome, sometimes I’m back to the Overview page, sometimes to an error page ‘Requested content not found’ for a ‘/overview’ URL.

Anyone having a fix for this problem ?

I may also consider reindtalling 5.1.0 M2.

I’m not saying that all the things you experience have been fixed (I don’t know that), but many things have been fixed in the web UI lately, so my guess is that at least some of them have.

It’s a shame that there’s no easy way to update the web UI, but I don’t think there is..?

Thank you for the information.

What do you mean with ‘lately’ ? By some fixes AFTER 5.1.0 M3 ?

Yes. There was a big upgrade of some of the things that power the web UI between M2 and M3, and this led to a lot of issues. Many were solved before M3 was released, but it’s not easy for a few to test “everything”, so a lot more has been discovered after M3 was released. Things are being fixed rapidly, that doesn’t mean that everything is fixed obviously, but many things are. In a way, it’s a shame that users can’t easily get access to the latest version, so that only the problems that remain could be in focus.

Thank you very much.

If I wanted full stability, I’d have stayed with the 5.0x stable. If I were an adventurer, I’d install the latest snapshot.

In between, there is the Milestone version.

I’am aware that there may be little glitches. As I don’t help developping, using and testing it is my small contribution to the OpenHab community.

:laughing:

Log in to the Karaf console, then run:

bundle:list org.openhab.ui

Remember the bundle ID (three digit number).
Then run:

bundle:update BUNDLE_ID https://ci.openhab.org/job/openHAB-WebUI/lastSuccessfulBuild/artifact/bundles/org.openhab.ui/target/org.openhab.ui-5.1.0-SNAPSHOT.jar

This will update Main UI to the latest build from our Jenkins CI server – no openHAB restart required.

1 Like

That should probably be documented somewhere where people can easily find it - together with how to downgrade to the “standard bundle” if things go wrong.

I wanted to do this for a long time … unfortunately didn’t do yet and do not know where to put it.
Maybe somewhere under the Main UI section in the docs: Main UI | openHAB

2 Likes

Because it’s a console command, maybe it belongs on the Console page of the administration guide? Either place seems reasonable to me.

Now that you mention it, I would rather put it to the console page. It’s not too prominent there but still visible.

The question is if somewhere “more prominent” should link there, informing that there’s a way to update the UI if there’s a bothersome bug without updating OH, or if “helpers on the forum” should just send users there.

Question if this is also possible for the add-ons?

Because sometimes there are some really fixes needed example changed API from the service you want to connect to (e.g. pihole or zwavejsui are examples)

I think that it’s likely to be more difficult for add-ons, but in principle the same should be possible, e.g.:

bundle:update BUNDLE_ID https://ci.openhab.org/job/openHAB-Addons/lastSuccessfulBuild/artifact/bundles/org.openhab.binding.pihole/target/org.openhab.binding.pihole-5.1.0-SNAPSHOT.jar

The problem is that there’s no guarantee that the latest build is compatible with the version you’re running, the likelihood that it will work decreases the larger the “version gap” between your system and the latest is. The web UI has one “advantage” in that it works quite independently of Core, so conflicts are much less likely. Bindings on the other hand, can “become incompatible” quite frequently. But, essentially, you can try and see, but you should know how to restore the “original” bundle if it doesn’t work, before you start.