OH3 (3.0.2) Clients get 404 on habpanel documents

Here’s a really strange one.

I had habpanel all working on my iPhone, laptop and desktop. (Laptop and desktop both Mac’s running 11.3.1). All using Safari.

HabPanel is run from a R-Pi4 (4GB) running OpenHabian on it with OH 3.0.2

Then suddenly my laptop started to get a message saying habpanel was trying to connect to the server. Looking in the developer pages for the browser, the network trace shows 404’s for all the included docs under the main habpanel. e.g. styles.min.css, All the .js files. Only the index.html is served OK.

I removed habpanel and reinstalled it. Same thing. Restarted the OH3 (reboot & a simple restart of daemons).

Anyone seen this? Is it a screwy setting somewhere? There’s nothing obvious. No errors in openhanded.log (Does the web and REST instance log anywhere separately?)


I’m not positive but I don’t think the embedded docs are actually embedded. I think they reach out to the pages hosted at https://openhab.org/docs. Sometime after the release of OH 3 there was a complete rearrangement of the UI docs and the HABPanel docs are in a new location I think. Maybe HABPanel itself wasn’t updated to point to the new location.

Can you see the actual URLs that are being used that generate the 404’s?

What happens when you try with curl i.e.

curl -v http://yourip:8080/habpanel/app/app.js


Hi Rick. Thanks for the reply

Does the OH3 server act as a proxy for those docs? or is the browser supposed to pull them back directly from openhab.org?

Currently the browsers always try to pull from the OH3 server. URL’s look like this


I’m thinking that they must have been served from the OH server (Or via the OH server) at some stage because my 1 client that does work still has them cached. No doubt that will fail as soon as it tries to check/refresh them.



hamish@thunderstruck Downloads % curl -v http://openhab:8080/vendor/styles.min.css
*   Trying
* Connected to openhab. ( port 8080 (#0)
> GET /vendor/styles.min.css HTTP/1.1
> Host: openhab:8080
> User-Agent: curl/7.64.1
> Accept: */*
< HTTP/1.1 404 Not Found
< Cache-Control: must-revalidate,no-cache,no-store
< Content-Type: text/html;charset=iso-8859-1
< Content-Length: 338
< Server: Jetty(9.4.20.v20190813)
<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
<title>Error 404 Not Found</title>
<body><h2>HTTP ERROR 404</h2>
<p>Problem accessing /vendor/styles.min.css. Reason:
<pre>    Not Found</pre></p><hr><a href="http://eclipse.org/jetty">Powered by Jetty:// 9.4.20.v20190813</a><hr/>

* Connection #0 to host openhab left intact
* Closing connection 0
hamish@thunderstruck Downloads %

I don’t suppose anyone has any ideas about this do they?

curl -v http://openhab:8080/vendor/styles.min.css

you’re missing the /habpanel/ part?

Well… Technically I’m not… I could argue that it’s habpanel that is missing it in the URL’s it refers to…

e.g. From the /habpanel doc

    <link rel="icon" type="image/png" href="assets/manifest/logo36.png">
    <link rel="apple-touch-icon" type="image/png" href="assets/manifest/apple-icon.png">
    <link rel="apple-touch-startup-image" href="assets/manifest/logo340.png">
    <link rel="stylesheet" href="vendor/styles.min.css" />
    <link rel="stylesheet" ng-href="assets/styles/themes/{{settings.theme || 'default'}}.css" />
    <link rel="stylesheet" ng-if="settings.additional_stylesheet_url" ng-href="{{settings.additional_stylesheet_url}}" />
    <link rel="manifest" href="manifest.json" />


Make sure you’re using the correct full URL i.e. http://ip:8080/habpanel/index.html and not http://ip:8080/habpanel or similar.

I don’t believe it… It fails with http://openhab:8080/habpanel when the returned page (Which is index.html) fails to load the rest of the content… What a simple work-around. (And one I never considered).

is this a bug somewhere that’ll be fixed?

** Well… Almost works… In that the page comes up but for some reason the ‘edit’ icon never appears when hovering over the title any more… And neither does the settings icon at the bottom of the panel list.
But at least I’m closer to it working again.