I don’t know if this is the right place to report bugs in the debian package? I couldn’t find a specific section for bug reports, or for the debian version. Feel free to tell me to post elsewhere if this is wrong.
It would be great if this package was actually in debian then the standard bug-reporting processes for debian and ubuntu could be used. If you are looking for packaging help to get that done, it is my area of expertise and I’m happy to help out.
Issue of the topic:
As I was failing to get openhab on an rpi to work (networking problem, reported here), I thought I’d just try it on my laptop for now. There is no openhab in debian, but this project provides some debs. So I installed the latest stable version. And did sudo systemctl start openhab.service to start it.
The webinterface become available (yay!), and asks me to do setup.
However the setup wizard is not displaying properly and is very hard to read.
All the items which should be fills or icons are labels instead, often overwriting the text they are supposed to highlight/be a background for.
And when I get through to the main interface the problem remains. This is not entirely unusable if you already know the interface, but for a newbie it’s pretty-much fatal. I didn’t find any pother mentions of this so maybe there is something unusual happening on my system, or no-one else is using the debian packages?
Please post configurations (if applicable):
I haven’t really got any configurations yet, so assume defaults.
Also where do I find the source for the debian package? There don’t appear to be any sources at JFrog
And I found GitHub - openhab/openhab-distro: The binary distribution of openHAB
But didn’t find any debian packaging in there either. What is the process for building the debian packages?
The licence requires that the corresponding source is available somewhere.
I wanted to look at the packaging and the upstream source to see where all these missing icons might have got to.
I always found Debian a little weird, I use Mint Linux and apt installs and updates openHAB without problems. I ran Debian for several months and never could get the sound card to work. Wiped the drive, installed Mint and sound card worked out of the box.
First things first: it’s very common to add repos to apt instead of inserting the package to the OS. Pleasse be aware that openHAB has nothing to do with debian.
Second: it’s an apt package, it’s not debian. In fact, openHABian uses the identical package, there is really no difference. All users with an apt based system (i.e. all openHABian users) use exactly this package.
Third: As I’m using openHAB since many years on debian, I can assure that there is no debian-specific bug at all.
Are you aware that openHAB is meant to be a headless installation? That is, install openHAB on one computer, connect with another computer.
Which browser are you using? Chrome seems to be the best option, I’m using Firefox (there are known issues with the Firefox cache so keep that in mind), but Safari and Edge are also working flawless.
I’ll second @Udo_Hartmann’s question, what browser are you using?
There is nothing I can think of about the apt package that would cause OH to work enough to present a UI at all but fail to load icons and graphics. The icons and such are packaged up with the code that runs the UI itself. If you have the one you have both and there’s nothing that could have gone wrong in the installation itself that would leave you in this sort of situation. Something else must be going wrong.
The apt package serves up the deb packages and are used by openHABian which is the most common way for OH to be installed on Raspberry Pi OS which tracks with debian pretty closely. It also works on Ubuntu, and other debian based distros. So the packages are probably the most used way to install openHAB.
Yes. I realise this is a generic out-of-distro deb package. Hence the comment “There is no openhab in debian, but this project provides some debs”. ‘debian’ refers to both a packaging format and a distro.
OK. good to know the same package is used in openhabian, that does narrow down the problem set.
Whether the pages display correctly should be independent of whether the browser is running on the same machine or another, but I guess things could be configured differently for localhost and not-locahost.
I am using firefox-esr from debian stable: 115.7.0esr (Sorry - meant to put that in the original message)
I just tried from another machine (firefox-esr 115.4.0esr) and the icons appear. Interesting.
And if I try it in chrome (121.0.6167.85) locally then the icons appear too. So the issue appears to be restricted to firefox locally. Even in a private window with the extensions turned off (ublock origin and privacy badger) still no icons.
Can someone who understand modern web-ese explain where they should be coming from so I can try and work out what’s going on here? Why would icons be delivered to chrome but not firefox locally? and to both remotely? Presumably something to do with modern fancy DOMs and they are not just coming from an icon file? (I understand HTML and files, but not modern javascript and DOMs and openhab appears to be entirely the latter).
And I would still like to know where the source, packaging and machinery for making the openhab debs lives.
By all appearances, there is something wrong with that version of Firefox which makes it not work well with OH. There are other problems with Firefox and OH so it’s not really recommended to use it, at least until the fix for caching (FF does it different from the rest which breaks some things for OH) rolls out.
But the difference isn’t only local FF and remote FF. It’s also a difference between 115.7 and 115.4. In any case, we are not FF experts here so likely will be limited in how much we can help to diagnose the problem. Furthermore, you have to decide if it’s even worth fighting. If so, there might be something useful in the web console.
MainUI is built upon two levels worth of web UI frameworks. Nothing in any modern web based UI just comes from an icon file.
By all appearances, there is something wrong with that version of Firefox which makes it not work well with OH.
A reasonable theory, but I just updated to 115.7.0esr on the remote machine and it’s still showing the graphics. So version 115.7 apparently can work.
you have to decide if it’s even worth fighting.
It’s bad when things work in one browser but not another, and worth investigating IMHO (because ignoring this stuff tends towards a browser monopoly and that’s never a good thing). In practical terms it’s seriously broken on my normal computer and browser - I shouldn’t have to go use another machine or another browser to get a useable interface (now I can see what it’s supposed to look like it’s clear why I was having so much difficulty driving it). So yeah I have an incentive.
The console output from the two is identical. The network access is all in a different order so tricky to compare, but I’ve not spotted an actual difference yet.
Well, all I can do is wish you luck. I think it’s probably a tiny minority of users who run OH and the UI on the same machine. So if there are weird problems you are likely to first to encounter this one. Definitely file an issue with screen shots, captured logs, and all that but ultimately I don’t have a lot of hope that anyone is going to volunteer to spend a whole lot of effort on it. You might be on your own to diagnose and possibly even to fix. If the problem is in the underlying Vue or F7 frameworks, it might not even be something we can fix here.
I agree that few people habitually use the UI on the same machine as openhab is running, but all the install/setup instructions I read tell you to go to localhost:8080 to check that your install is working, so we do expect this to work.
I have never experienced such problems when developing openHAB, and for development I run openHAB locally on my Fedora system.
So it obviously fails to load icons, or it does not replace the icon names with the actual icons after loading the icons.
I can observe that behaviour that icon names are shown instead of icons sometimes when having really slow networking on my mobile phone and opening openHAB from there, but after a few seconds the icons are loaded and properly shown.
@wookey Can you please check the browser dev tool’s network tab?
There should be a request to http://localhost:8080/fonts/Framework7Icons-Regular..woff2 which loads the Framework7 icons used by the UI.
So yes that does look like the thing that holds the missing icons and it’s not being loaded when they don’t appear.
That delay you mention might be a clue, but it’s not resolving itself no matter how long I wait.
Is there a way to manually load that URL as a resource in the browser console? If I load it and the icons appear then that’s fairly conclusive, but leaves the question of why it’s not being requested in the first place.
The requestor is line 1 of app.3456231afb83cd720478.js, but unfortunately line 1 is 57000 chars long (hooray for minifiers). The text “Framework7Icons” does not appear in that .js (on the working browser) so I guess the URL/resource name is constructed somehow.
That delay is caused by slow network, i.e. the request takes some time to complete.
Your problem is really interesting as there seems to be no request at all.
Those are the material icons. Can you please check what happens when you go to “Help & About” and select the Android theme? I’d expect the icons to show up.
AFAIK, no, but I haven’t checked this.
For me the request initiator is a minified css (in my case app.d24da219273e08add1d3.css).
If you are loading from localhost there shouldn’t be a network delay though.
My understanding is that Material is actually a font, not a bunch of separate image files representing each icon. I can’t imagine one can be loaded with a URL like you could with separate files.
A little update on this issue. I re-installed my RPi4 openhabian, which got the networking going correctly this time. But interestingly, remote firefox access to this instance exhibits the same ‘icons missing’, and no request for any .woff2 files. So it’s not just a localhost issue. (firefox 115.7.0esr).
