There will be no specific Yellow zigbee integration.
If you want to spread FUD, at least make up something vaguely believable…
That doesn’t mean they don’t have that power… This is semantics and pointless to even point out. I was pointing out what Members are, nothing I said was out of place.
2 Likes
How it is then done? Spreading nothing here, asking to understand.
1 Like
The Joe Rogan defense.
Yellow has a Silicon Labs chip, which both Zigbee2MQTT and ZHA already support.
If it needs specifics, it will be added to the existing integrations, which already support a ton of different chips.
Ok, but it has to talk to gpio… core integrations are not aloud to talk to gpio after 2022.6.
They are kicking out other zigbee/etc cards doing so.
So they give priority to that card, right?
Usb cards are different, they are not connected to gpio…
You’re making up stuff again. The RPI_GPIO integration is deprecated, amongst others, nothing more, nothing less.
I cannot even see a coherent sophism leading to that bogus deduction
1 Like
Please explain:
" Consequences
We will no longer accept integrations that integrate with devices over GPIO as a core integration; those will have to be maintained as custom integrations, or use projects like ESPHome instead. "
I believe it means the same as I said?
I am trying to understand the difference between these zigbee etc cards on gpio compared other stuff.
Your answer didn’t help much as i don’t even fully understand it ( English as 4th language ) other than the bogus part 
Edit: I can’t find it now but it looks like serial devices are still ok on gpio…so maybe Yellow/Amber zigbee is serial…
It has a “mother board”. I use the term mother board because I don’t know if this board has a name. But all devices are connected to this board.
IO doesn’t care if it is on a board or connector anyways it is called carrier board.
It uses serial UART so it is excluded. There is also I2C and other general io but I guess they won’t be using them.
Info was here: https://github.com/home-assistant/architecture/discussions/596#discussioncomment-2096853
This also means we could use serial relay boards and other boards still on gpio…not as easy to setup but possible.
1 Like
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)