Closed PaulL1 closed 1 year ago
Please run this command in your console and show us the result: bundle:list -s | grep ui | grep openhab
While I am running a 4.0 snapshot, I get this result:
183 x Active x 80 x 4.0.0.202303170310 x org.openhab.core.io.rest.ui
213 x Active x 80 x 4.0.0.202303170309 x org.openhab.core.ui
214 x Active x 80 x 4.0.0.202303170310 x org.openhab.core.ui.icon
216 x Active x 80 x 4.0.0.202303172211 x org.openhab.ui
217 x Active x 80 x 4.0.0.202303172206 x org.openhab.ui.iconset.classic
274 x Active x 80 x 4.0.0.202303191029 x org.openhab.ui.basic
You should have all these 6 bundles active and all from the same OH version.
Your first log message (enhab.ui.internal.UIErrorPageServlet) is logged by MainUI so I understand that you start Basic UI from MainUI. Can you try to start Basic UI directly, just by entering the URL in your browser ? Something like http://192.xxx.xxx.xxx:8080/basicui/app
Mine looks the same:
openhab> bundle:list -s | grep ui
101 │ Active │ 80 │ 3.13.0.v20200828-1034 │ org.eclipse.equinox.common
174 │ Active │ 80 │ 4.0.0.M1 │ org.openhab.core.io.rest.ui
204 │ Active │ 80 │ 4.0.0.M1 │ org.openhab.core.ui
205 │ Active │ 80 │ 4.0.0.M1 │ org.openhab.core.ui.icon
207 │ Active │ 80 │ 4.0.0.M1 │ org.openhab.ui
208 │ Active │ 80 │ 4.0.0.M1 │ org.openhab.ui.iconset.classic
271 │ Active │ 80 │ 4.0.0.M1 │ org.openhab.ui.basic
I don't start Basic UI from Main UI, I'm just refreshing a basicUI page that's already open on this URL: http://raspberrypi2:8080/basicui/app/?sitemap=default
If I restart with no pages open and refresh just that one page I still get that error. I've attached the full reboot trace with trace logging on the UI ( log:set TRACE org.openhab.ui). Nothing in there is jumping out at me, but it may give you some ideas. I also opened a browser on http://raspberrypi2:8080/basicui/app/ but that still gave similar errors as before, my interpretation is that it's falling back to the error page servlet for some sort of page not found error. It's not clear to me why it's not found, or where I'd look to see if there's something corrupt about the file, or perhaps something wrong with the paths. I'm assuming the fact the bundle is active would mean it was found and unpacked properly though.
Like I mentioned in the forum, I get the same error on openHAB 3.4.1 release, meaning the BasicUI is now broken.
openhab> bundle:list -s | grep ui | grep openhab
184 (0x Active x 80 x 3.4.0 x org.openhab.core.io.rest.ui
215 (0x Active x 80 x 3.4.0 x org.openhab.core.ui
216 (0x Active x 80 x 3.4.0 x org.openhab.core.ui.icon
218 (0x Active x 80 x 3.4.0 x org.openhab.ui
219 (0x Active x 80 x 3.4.0 x org.openhab.ui.iconset.classic
320 (0x Active x 80 x 3.4.0 x org.openhab.ui.basic
321 (0x Active x 80 x 3.4.0 x org.openhab.ui.habpanel
Like I mentioned in the forum, I get the same error on openHAB 3.4.1 release, meaning the BasicUI is now broken.
You are apparently running 3.4.0 and not 3.4.1. Did you encounter that issue with 3.3? All this tends to let me think it is probably not really a BasicUI issue. I am not sure there was any change between 3.3 and 3.4. This might be something else like for example compression enabled in communication with the server? But why only 2 persons encounter it?
You are apparently running 3.4.0 and not 3.4.1.
I'm not sure. Main UI /about/ says:
openHAB 3.4.1
Release Build
Did you encounter that issue with 3.3?
This is the first time I'm seeing the error, so no.
It was working fine until a few days ago. Before the error occurred, I was changing items, sitemap and py files, which were being uploaded with WinSCP "Keep remote directory up to date" using a very slow and error prone VPN connection. I probably restarted openhab before the error occurred too.
I have no idea what happening but I am almost certain it has no link with any change done in BasicUI code. In 3.4, the only changes were fixes for the color picker and support added for webaudio.
Maybe @wborn and @J-N-K have knowledge of core changes that could lead to that ?
2023-03-21 22:55:54.530 [DEBUG] [enhab.ui.internal.UIErrorPageServlet] - Returning index file as response with status 404 for request URI: /basicui/icon/switch
Why does it use path /basicui/icon/switch
and not /icon/switch
?
And tris log is done by code belonging to MsinUI. Maybe when MainUI tries to retrieve icons? No direct link with BasicUI.
Are you both behind a reverse proxy that rewrites URL?
I'm not using any proxy or any complex configuration. Raspberry pi with openhab installed directly on it, connecting directly to that raspberry pi on port 8080 from the browser. The issue occurs across two different devices (phone and laptop) and two different browsers on each (Chrome and Safari), so pretty sure it's not client side.
It seems to me that it's failing to find a file or files that it expects to find. I'm very willing to help debug that, but it's not clear to me where it would be looking to find those files. My best guess is that there's a package in the wrong location or a file permissions issue or something like that. In order to provide assistance with that, I'd need to know where the files that it's trying to return should be residing - I'm assuming it's /var/lib/openhab/xxxxx, but I'm not sure exactly where. Or perhaps they get unpacked into a temp directory on startup, or maybe they're memory resident. It seems unlikely they'd get unpacked again on every web request, so I'm sort of expecting to see them on the file system somewhere.
I don't personally think an upgrade caused this issue - it happened when I rebooted (some changes to the physical burner on the diesel boiler meant I had it powered down). I hadn't upgraded any time recently, and any upgrade always triggers a restart of openhab even if not the whole machine. When I got the issue I did then run an upgrade, but the upgrade did not trigger the issue.
It is plausible that I had upgraded months ago without restarting the whole machine, and that therefore some permissions or file location thing didn't take effect until the reboot. That seems to me the most likely problem - since it's clearly not finding the files to return, and yet the bundle appears to be present and active.
On the question of URLs and why it's using particular paths, this is what my browser console is reporting:
It seems to me that these paths are being requested browser side. I'm assuming they are embedded in the html page itself.
The page it is displaying below is: http://raspberrypi2:8080/basicui/app/
You can see the html is requesting, for example, material-icons.css and smarthome.js, which would be relative to the url - so http://raspberrypi2:8080/basicui/app/smarthome.js.
I wonder whether what's going on is that it's failing to find the basicui index.html (if there is such a thing), and is instead returning the index.html from the standard ui. That, in turn is trying to load the icons etc that it expects, but because the url that the browser requested was http://raspberrypi2:8080/basicui/app/index.html, it's all failing, because the page actually returned was http://raspberrypi2:8080/app/index.html. Does that make sense? It's clearly not that url, because I tried retrieving that page directly.
I'm not using a reverse proxy, just a VPN (WireGuard) to access remotely. I tried reinstalling BasicUI binding, without a restart, but same error.
Does it work if you use http://raspberrypi2:8080/basicui/app instead?
I think the issue is reproducible using URLs like:
http://raspberrypi2:8080/basicui/app/index.html http://raspberrypi2:8080/basicui/app/
Perhaps some redirect needs to be added to fix this.
I solved the issue.
I was using the following URL, which does not work: http://192.168.X.X:8080/basicui/app/
It does work when I use this URL, without trailing slash: http://192.168.X.X:8080/basicui/app
If you go to MainUI, click Other apps, BasicUI, then the correct URL is used.
I would say that is a bug. The existence or nonexistence of a trailing slash should not break an app.
This also works to resolve my issue. However, the URL I use hasn't changed for a long time - so it must have worked in the past then stopped working. Either way, happier with it working.
I am not sure it makes sense to end the URL with a slash while the URL can contain parameters (like sitemap). I am going to enhance the README to explain that.
I get that. It's just weird that it used to work, with parameters. I'm pretty sure I never entered that URL directly, so at some point in time it put that slash on automatically. With parameters it used to look like: http://raspberrypi2:8080/basicui/app/?sitemap=default Which I agree looks weird. I just wonder how many other people will have shortcuts, bookmarks etc that have stopped working.
@wborn made a change (whiteboard) in OH4 (PR #1600), maybe it introduced a different behaviour ? @wborn: WDYT ?
With parameters it used to look like: http://raspberrypi2:8080/basicui/app/?sitemap=default Which I agree looks weird. I just wonder how many other people will have shortcuts, bookmarks etc that have stopped working.
In what OH versions was this supposed to be working? I tried such URLs in some older OH 3 versions but for me it results in similar issues as with OH 4. Maybe it was only supported by the proxy config in openHABian?
@wborn made a change (whiteboard) in OH4 (PR https://github.com/openhab/openhab-webui/pull/1600), maybe it introduced a different behaviour ?
It is also reported to occur with OH 3.4.3 (https://github.com/openhab/openhab-core/issues/3561) which does not have these changes.
Refer this discussion on the community pages: https://community.openhab.org/t/basicui-not-loading-any-css-or-icons-after-reboot/145424
I'm running on a RaspberryPi with Debian and an apt install, currently on 4.0.0.M1.
My install was operating fine, after a reboot the basic UI wasn't delivering any CSS, Javascript or icons, and this is consistent across Safari and Chrome, and both on my laptop and on my phone (unlikely to be a cookie or cache issue). It is delivering the index page, but for all other pages there's a message in the log along the lines of:
Reviewing the javascript console I can see that for files such as manifest.json and the javascript files the actual content returned is the index.html (which is also what the error from the log above says that it's doing).
At that point I suspect I was on an earlier build, but I don't know what exact earlier build. I ran a full upgrade, bringing me to 4.0.0.M1, in the hopes of correcting the issue, but the problem continues to occur.
The iOS app is still rendering properly.
The icon bundle is installed and active, no bundles are reporting inactive. I'm assuming the icon bundle isn't the problem, as javascript and css also are not returned.
These lines from the debug log on startup were the only other things I found in the log that looked maybe relevant. They actually look OK to me, but it did fail to find an activate method - which may be because there isn't supposed to be one, or may be because something is broken.
I suspect a reinstall will fix the problem, but that wouldn't avoid other people getting the same problem. Are there more diagnostics I can usefully perform? I'm assuming the files themselves must be unpacked in a cache somewhere that I could look at to see if the files are potentially missing?