I have just noticed that HA is planing to remove GPIO support:
Integrations I use a lot e.g. for the BMP280 and BME680 sensors will therefore stop working. I also just bought a MCP23017 I/O Expander board hoping I could use it as a replacement for the not so great Firmata integration.
Is perhaps someone already planning a custom integration as a replacement for this change? Is there something already in the pipeline?
What about MQTT IO ? Itās basically a gpio2mqtt and that should work perfectly fine with the HA MQTT integration.
That looks really promising. Thanks, I will definitely have a look a this.
Wow. First Iāve heard.
I use GPIO pins for monitoring my heating system.
It looks from the linked page that itās not GPIO support (platform: rpi_gpio) which is being removed, but that integrations using GPIO will no longer be accepted. Not sure exactly what this means though:
It will still be possible to have custom integrations that use GPIO.
I hope the devs keep us posted on this. Am I correct that the platform will remain?
No, this platform is now also deprecated:
Oh, wow. Iām heavily dependent on the GPIO platform.
What is the recommended alternative?
The MQTT IO project mentioned above also supports Raspberry Pi GPIO. I will move to it if no new custom integration appears to handle GPIO directly in HA.
Although I have read the reasons for the removal it is not really plausible to me. HA propagates local control and then removes one of the most local control mechanisms there is. And all other home automation platforms I have looked into support some kind of GPIO control.
I completely agree, but my opinion carries no weight. Is this the sort of thing for which a Feature Request should be entered? I wonder if it would get enough votes to sway any developer minds.
Quite a Christmas gift! I am not at all pleased to learn of this! One of the primary attractions of this system for me is discrete I/O that is very close to the core system in terms of time to respond, reliability, and with few points of failure and minimal software glue to keep updated etc. I am aware of the lagging support for GPIO with the 64 bit OS but I got the sense that these issues would be resolved soon and I am set to use the GPIO pins once I can access them.
For some I/O I wanted sub second times to output response. For others, I want zero additional power overhead until I turn on a particular output (to power something up for example). Think: idling on battery scanning critical inputs. Battery is getting low. Turn on glow plugs. Then crank generator. Watch AC frequency & voltage fuel level etc. Re-charge battery do housekeeping, messaging etc. How many microcontrollers do you want to depend on to make that process work? How many different devices do you want to connect to the same critical inputs so they can be monitored independent of each other? Are you sure there will be no interaction? What processes that reside on your core might you want occasional access to during power economization that arenāt practical by means other than the processing power of a PI? If it is a second PI - how are you going to power(up) that ethernet switch that connects them? No, I donāt/wonāt use Wi-Fi for critical functions. Then of course one of those PI will NOT be running HA because GPIO apparently isnāt too popular. So, adding that second PI didnāt do much except suck resources from the overall goal.
I say there needs to be a clear, supported path to access GPIO for discrete functions as well as interrupts, I2c and SPI capabilities of the core system in order to access things like 1-wire masters and the already mentioned IO expanders that is at least as accessible as perhaps zwave or Node-RED.
I too am a nobody. I have big visions and marginal coding ability but lots of experience with control systems and PLCs. I suspect that many using those functions are busy using them and not so much spending time advocating for their use. These functions are necessary at such a fundamental level for so many automation applications that I believe many take them for granted and use them quietly. They will not be happy to find such basic support dropped. If this must happen then the devs need to provide a road map that we can use to retain the capability that will cover most users.
I do appreciate the challenges the devs face down in every release and commend the progress they are making. What I do not want to see is a high speed train wreck (any speed wreck for that matter) because of a short sighted decision that hobbles Home Assistant going forward.
Q
If that is the case, then those functions will be gone. One voice (or even a few voices) crying into the wind wonāt be enough to justify a change in the overall project direction.
HA has expanded in lots of different directions. Thatās good. But it means the chore of maintenance also expands. I understand that all the fun is in coding new integrations and components. Thereās not much glory in keeping the boilers running down in the engine room.
If the whole gpio platform should be removed then I donāt understand how I should control the cooling fan Rpi which is mounted on the Rpi pins as a board.
I hope this turns out to be wrong but your assessment is reasonable. In principle though, one person taking the trouble to write about their concerns / displeasure / whatever over the announcement should be be understood to represent many more.
Another concern is the talk of eliminating Supervised installs from the āsupported listā. Both issues suggest a walled garden approach that gives lipservice to the more demanding implementations of HA but in reality is indifferent to the needs of some of itās users. While that group of users do not (or may not) have a tangible, measurable presence, It does not follow that they have no significant value to the overall effort.
I am not clear how the devs can know with any level of certainty how many are not sharing information with them. Even if they do (or think they do) know, there are many other points where this decision will impact the continued success of the platform. From my own experience which is common, I believe, anyone evaluating an automation system will not only look at what āretailā devices the system can be used with but just as important, how accessible and well supported ALL of the resources embedded in the core are as well as how well developed, āstandardā low level interfaces are supported. Along with the attitude of the devs. At the moment, it appears that āHouston, we have a problem.ā
I couldnāt agree more! For my part, achieving my goals/dreams in my automation system would be glory enough! Truly, if I had the wherewithall to help with this problem, I would. In order to get to that place I need to spend less time trying and more time doing. With no peers or mentors, the pace of progress for me has been glacial. I was beginning to have hope of improving that but nowā¦
Regards
Q
I did not read it all,but you can use ESP-Home with ESP32s that have Ethernet connection.
That will be a much better solution to most applications you have the GPIO support for in my opinion.
Each ESP-Node will be a own server so you can connect to it independent of the āmotherā (HA) to control it via an web interface and can easily and cheaply be replaced in minutes.
I believe if you just give it a chance then you will see that it has benefits.
I donāt know what the āofficialā reason is but if itās because ESP-Home can fill the space then I would agree with that reasoning.
Thanks for your comments @Hellis81.
The key word is āMOSTā! You can drive an aircraft carrier through there - at speed!
I use ESP Home and find lots of potential there - especially for remote sensing. I have several boards in service. And yes, there are boards that include ethernet - even POE. However they are not common or the default config for an ESP board. I havenāt checked if board configs exist for boards with ethernet or if ESP home has support for ethernet yet either.
Having said all that, the fact that 'the core" just became an RPI, an ESP32 board and an ethernet switch, hugely complicated the task of providing a rock solid core with maximum capability to respond dynamically and quickly to inputs - especially when power conservation measures and speed are needed.
Placing all GPIO out of reach of the core is never a good Idea. Inevitably, it opens the system to all sorts of failure modes that simply do not exist when GPIO is local. Lack of local GPIO precludes the possibility of assembling an economical system to handle some categories of task. At a minimum, it increases dramatically the difficulty of assuring a robust system that functions reliably in all (even most) circumstances.
You might argue āyou shouldnāt use your system for that anywayā. I will argue that you shouldnāt presume to decide for me! I am not trying to be nasty or snarky by putting it that way. Nor am I suggesting that is what you are saying. I welcome your (and others) advice and dialog but those operate at a different level. I have learned that removing someone elseās ability to choose because I think I know better eventually comes back to bite me. Regardless of my good intentions!
I hope the devs and the community can together find a solid, long term solution that will not be a drag in terms of maintainability for the devs which will preserve the core peripheral and GPIO access that I see as one of the keys to maintaining broad relevance for the platform.
Q
I wrote most because I felt I donāt know if everything supported by GPIO is supported in ESP-Home.
But i believe it is.
Probably there is more support to ESP than raspberry since Arduino based boards is generally more used for IO than raspberry boards are.
But donāt quote on that.
The other thing I can say is that I would ranter not place all eggs in one basket.
You find it great to have everything in one place, I find that less attractive.
One bad move and everything is lost.
With ESP based GPIO only that node is lost.
Even if HA is lost the ESP-Node will still function without HA.
And all the points you make about failure points and economically can be said the other way around.
Running HA on an old computer that is left over with a cheap ESP is cheaper than a raspberry.
Iām not really sure I understand your reason for posting here. You apparently arenāt impacted if GPIO support were removed. Thatās fine. Probably most people donāt care if ANY single integration or component is removed. And you donāt want to take the time to read the whole thread. So why jump in?
I have used ESPHome and I like it. It actually seems like the best alternative if GPIO pins on the RPi are no longer available. But itās a VERY poor substitute. Let me explain my use case:
The relays which connect to my RPi GPIO pins are right next to the RPi running HA. Itās a somewhat tight space, in a utility closet. To insert an ESP device, Iāll have to add another power supply and, since itās now a critical component, another UPS. Then ESPHome becomes a critical software component, subject to all the usual breaking changes and time-consuming updates. Iād be adding a number of new potential points of failure, both hardware and software.
The ESP would be near the RPi (where the relays are.) It would be communicating over my home WiFi network just to talk to the RPi right next to it.
It makes no sense to add all this hardware, software and infrastructure just to move the signals from the ESP GPIO pins to the RPi sitting right next to it, with the RPi GPIO pins going unused.
This seems contrary to the whole idea of HA. I envisioned HA as the core of my home automation/monitoring system, not a peripheral component which, in this example, isnāt really even needed. I might just as well load the web component on the ESP and monitor my system from there.
Youād think a system designed for a RPi would be more functional than something like ESPHome, not less.
Iām not affected of the removal, correct.
But I wanted to tell Quanta there is an alternative, but I didnāt know he already knew.
I have read the whole thread except Quantas first post that I answered to.
Too much drama and moaning, that is why I didnāt read the whole post.
I skimmed through but couldnāt see that he mentioned ESP-Home so I wanted to tell him about the option.
Iām glad I found this page, but then Iām not.
Up until yesterday I ran a previous version of HA Core and was happy with it and how it ran but there were a few unrelated HA system bugs and I decided on a fresh install and of course the upgrade to the new HA core. Much to my dismay though. My previous āworkingā system controls all of my heating, lighting etc with various one wire temperature sensors around the house, GPIO pins to control various relays etc. Iāve relied on my previous system for so long now, it used to be a case of backing up a copy of the configuration.yaml and a few other things and then integrate them back into the new system. I spent literally most of yesterday on this trying to figure out why the hell nothing works and the only entities showing up being those for one wire. The central heating had to turned on manually, with no thermostat control either.
If Iād have known beforehand that support for GPIO had been dropped then I wouldnāt have bothered with the upgrade. ESP-Home might seem like a viable option, if you have it. I personally prefer to have the least amount of devices that can go wrong as possible, and itās bad enough when you have devices such as wifi plus and lights that go down and need reconnecting again if thereās a wif glitch.
Has anyone got any ideas? Iāve loved using HA Core for many years now, would hate to have to look around for alternatives.
How many GPIOās are you using? I know itās not what you want but a single ESP32 could probably sort it all out for you, running ESPhome (which integrated very nicely with HA) plus you can get them with Ethernet so there is no worrying about wifi issues.
At the moment Iām only using 7 of them. One for the 1-wire sensors, I have 8 of those. 3 that control relays for switching on my CH boiler, oil radiator in the loft and CH hot air blower as well as 4 PIR sensors around the house. Unless I downgrade to a previous version of HA then mi Pi 4 is pretty useless, or just change to another platform such as openHAB or similar.