No need, it is included in default config.
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.
Edit:
For reference, I created here an issue:
https://bugs.archlinux.org/task/78323
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.
1 Like
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.
The first one is the slightly older version and the second is my current installation.
Now I’ll update it one version at a time so I can pinpoint which version introduced the bug.
UPDATE: 2023.2 was still OK but after updating to 2023.3 the labels are gone!
Makes sense. The release article is titled “Dialogs!”.
Seems like some dialogs were not adapted so far. Do you have the option to test the newest pre-release? (2023.5.0b3)
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…
1 Like
I just noticed that some other labels are also missing:
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?
Thank you very much for testing! I agree -if it seems to be fixed in the nightly/pre version then we should just wait for now.
1 Like
Version 2023.5.0 was released today 
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.
I’ve been digging into the code again, this time just comparing the HTML between the working and not working labels versions. So turns out this element is missing altogether when the labels don’t show up:
<span id="label" class="mdc-floating-label mdc-floating-label--required mdc-floating-label--float-above"><!--?lit$239119405$-->Name</span>
And also the class directive for the input is different
mdc-text-field mdc-text-field--filled mdc-text-field--label-floating
^ when the labels show up
mdc-text-field mdc-text-field--no-label mdc-text-field--filled
^ labels don’t show up.
If I paste the missing stuff into the inspector of the one where it doesn’t work, the label does show up properly, so that indicates it’s just being formed wrong at some point.
Also, when the config flow is launched, it gets the flow config as json from the hass backend - that’s identical between the versions, so it looks like the frontend is just broken there for some reason.
Update: I seem to have found the js-function that creates the text fields, but I haven’t managed to figure out why it does that no-label variant on this installation.
More info:
I grabbed the arch linux package and put all the files in a local git repo → then rsync’d everything from the pip-package into it so I could see what the difference was. At quick glance, the difference is mainly that around 10 000 translation files are missing from the arch linux package! That might explain the situation.
1 Like
I figured it out! 
For whatever reason, the Arch Linux package is missing all the translation files! So once I rsynced in all the .json files from the pip-package, the labels appeared. Woohoo
I’ll see if I can figure out what needs to be changed in the PKGBUILD so that it’ll include the files in the future…
1 Like
You are awesome! :3
Thanks for the great work! -and thanks for updating the issue ticket
Now, we have to wait that the package maintainer react. Please let me know when you know how to modify the PKGBUILD
I think I found it. setup.py runs this after the same that the PKGBUILD does:
python3 -m script.translations develop --all
I’ll test it when I get a chance to.
1 Like
Yup, looks like that previous thing worked
I built a package of the 2023.5.1 version like before, just added
python -m script.translations develop --all
in the build() function of the PKGBUILD after cd home-assistant. So it updates the translation files before it does the python build. (I don’t know if that would make more sense to do in the prepare() function?) Then I installed the package on my other raspberry pi, and the labels do indeed show up There’s a bunch of dependency errors running that though, but that same thing should work with an older version just the same.
I’ll do one more test - the same build but without that translation update command, just to see if that’s indeed what causes the difference and not some other random occurrence.
Update: Yes, that was it The same package without that command doesn’t show the labels.
1 Like
The maintainer of the package just replied that the fix is now in the repo
Thanks again! I just updated my it and I can confirm that the issue is solved! I owe you something :3
1 Like