2025.5: Two Million Strong and Getting Better

Mariusthvdb · May 12, 2025, 12:40pm

Tried to get Better, didnt work out. tried to restore this mornings backup:

complete /config folder got wiped… while in the Dashboard, an eery experience.

managed to get to the system menu items (my own yaml config is gone) and trying to restore once again, but this remains in view…
o dear

can we somehow check if this is actually active, or hanging?

I can still ssh in but ha core logs ends with:

  File "<frozen os>", line 227, in makedirs
FileNotFoundError: [Errno 2] No such file or directory: '/config/.storage'
2025-05-12 14:38:03.188 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved (None)
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/storage.py", line 520, in _async_callback_final_write
    await self._async_handle_write_data()
  File "/usr/src/homeassistant/homeassistant/helpers/storage.py", line 540, in _async_handle_write_data
    await self._async_write_data(self.path, data)
  File "/usr/src/homeassistant/homeassistant/helpers/storage.py", line 545, in _async_write_data
    await self.hass.async_add_executor_job(self._write_data, self.path, data)
  File "/usr/local/lib/python3.13/concurrent/futures/thread.py", line 59, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/src/homeassistant/homeassistant/helpers/storage.py", line 549, in _write_data
    os.makedirs(os.path.dirname(path), exist_ok=True)
    ~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen os>", line 227, in makedirs

I managed to pull of a ha core start in the Terminal, and got a working Frontend. However, still non files in the /config ???:

and whopper, gone is the Dashboard again.
I am completely lost what to do

update
was able somehow to restart via the Terminal (HA interface wouldnt let me because of ‘no configuration.yaml’ that meanwhile had been set back manually…)

Ive immediately unencrypted local backups, as it was impossible to backup via the Backup integration, and that at least gives me the files so I can manually restore if this is to happen once again.
Completely clueless (obviously…) yet as to what happened. (supposing at least it did not have to do with todays ESPHome update )

remarkable is that all of the device/entities/integrations were there, while the complete .storage was erased.

Protoncek · May 12, 2025, 3:07pm

Same happened to me yesterday when i reverted to restore my previous esphome names. Complet machine reboot helped - not only HA restart, but underlying os (HAOS…). That’s good thing of proxmox - you can alwaýs reboot VM…

Mariusthvdb · May 13, 2025, 9:51am

In hindsight, my guess is the system did not prevent manipulating the commandline in a Terminal session over SSH while a backup was being restored. Could that be it?

I had a frontend twice after a restart in ssh, (under the impression the backup process was not active anymore), but saw that Frontend slither away from under my hands while at that…

Not sure if this has anything to do with the changes in 2025.5? The system should not allow that to happen at all. No matter what.

HouseOfCards · May 14, 2025, 6:11pm

Same type of various bugs in themes for me. It seems this is the first step at moving us away from custom themes altogether. I also had all the top row tabs on my dashboard in CAPITALS, and the upgrade renamed them all to Capitals. So I have to rename a hundred or so…

Maybe a developer could share the long term view of theming upfront, rather than what I expect will be a slow stream of steady breaking changes of the coming release.

petro · May 14, 2025, 6:19pm

The old framework that HA used for the UI is no longer being made (the upstream library closed shop), so a new framework was found and everything is migrating over. The change was not related to theming, just related to the framework. Some things like this were bound to be missed.

HouseOfCards · May 15, 2025, 12:25am

I notice also that at some point, you can no longer select a theme in a markdown card, for example. You can put it manually in the YAML editor, but the visual editor says that “theme is not supported in the visual editor”.

I nuked my themes altogether. The exception is…

  ha-card-background: "#F0D69B"
    # Card Backgrounds

  primary-text-color: '#000000'
    # Card Text

I have a theme which I use for markdown cards I want to use as a highlighter of sorts. If I can set a color in cards natively I wouldn’t even need this anymore.

stevemann · May 15, 2025, 4:15am

It took me a while for me to figure out what the fuss was about because I wasn’t seeing the “renaming” effect. Maybe because I use the name: component in all of my cards and configurations. So, I don’t see the issue.

Nick4 · May 15, 2025, 7:29am

Hi, did you see this: https://youtu.be/kfu_3Fm0wDw?t=4242

Cadster · May 15, 2025, 8:20am

Nick4 is refering to this months releaseparty.

pove · May 15, 2025, 8:54am

I saw it, and there is no reference to the changes in ESPHome devices names.

klogg · May 15, 2025, 10:43am

Surely this is the biggest ‘crime’ of all?

I am yet to upgrade. I have plenty of ESPHome devices but because I am someone-who-knows-just-about-enough-ESPHome-to-get-by-and-at-the-moment-is-happy-with-that, and the fact that the changes don’t seem to be documented anywhere, I am at a loss to know exactly what will happen when I upgrade or what the remedy will be.

Just when you thought they were learning something (backups, providing an option to ‘opt-out’ of hiding entity_IDs in the picker) they go and do this

I have no need for Nabu Casa; I use Tailscale for external access and have my own Google api for TTS, but I used to subscribe just to support the project. I stopped when I began to feel a lack of appreciation for the ‘users’ which culminated with the radio silence after the discovered security breach a year or two back.

Things definitely seem to be improving on the ‘appreciation’ side and do I keep edging towards re-subscribing.

But then these things happen and it puts me off.

Just saying…

EDIT: Ok, so I now see someone (petro, who else?) has provided a guide to deal with this.
EDIT2: So having now read that thread it looks like it isn’t an actual solution?

tom_l · May 15, 2025, 11:07am

Yeah except we shouldn’t need workarounds like that.

petro · May 15, 2025, 11:32am

It can be permanent if you keep the file. Apparently deleting the file reverts the name. I’m not 100% sure that is the case though. I did this a number of years ago (to keep an organized list of entity names), and those names made their way into the entity registry. So it doesn’t make sense to me that it’s not happening for other people. I’ll test it at some point.

Protoncek · May 15, 2025, 11:44am

Correct. It’s a patch, not a solution. Extremely useful and welcomed, though.

I’m not 100% sure, too, but yesterday i corrected one of my esp’s and experienced this:

i corrected - changed all necesarry in esphome. Then i removed appropriate lines from customize.yaml and reloaded customizations. Then i programmed my esp module. After programming id’s of entities remained the same, (names too, but they were changed in a way that they remained the same anyway).
when i removed esp node an re-added it in HA id’s of entities changed (which is fine, since i corrected my yaml for that module). It’s kinda logical, though - since i deleted my device when re-adding it HA thinks of those entities as new…

Strange part however is that even enities were renamed (in my case from “sensor.uptime_5” to “sensor.biodom_update”) history of this entity wasn’t deleted…

So, i guess best option is to keep all modifications to be sure that names remain as they are.

Ildar_Gabdullin · May 15, 2025, 12:04pm

Away from PC, have not installed 2025.5 yet (although used it while working with PRs in devcontainer on April, but tested only frontend stuff).
So, is this “friendly names for ESP” the main issue with 2025.5? (IMHO paper- and mdc-tab-related things are related to custom stuff and solvable).
I saw a method from Petro based on “customize” (if I am not mistaken, just had a quick look). But - I do recall some recent complains like “names defined in customize are ignored in more-info”. So, what is a possible future of customize?

arturpragacz · May 15, 2025, 4:11pm

customize is a legacy feature. While there is no intention (that I’m aware of) to get rid of it at this point, it is no longer developed and is provided only “as is”. New features often do not take it into account.

It can be permanent if you keep the file. Apparently deleting the file reverts the name. I’m not 100% sure that is the case though. I did this a number of years ago (to keep an organized list of entity names), and those names made their way into the entity registry. So it doesn’t make sense to me that it’s not happening for other people. I’ll test it at some point.

That is very unlikely to happen. customize is a hack that only affects the state machine, it generally does not interact with the entity registry. Maybe some weird interaction made it happen for you at some point, but I would not recommend using it to people at this moment, unless absolutely necessary.

The only supported way to change the name of an entity is through the UI.

petro · May 15, 2025, 4:21pm

Customize.yaml is still officially supported and customizing the friendly_name (among other attributes) is still officially supported.

As for how my customize.yaml names made their way into the entity registry, I can’t answer that. My configuration was started in late 2015, I removed customize.yaml April last year. So there’s ~9 years of changes to the system that could have caused the friendly_names to propagate into the entity registry. All I can say is that I did not manually change the names.

Protoncek · May 15, 2025, 4:22pm

Ok, but… in this case: you’re welcome to rename near 1000 names one-by-one via UI for me…

arturpragacz · May 15, 2025, 5:03pm

The support for it is slowly getting removed though. It already does not work in more-info dialog for example.

Ildar_Gabdullin · May 15, 2025, 10:45pm

I read the explanation from Paul in that ticket. Perhaps there is some logic here. But it does make “customize” to be ignored. Seems that “customize” is left for yaml-made entities only (at least for those which do not have unique ids).