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.
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â.
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.
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.
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.
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.
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.
Actually I quite prefer tech savvy users compared to noobs, I donât do phone support anymore for a reason 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.
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
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)
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.
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.
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.
but Iâll try my best to help people out as much as I can.
