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.
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