I'm unhappy with the removal of GPIO

Agree with everything you said. Citing usage stats as the first reason to remove an integration is frankly scary. It punishes those who don’t share which really goes against the main principle of HA. I completely understand the logic behind it but in this particular community it doesn’t work given the encouragement to stay local.

That being said, GPIO is also not my fight. Also, why isn’t a Pi powerful enough for you? I’m currently running on one and curious if I can expect to reach a point it won’t be enough power for me.

1 Like

You can find out if there is.
I’m not going to.

This is the thing.
“The GPIO” people keep referring to the blog post from last week about decade of service, yet on the other hand they don’t expect anyone to service them.
Which one is it going to be?

Where was this the first reason?

Perhaps there is more cleanup in the pipes?
If the “new motto” is to make sure integrations work then that could mean HA and Nabu casa is aiming for every integration must have a developer (?).
This is perhaps step 1 of 10.
Who knows?

But right now, this is the current situation.
Alternatives are already in place, four months in advance.

The Broadlink yaml configuration was also deleted this release.
Probably because it was “due” anyway but also because there is no support/maintainer (I guess).

1 Like

In that other thread which broke the news, I think I asked where the instructions for doing that were.

IIRC, there weren’t any. I think I now have the right files, but I’m still not really sure. I shudder to think what someone with less experience would have to go through. Sometimes we forget that not everyone has the same background and experience level we do.

If it were so easy, wouldn’t it have made sense to document a step-by-step procedure to implement the alternative? Instead a LOT of effort has been put into challenging anyone who posts their concerns.

3 Likes

Just wait a couple of weeks and it will be in HACS. If you figured out how to use the GPIO, HACS should be a walk in the park. Tha HA team is small, they can’t do everything, and they have to be able to draw the line somewhere. Yes I know it sucks to be on the receiving end.

3 Likes

It’s more that I haven’t yet got time to create another machine with the new version to be able to report those bugs in 2022.2. Since it’s not usable anymore, I need to install it somewhere else to test.

It’s the same process for any integration… this process has been documented and hasn’t changed since the inception of home assistant. If you want to know the correct files, use the link on the integration page that directs you to the files for said integration.

copy the files in that folder into config\custom_components\rpi_gpio…

add

  "version": "1.0",

at line 2 in manifest.json.

There’s your 2 3 step guide.

5 Likes

But you should be honest and tell, that they still have to add version in manifest. So at least 3 steps. :wink:

1 Like

forgot about that bit. Regardless, it’s REALLY easy.

First reason listed here… https://github.com/home-assistant/architecture/blob/780ea1b180263fce7b08805c019dd580f3db6fe2/adr/0019-GPIO.md

I’m not here to argue with you. Just curious the direction of the project. I hope the goal isn’t to have a developer actively support every integration because that would result in much fewer integrations. Generally open source projects are reactive which tends to work in an environment where people are volunteering their time. In projects such as these the expectation should really be that nothing is actively maintained as this awesome project is only possible through the good people who donate their time.

My preference would be to have the project operate like other open source projects where people fix issues when they come up, if they are willing and able. Having every piece actively worked on isn’t a sustainable model. That’s just my opinion though, others are obviously welcome to theirs.

3 Likes

The rpi.gpio is now able to be added as a custom component in HACS. An example is here. Maybe the one Petro is referring to above.

Just pre-emptively added it to my Pi4 via HACS, went in fine.

5 Likes

it is, I just didn’t want to say the dev’s name until he actually did the work. The cats out of the bag now.

2 Likes

I assume it definitely is, as for any open-source project, really.
Unmaintained code is dead code that can blow unto your face at any moment…

Sure, but you still have one/many maintainers who is the gatekeepers.
Having (tried) to contribute to the project, I’m telling you having those kind of integrations as custom ones in a less busy and less restrictive repo is actually a blessing.

  • No more synchronizations with the main HA: Fixes can be push anytime, and you are not forced to upgrade HA to get them
  • (Hopefully) more reactive issues / PR: No more PR’s or issues just ignored
  • No more restrictive rules: Yes, you can have YAML and not be opposed some ADR

Those are some of advantages of having non-monolithic software.

I already mentioned that this was the inevitable way forward for HA. I just assumed the devs had a grand plan to do this in a neat way, but that doesn’t seem to be the case, so just assume more and more integration will follow that route at a semi-random pace.

3 Likes

omg this is horrible…

I hope there will be a straightforward solution for this. I am using the GPIO as High/Low Inputs…
Will this be possible to use with that GPIO2MQTT solution? Or better that HACS solution?

agree here.

Reading the breaking changes, I felt not good.

We do not forbid the use of GPIO, but we are merely deprecating and removing built-in integrations, providing GPIO functionality from Core. We welcome custom integrations (existing or new ones) to provide alternatives. However, for most cases we recommend on using dedicated hardware, like an ESP device, instead.

That sounds like this:
you can build something to suite your needs, but on the long run - just buy more hardware and use that ESP thing - which obviously won’t work, when there is no wifi.

wired network and wired GPIO entities are just more reliable.

2 Likes

On a different thread it was posted about using flyte/mqtt-io (https://github.com/flyte/mqtt-io) to directly link GPIO to HA via MQTT. But yeah I do agree with people having another link over a network might make a weakpoint that isn’t really needed.

I started on a pi and for the first year or so it was ok. But as I added more and more devices I kept suffering sd card failures at an accelerating rate. I tried cutting down on the logging of entities, using industrial cards, different databases. Short of moving the database off the SD card… it just was too much. Then I started adding stuff such as high res live streams of my security cameras on top of everything else. The poor pi didn’t stand a chance. I moved everything over to a VM on a NAS with an Intel CPU, 12GB of ram, and nas hard disks. The difference is night and day. Best of all if I need to recover from a catastrophic failure I can vpn into my home network from anywhere and fix it as long as the nas is still functioning. Ironically the only failures I’ve ever suffered was an update to the NAS that caused it to reboot unexpectedly. The supervisor failed to restart when the VM booted. And a second when a power outage lasted sufficiently long and the power draw on the ups was higher than expected causing a dirty shutdown. Again the supervisor did not like that.

And this leads me to another point I hope the dev’s take into consideration. I’ve been building out this system since 2018 now. My house has come to run on it. It NEEDS to work 100% of the time or at least be easily recoverable. As in minutes from noticing a failure or from when the wife sends me a text message it needs to be back online. The WAF demands it. This system now touches just about every function of the house. HVAC, DHW, Ethernet, security, lighting, AV, solar production, even the f*ing aquarium is controlled by it. And the list goes on. This is no longer just a novelty, it is a production system by every measure. And it is about the only solution on the market capable of doing it despite it being technically in beta still. Version 1.0 anyone?
And really all of it is transparent to anyone who doesn’t know it’s there. You really would never know it is there doing it’s thing. And that’s the idea. Don’t get me wrong most systems continue to function just fine with out it.

I know I’m not the only one using it in such an extensive way. So making breaking changes… Tread lightly.

For a good example of a dependency, I do not even have physical switches for my security flood lights anymore. I removed them to solve the issue of the wife, a 4yr old, and guests touching the wrong switch whenever they turned off the nook light, a set of switches right next to the downstairs powder room. The cable to the lights is only 14-2 nm-b, a smart switch was not an option when the motion sensor wired to it has to be always on.

4 Likes

Disappointing. I just got everything working perfectly and now its deprecated. I should have opted into the stats I guess.

If you really got everything working perfectly why do you update at all?
Freeze that system as your production and check out the newer versions and features on a dedicated test-system until you feel safe to upgrade your production environment.

1 Like

What? That is what is happening.

Awesome! Is there a link? Hope there will be some migration guide for us, ( the 0.8% ) on how to migrate

Why do you need a guide? Just install it, change nothing and it’ll work.

EDIT: To clarify, its an exact copy of the built in integration. The custom integration will just start using your existing config on restart after you install it.

1 Like