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.
Yeah, OTOH it’s just another day in an heavily decoupled ecosystem like python or npm, nothing really specific to HA besides the huge number of dependencies.
Also to be considered is that an average user would actually use few integrations, so while a monolithic release must indeed manage dependencies for potentially everything at once, if only for tests, cherrypicked integrations are less likely to clash.
1 Like
What is your actual suggestion above a forewarning of 4 months that a functionality will be removed?
The answer of “ask the community” if 992000 out of one million doesn’t care is not a valid one.
That’s literally what happened with zwave. The community decided that zwave js was the way to go because of the issues in openzwave. It was brought up and discussed by the community right here on the forums. This right here shows how out of touch the community is with the decisions of HA. It also shows why doing these things are fruitless because people will still be mad. Believe me, HA has tried every method and the outcome is always the same: pitchforks.
3 Likes
Does this means a RPI is still able to boot with a PoE+ HAT in 2022.7?
How do you have that configured?
I did not configer anything.
The HAT is on RPI and it boots up.
I don’t reed any data from it.
It has no relation to this then
Thanx,
I was confused, because the PoE+ HAT is placed on top of the GPIO pins…
The deprecation only affects the use of GPIO pins inside home assistant. Even then, gpio is not forbidden. The integrations are just being moved from core. Anyone can take whatever integration it is, copy it to their custom_components folder and be up and running in under 5 minutes.
I understand now…
To me ‘GPIO is moving from core’ sounded like GPIO is no longer working until the HACS integration is starts.
So I was afraid that the RPI with PoE HAT was never to be able to boot again, as HA OS has to boot first before HACS is starting… But that’s not the case here. 
Thanx
Do you understand what the deprecation of GPIO means? What you pointed to here will still work after deprecation without having the integration.
it means it will stop working after 2022.6 if you don’t do something.
Wow, you really don’t understand this deprecation.
1 Like