Most probably, I was unclear. The main point was that you cannot be sure to still use a core component 1:1 in the release, where it is not part of core anymore, because one single line/design change/… in core in major or dot release can break every component to work.
E.g. you cannot use 2011.12.10 sonos integration as custom component in 2022.2.0, because core introduced other dependencies for media player, …
Don’t need to discuss this here, but I only wanted to point in the direction, that it is not correct if the user think, that it is always enough to copy it to custom_components to kepp this running (without changes).
The real reason behind the removal of rpi gpio might be Amber/Yellow:
" GPIO
The Raspberry Pi Compute Module 4 allows you to communicate with external components via GPIO pins. Most GPIO pins on Home Assistant Yellow are used for on-board features such as the Zigbee module, audio DAC and for the debug console. This is why we don’t include a Raspberry Pi-compatible 40-pin header - most of those pins are already used. Instead, there is a 10-pin header (labeled J11 in the image below) that exposes a serial port and I²C. This header is compatible with the first ten pins of the standard 40-pin header, which makes it compatible with accessories that only use those first ten pins.
That said, we don’t recommend using the GPIO pins with Home Assistant at all. Instead, we suggest using an external ESP-based microcontroller with ESPHome,. "
Might be good to edit those specs with info about the removals. I2c going out already in 2022/4
Ah… So this is the real reason? It’s commercial one? What is the percentage of users opted-in for such a zigbee controller? All I know from posts on the forum uses external solutions (USB sticks, gateways (incl flashed). Also what is percentage of HAs based on Yellow/Amber?
I have a personal preference, wherever possible, to use official software from the developer rather than software that has been customized by HA developers.
Just to be clear, its an authors decision to submit an integration to HA core as opposed to submitting an integration in HACS. Nobody is forcing them to do either one, its their choice.
With this attitude why would core ever want to accept any integration? This is the type of thinking we all need to stop doing, its these types of expectations that lead to developers getting tired and moving on. I have seen it before and its probably going to happen to someone reading this thread and the comments and expectations that lie in here.
Just keep in mind its an authors choice to choose to submit to HA core or HACS, nobody is forcing them to do anything.
Assuming people actually go online to do polls, then people will complain about not getting enough notice or that their social media of choice did not get the poll. This happens more often than you think as well.
To get into core, it must be accepted by core team. ussually it’s somehow connected to zeroconf etc. I can understand it as increasing HA value by extenting it’s built-in (implicitelly supported) features.
Look at Shelly for example. It had 3rd party integration, it had MQTT integration but still at some point the core integration has been added (in contrary to two other ones being from time to time broken, giving less flexibility than mqtt etc)
And still, till today it floods your integration screen with all recognized, not configured shelly devices in your network, even if you don’t want to use built-in shelly integration.
Now answer yourself: why they did it.
Not exactly. Core devs can fork any open source code (incl 3rd party integrations) and include them into core. Then can drop for various reasons.
I’m not saying this is what happens. Just saying that what you are saing is not the only possible option.
Not true. It’s accepted by home assistant members, which are a group of ~50 to ~60 really active home assistant contributors. And before this sparks some sort of conspiracy: Members have the ability to merge PRs, tag PRs, tag issues, etc.
How can someone be a ‘hardware guy’ and have zero coding background ? Digital hardware and coding are two faces of the same medal, they go hand in hand, one cannot exist without the other. If they have no coding background, maybe it’s time to learn. And this is not even about coding, it’s about copying some files…
Independently of what you think of the whole core vs custom part and the removal of gpio from core from an organizational pov and what that means for the future heading of HA (and I’m with the guys who think it should have been kept in core), the fix here is literally copying a couple of files to another folder. I mean seriously, these people can create hardware, design PCBs, whatever, but not copy a few files ? Huh.
