And can’t type
wget -O - https://get.hacs.xyz | bash -
Or even copy & paste.
Yep, where should that be copied?
Clearly you can code now.
Can you weld titanium?
I see all the time really bad hardware hacks and diy stuff by coders but i would never start mocking them. I help them.
You feel special?
It is nice to be important but it is more important to be nice.
1 Like
Exactly where the bloody instructions say.
1 Like
Isn’t it time to lock these threads soon?
3 Likes
Just to add on what @petro wrote:
I was aware of the removal for GPIOs from core for a while, I waited until the last minute hoping someone who worked on it on the past or wants to be a code owner will take it.
I believe the decision to remove it from core is correct. I know it doesn’t make everyone happy, but Home Assistant core should not include integrations that has direct IO interaction which requires specific drivers.
If you have the knowledge to wire things directly to a PI it should be possible (even if not easy) to install an external integration. There is also a work in the background for a different solution which will not require a custom integration from HACS, if that will go I will link it here and on my repo.
There was a slight miss here that people also use it to control the internal fan, this might needed to be considered and maybe just this should be allowed as minimal requirement for the PI platform.
I don’t think anyone is really impacted here, there are 4 months until this removed from core and I believe everyone who needs it can move the custom integration. If you need help with installation feel free to ask me.
At the end nothing is done in order to make things worse, these things are with motivation to help making building of images easier and making releases more simple.
7 Likes
Hi, I would also like to express in this forum that I’m very disappointed with the deprecation of all the integrations that interface with GPIO directly.
As Home Assistant is an Open Source software we’re in no position to complain, this is a great application and I have to say that I have been very satisfied with it. The developers and the community have put together a great piece of software, and if you want you take it and if not you choose something else.
Nonetheless, Home Assistant is described as being powered by a worldwide community of tinkerers and DIY enthusiasts. If more and more DIY enthusiast join the community, Home Assistant will keep getting better. I’m afraid this decision can result in a lot of people leaving the Home Assistant project, and turn new users looking for a home automation away from this project because it doesn’t support any more these direct interfaces that were at the core of the solutions that many tinkerers like myself undertook. When I decided to base my home automation solution in Home Assistant an indispensable requirement was the support of GPIO.
I designed and ordered a PCB which interfaces with the Raspberry Pi that runs HASS OS, using 18 different GPIOs, one of them attached to a DHT sensor that provides temperature and humidity readings. In the release notes the use of other HW like ESP devices is recommended, others also suggest using two Raspberry Pis, etc. but they are surely not in any way the best technical solution for setups like mine, making it more complex, costly and less reliable. Many others are in a situation similar to mine, have Raspberry Pi HATS, etc.
Also mentioned in the release notes is the use of custom integrations. A developer has already shared one for GPIO and I am testing one also for the DHT sensor. The problem is that these custom integrations rely on imports from libraries that have to be present in the Home Assistant Operating System distributions (the one that I use). I would like to ask that at least all libraries and other SW dependencies are maintained so we can keep using these custom integrations.
Actually I would like to ask if it is possible to reconsider this decision. I’m sure there are many users that would appreciate that these integrations are kept; and a number of new users will also choose Home Assistant if GPIO is maintained. I don’t believe it’s a huge effort to maintain it, no new functionality is required, just need it to be maintained, it currently works well enough. And the support of the community was really good. Last year there were problems with binary sensors in Raspberry Pi 4, and the problem was resolved. The same with the DHT sensor integration. The GPIO community is very much alive.
But again, if this is not possible, I really hope that you maintain all the necessary requirements and dependencies (e.g. libraries) in the Core SW to keep the Custom Integrations for GPIO, DHT, etc. Otherwise this will not just be a deprecation resolved with custom integrations, it will mean the eventual death of direct GPIO use in Home Assistant, and that would be a shame for many tinkerers and electronics enthusiasts.
In any case, thanks to the developers and the community for all the work that has already been put into this great project!!
3 Likes
Actual DYers and tinkerer’s don’t care.
It will take them less time to fix the inconveniences that it took you to write your post.
No. Custom integrations will import the required libraries.
ESP is surely less complex and more cost effective for sensors than any RPi with whatever hat.
Nobody in its right mind will use HA just because it supports the RPI GPIO, which it will still do, btw, just not out of the box.
It’s the kind of spurious argument that will convince noone.
Dead or alive, you have to make up your mind 
If it’s alive, the switch to a custom component will be a breeze with a vibrant community to support it.
I think all integrations should be moved to HACS or something similar
Having 2 systems to install integrations is not easy for beginners
OK what would it take to keep One wire and gpio from being deprecated? can I help, possibly with others? For me raspberry pi gpio is fundamental in a home automation setup.
Only one as far as I know of, custom_components (which is easiest via HACS, but HACS is an unnecessary convenience)
Decoupling integration updates from core updates is a great idea.
4 Likes
Dude… HACS literally transforms HA. Without it you are missing out on so many great features. Time to have another crack at getting it installed.
1 Like
Dependencies (ie all the pypi packages that each integration pulls in) would be hell.
That is exactly why I chose HA and I know many other doing the same.
Could you act a bit more politely. You and some others are shouting here and on the other thread at us like it was the way to talk here. I hope not.
4 Likes
I think its just going around in circles and nobody wins from it
The decision has been made and as i believe someone has already stated has only been reversed in the rarest of circumstances
Even something that had a far bigger impact (no YAML based integrations anymore) has never been reversed
The best outcome for yourself and others who have the deprecated integration is to work with the generous dev who has decided to take it on as a custom integration so that it can continue.
I cant see any other scenario in this instance
2 Likes
You have a point, but packages used by multiple integrations are few, afaik.
Now, there might be an issue with dependencies of dependencies…
There is a bloody big list 
https://github.com/home-assistant/core/blob/f170aba0cc0a0d626a00db213574f683e39c6fe9/requirements_all.txt
Yeah, but the only potential tricky ones are the ones having multiple “comments” ie multiple integrations using them
I don’t use GPIO. I think the elephant in the room here isn’t the removal of it in so much it is a communication failure.
This isn’t the first time the HA devs have failed hard in this category. They were completely out of touch with Supervised installations and probably more so with ZWave (what colossal train wreck that was for a few days….)
In all three of these cases the reason the situation blew up is complete lack of communication. These are massive decisions that should not be made in the dark corners of a dev forum. These are the types of decisions that should have blog posts to solicit input….kind like the FCC does
You don’t have to listen to the feedback…. It at least you could get out ahead of the train and have a plan. In the case of this GPIO fiasco all it would have taken is having a plan to replace it and linking the plan in the release notes. Instead it’s just dumped on the community with what comes across as a big middle finger. The same issue happened with ZWave
If you want to streamline something, maybe focus on your communication quality and approach….as you grow it is going to become more important to keep things smooth.
(I agree GPIO support should not be core but just a regular integration btw)
Also 0.8% can be a large number of people. If you have a million installed users that is 8000 users….I would expect loud complaining from a group this big. You guys have to start realizing your product is large and that communication is key. I don’t feel like you completely get it. You are close……your release blog posts are really quite good….but these kinds of communications for functionality being removed you should probably pay a lot more attention to the approach.
10 Likes
Yeah imagine pya-1.3 is a requirement of partx, party and partz, all parts of core. If partx n suddenly needs pya-1.4, presumably the core code-owners can update party and partz so that all are compatible with pya-1.4.
Now imagine all the parts are in separate github repos. Not so easy.
Also party has been forked 3 times and has three different maintainers, all going in different versions.
I am not saying decoupling from core is bad idea, but there are fishooks.