I'm unhappy with the removal of GPIO

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

2 Likes

Nah…

reptile

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 no idea if that is the real reason… just noted it could be.

It isn’t. And the description describes exactly where they went, and what was left over.

There are plenty of things you can install HA on which don’t have GPIO pins. Where do those fit into the conspiracy?

reptile_but

It’s not the real reason, @jkk is grasping at straws trying to make up a controversy.

FYI the percentage is 0. It hasn’t been released as far as I know.

I use the developer’s official zwavejs2mqtt

https://hub.docker.com/r/zwavejs/zwavejs2mqtt

along with the zwavejs integration.

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.

Sure, I pointed that earlier. I meant move the current integration out of core and not accepting new ones.

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.

1 Like

I still don’t get it…

We should not use gpio while Yellow/Amber uses it for Zigbee module, audio DAC and for the debug console.

They say it is bad practice while selling product with one of the main features relying on gpio.

1 Like

Stop making crap up. No one said it’s bad practice. You been given the reasons, multiple times.

I have been told now many times it should not be used anyway…

Why are you even here arguing with us and asking us to stop talking about it?

It thought this thread was made for us to talk about the issue. Let us talk please.

Btw, is Yellow zigbee integration going to be installed from HACS too?

1 Like

I’m here to point out everything false that you post, which is most things. Sorry that this is hampering your agenda.

2 Likes

If I remember right it was some sort of key I had to make or something.

As I said if it can’t be installed directly from home assistant and it isn’t just a copy paste then it looks like I’ll be building an esp circuit, just seems such a waste of resources for something that worked directly before.

Let’s not play the angelism card either :wink:
If they can, they don’t. I’ve only ever seen PR merged by the core team.
I’ve never seen a PR approved by a member going in if a core member objects, either.

1 Like