Private github repos are still readable by github.com employees. You know, Microsoft. So yes, good that it’s not a public repo, but realize you’re still trusting outside your zone of control.
Other git based repos are avaliable. I quite like BitBucket myself
You can have a local git server also, some people use git on synology NAS for example.
I’ve asked twice now in this thread (three if you count this time) but I still haven’t had anyone who promotes the idea of “UI only integrations” explain how someone is supposed to “officially” fix a failed integration that was configured via the UI if the UI doesn’t load.
I have yet to have an integration that a configuration issue caused the UI not to load.
The user in question in that thread had a custom component who’s dependency failed to load, not sure why THAT caused their UI not to load but since it’s not an official component/integration who knows.
Maybe you haven’t but I did. And it took several hours of troubleshooting to get everything working again. If I was a “non-tech savvy” user I wouldn’t have been able to even come close to being able to recover from it.
And how common it is isn’t really even the point. It can happen.
But even if the cause is something else (custom component or not), if the error logs say that the error is caused by a certain integration then the logical first step of any troubleshooting procedure has to be removing that integration. Otherwise the error logs are completely superfluous.
And if you can’t remove that component (custom or not) then you are still in the same boat in the end.
There has to be some official way to recover from a failed integration/component configured via the UI that is just as “easy” as simply removing the configuration from your yaml files.
Not to mention that a number of custom components are moving over to the ui set up, so we’re still in the same boat. I’d like to think that this means an ‘official way to fix’ is on its way, but I suspect in the long run they’ll just remove the ability to add custom components.
What is amazing is how Home complicated Home Assistant is. It has over 1500 integrations, lots of custom components, and many systems that it will run on. The more you use it the more you find out what you don’t know. I appreciate all the effort that the developers are doing. Making it easier for development is a good thing. It is a long way from being easy for non technical users.
Your “more” example is another user using a custom component. Those components aren’t supported by the HA devs or the core system so their behaviour can’t be guaranteed. All of your examples so far have been people doing unsupported things and then having stuff break.
Can you find an example where someone wasn’t using a custom component?
There’s no indication that user wasn’t using a custom component nor does the user indicate which component they were using. It’s hard to say whether or not it was a supported integration.
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.