I think the title already describes my issue. The text labels are missing. I attached a screenshot for reference. I already switched the interface language to English but it doesn’t change anything. All other dialogs/pages are fine -it is just the MQTT related one. If I go to “settings”, and then select “add integration”, filter by “mqtt” and then start the configuration part, the labels are missing. To my understanding, this isn’t a third party extension.
This issue occurs with Firefox, Chrome, and the Android App.
Does anyone know how to fix this? (or at least could tell me the meaning of the fields -I can guess most but not all of them).
This is not possible in my case. The pull down menu is grey (i.e., disabled). I cannot select anything. I believe that this is the default behaviour. If I install a third party theme (e.g., “ui-lovelace-minimalist”), then the pull down menu is activated, and I also can select “default”. (I tried that but nothing changed)
I have a similar issue. I’m not sure if it’s all configuration dialogs or just some, but a lot of labels are missing. And it’s not just on the desktop either, it also happens in the companion app (Android). I think this started happening after the most recent update (I’m running hass on Arch Linux ARM and updated using pacman).
My themes-menu only says “Backend-selected” and is greyed out. Oh and by the way, my configuration.yaml doesn’t even contain a fronted-section! I guess I’ll try adding that…
Here’s an example of what happens when I try to configure something:
Yeah, I noticed. Any idea what could be causing this though?
I don’t have a clue where to start looking even, the only solution I have in mind is to try to update to the latest version again… But I gotta wait until the rest of the family sleeps first.
Thanks for sharing this. I also use Arch Linux (x86_64 -not ARM). In my case, I only saw that issue in the MQTT dialogs (but all -first setup, and configuring things afterwards). So far I don’t have a clue but I try to figure it out.
It didn’t occur all the time though. I guess maybe they changed to using some library that’s not included in arch by default?
I updated to the latest version last night - it didn’t solve the problem, and actually hass wouldn’t start until I manually installed ulid-transform. That leads me to think this could also be solved by installing a relevant python-package, just gotta figure out which one!
Hmm, I’ve been browsing the code on git and googling around regarding this, and based on what I’ve found, I wonder if this has something to do with Home Assistant switching from Polymer to Lit? I’m running the 2023.4 version and according to what I’ve found, the next version should be completely Polymer-free.
I also checked if there are any missing dependencies but could not find any. There should be at least a hint in the log files (e.g., journalctl -r). The issue with "ulid-transform’ is a known issue (FS#78224 : [home-assistant] Missing dependecny for ulid_transform). For that reason, the newest home assistant package isn’t yet in the stable repository (for x86_64).
I also did browse the code and searched but couldn’t find any clue or hint for this issue. So far, for me the text labels were always missing for the MQTT integration.
Polymer and Lit seem to be frontend related -so maybe yes (but as far as I can see I use already lit -so it is installed).
I also reinstalled the “home-assistant-frontend” package as I was hoping that it re-compiles again the string files but it didn’t change anything.
Maybe it helps if you upvote the issue which I linked above (or add comments/thoughts).
Yeah, I voted and commented. My setup is Arch Linux ARM though (it has completely separate repos), so there’s a chance they won’t consider it to be the same thing…
My thought about the whole polymer+lit thing was, that maybe those dialogs are made using polymer but since that’s being deprecated, maybe it just doesn’t work before it’s fully ported over to lit. Just a hunch!
Let’s keep investigating! I guess I could try some older hass versions (I still have them in pacman’s cache) to see at what point it stops working.
Ha! I installed version 2022.12 on my second Raspberry Pi and here are the results! It’s super slow to init because it’s running a crappy SD card, but I found this integration config that’s available immediately.
Yeah, it’s definitely not all dialogs, just specific ones.
I’ll see if I can install a pre-release → looks like the only way is to install it directly via pip, and that’s taking ages… I’ll keep you posted when it finishes, assuming I get it to run this way…
This is the configuration for an automation.
These are supposed to be named “Night vision on”, “Night vision off”, and so on. Seems like it’s probably related to the same thing…
Update: I got the pre-release running and it does indeed show all the labels right, at least in that Riemann-thing I screenshotted before. So let’s stay put and wait for the next release, I guess?
Of course it’s not in the arch linux repo yet, but I built it myself from the official PKGBUILD, just changing version & tag numbers. One might also want to add the python-ulid-transform dependency to the PKGBUILD while you’re at it - I forgot myself, but it doesn’t matter since I already installed it manually before… (oh, I guess I installed it directly using pip. There’s also a package for it in the AUR)
But! The labels are still missing Maybe it worked on the other raspberry pi because I installed it directly via PIP, as opposed to installing it via pacman on my main installation…
This also seems to have some new dependencies now (rust, webrtcvad)…
Update: I downgraded to 2023.4.2. Too many dependency problems to deal with right now.
Anyway, it seems that the problem is in the arch linux package and not actually home-assistant, so I guess I’ll report my findings there and we’ll see where we’ll go from there.
There’s a lot of unnecessary dependencies on the package too - yes, HASS uses the libraries, but because arch doesn’t have the exact version that HASS wants it will install the package in its’ own venv anyway, so it would make sense to remove the dependencies from the package. It’s a pretty big undertaking though, to go through all the deps and see what works that way and what doesn’t… Also pacman installation is much faster than the pip install that HASS does.
Maybe it worked on the other raspberry pi because I installed it directly via PIP, as opposed to installing it via pacman on my main installation…