The future of YAML

Custom components are an essential adjunct to home assistant. Many users have one or more custom components. The whole HACS system encourages installation of custom components. HACS is developed by ludeeus who is a major contributor to HA core (59th largest number of commits to core github out of 1906 contributors).

thomasloven is the 9th highest contributor to home assistant frontend and the 9th highest to hacs/integration.

Custom components are risky, but are hardly a no no.

If this is an attempt to squeeze them out, it is a strange way of going about it.

1 Like

Hahahaha. I have seen one example of a user on this forum asking why his system started in the new safe mode. Every other time the frontend simply fails to start. It is far from “impossible”.

1 Like

No one is saying they are being squeezed out but you have to know that when you go the custom route your system becomes unsupportable. The dev’s first response to any issue will be “remove the custom components and try again” because they are totally untested and have no QA with HA.

This is typical of all software. Once you go custom your far more likely to have issues and far less likely to be supportable.

Granted, but if it is yaml configurable, it is simply a comment out. How do you comment out a ui configurable custom component?

3 Likes

Which is precisely what we’re saying.

WHAT IS THE OFFICIAL WAY TO REMOVE IT WHEN ONE CANNOT ACCESS THE FRONTEND?

4 Likes

Same as it’s always been? Remove/move the directory in custom_components.

How to do that?

The ssh addon is now considered to be only for ‘advanced’ users, it cannot be installed by default. The ‘target audience’ will not have any methods to do this.

Using the samba addon then.

Clearly if they’ve installed the custom component they have access to the file system in some way, shape or form.

How to install the samba addon? I can’t get in to the UI.

I installed hacs by drag and drop in the UI using [insert name of UI based file manager addon like vsc or cloud 9] so the only way I can remove it is through the UI but now I can’t see a UI.

Ok how’s a yaml config going to help them access the file system?

2 Likes

if it was that easy then it wouldn’t have taken me so long to fix my issue.

Actually if you read the post where I ask the question the first time I tell you that it was an error in HACS that the logs showed was the problem.

I believe that the logs might have been wrong in that case, tho, because when I finally did remove HACS from the .storage directory files my system still wouldn’t start. I don’t remember the details of every step I took to recover but eventually ended up destroying the old container and rebuilding (I use HA core in docker) and that didn’t fix it, then I renamed my old configuration.yaml so the system would create a new one and started adding back a few pieces at a time until it failed again. I’m not sure why but I had to do that a couple of times until the last component that it failed on was the standard Foscam camera integration. I removed it from yaml, restarted and then added it back in and everything has been fine since. I have no idea what the problem ultimately was. There was just a glitch somewhere that caused a corruption in something.

I had made no changes to HACS or the configuration.yaml, particularly not the camera integration, before the failure. I had restarted HA after a simple automation change (I think) and the system never came back.

If every integration was configured in the UI then 90% of the steps I took to recover would have been impossible.

And remember, I’m no rookie when it comes to HA. It’s not like I was just flailing around in the dark trying to fix things. I had a plan based on sound troubleshooting technique. And I still struggled for a few hours even with the vast majority of my config in yaml. If everything was done in the UI then I think I would have been done. If I ended up needing to re-install from scratch then it would have been a daunting task to have to re-add every single integration I use thru the ui again.

HA is designed to use custom components. Not only is it desired it’s actively encouraged. I would say that over 90% of the frontend components that people actually use in their systems are custom plugins.

And I’m also sure that a large part of users integrations are also custom integrations. I personally am using almost 30 custom components right now.

The official devs say that custom components aren’t supported but everyone knows that without them HA wouldn’t be where it is right now. And as such there ought to be an official way to fix things that break in your config even if those are custom components. And just because a component is built-in doesn’t mean it can’t get corrupted in some way as it did in my setup.

2 Likes

Because when people are editing their yaml files they already have a way to edit them remotely and are ‘capable’ tinkerers.

The problem here is that you want to cater for complete non-tech savvy users but have absolutely no idea how to support them when something breaks.

This is all without even mentioning that with no access to the ui such a user cannot even access the logs to see what failed, and therefore everyone is stumbling blind.

Furthermore, if a custom component can break the ui, so can an official component, so the argument ‘you’ll have to remove the offending custom component’ doesn’t wash.

4 Likes

Actually I quite prefer tech savvy users compared to noobs, I don’t do phone support anymore for a reason :stuck_out_tongue: but I’ll try my best to help people out as much as I can.

As I don’t use the “supervised” version, does a fubar HA config stop the supervisor from working too?

Granted but the first step is going to be remove the component. HACS is different as it’s fingers get really deep into the HA pie.

I’ve dip my toes into the .storage pool and the files aren’t overly complex, from what I understand of how it works tho, if the integration isn’t loaded/missing entries in the config_entries files are ignored.

1 Like

Supervisor would still be running, but again the problem is that the direction of the project is “everything to be configured in the ui” and nobody seems to be saying “OK, so what if the UI doesn’t load?”

Even though they thought the Titanic was unsinkable they still chucked a few lifeboats on it just in case :slightly_smiling_face:

I can tell you this, I will not do my automations via the UI, configuring integrations from the UI is fine in my eyes, less typos, formatting errors, and what not.

I guess that’s what ‘safe mode’ is for, but like I stated before, I have not seen an instance of the included integrations causing the UI not to load.

(The distinction is made for included integrations as the devs test those)

Did my example not count?

I said the original log entry pointed to HACS but I don’t think that was the real problem. It could have been but I have no way of verifying that. Like I said the last errors in the log pointed to my camera integration (or maybe I didn’t mention the logs…but it was there eventually). Simply removing it and re-adding it with a few restarts in between “fixed” things.

So the implication there being that the devs of the custom components don’t test those before they release them into the wild? I really doubt that’s case.

And it doesn’t matter if they are fully tested before release. They can still get corrupted later as in my (non?) case.

Of course the first step of any troubleshooting step (after looking in the logs) is to undo the last thing you did. So if a bad custom component gets thru and HA fails as soon as you do a restart after adding it then the obvious thing to do is to remove that custom component.

But again, you are missing the point.

If the component (custom or not) is added thru the UI and the UI doesn’t come up how does one fix it?

Just removing the HACS directory didn’t solve it. I kept getting errors about HACS after I removed it. Which is what led me needing to go into the .storage directory to edit those files to remove references to “hacs”.

And if a built-in component gets corrupted there is no (easy…) way to remove that components directory from within HA. At least all custom components are in a single easy (or at least easier…) to access directory.

1 Like

I’m implying there that they’re checking that the integration doesn’t halt the UI from loading. Note these are assumptions.

Not disregarding your issue, just stating that I personally haven’t seen an issue like that, nothing more.

Like I said HACS seems to have it’s fingers deeply into the HA pie, even tho it’s a custom component I think we can all agree it’s far from a normal component.

It’s really not hard for them to keep the yaml parsing in, from what I can tell, I can see for certain instances where it wouldn’t be workable ie: Ring, unless they’re planning to remove some of the “helper” functions available to components.

Until the rest if the configuration is is done solely thru the UI.

At that point every component, custom or not, becomes just as integrated into the “HA pie” as HACS has now become.

And add to that the recent removal of the users ability to manage their own entities even thru the UI (an example that I use that illustrates that is the built-in Unifi integration) or the removal of the “rename node” functionality from the zwave control panel a couple of years back (even tho that same ability is even now still available but buried deeply in the services tab), or etc… and then it just adds more fuel to the “I don’t want to be required to use the UI” fire.

I’ll grant those aren’t technically “future of yaml” issues, per se, but they do go to the broader issue of HA making decisions that impact the ability of the user to manage their own system in the way they want even to the point of arbitrarily removing functionality that could easily be retained aside from a decision of the dev team in order to (arguably) “Make It Easy™”.

Since I’m neither experienced with custom components, nor a supervised installation (I never did anything else but the simple venv-installation on raspbian): could/would your disaster-recovery haven been simplified / speeded up if you had made a backup / snapshot of your configuration prior to making bigger changes? I don’t know if there’s support for multiple snapshots where you can go back in time step by step. But if there is, I suppose that should have been the best solution. At least if this approach could have solved your issue. And if it does not, then that’s a feature that definitely has to be worked on.

I don’t use a Supervised install either. I use straight HA Core in Docker. So no snapshot’s available.

I make a backup of the config directory right before I update to the next version and then overwrite that backup every few days after a few successful modifications. Then I do the same for the next version. So I have backups of my config directory and the backup covers a few days worth of changes but I only have one backup of the config in the current version.

So I have one backup of every version going all the way back to when I first started using HA. :laughing:

But I hadn’t made a backup right before I made my “simple” config change (I honestly don’t remember what the change was but it was not related to any logs after the start up failure), did a successful config check and restarted before it all came undone.

Again, the issue is that the logs didn’t lead to the ultimate failure so I don’t know if it was a HA core file corruption, a custom component file corruption or a .storage file corruption that was the root cause.

And I really have no idea if it’s possible to restore just the .storage files from a previous version of HA without causing additional issues. I kind of tend to think it wouldn’t work.

1 Like