I originally started my time with HA using hassio. After a while I realized hassio had some restricts that precluded me from doing everything I needed to do on my controller to get the system I desired. I moved over to a Debian supervised install and ran that for years on an odroid N2+.
Last week I did an update on my system and the HA containers would no longer start. Since the supervised install has been dropped, I figured I’d spend some time trying to get my stuff going on Home Assistant OS. Based on forum post It seems access to the gpio pins hasn’t seen much love in HA OS. On my supervised install I had libgpiod installed which gave access to some bash commands to interface with the pins. I used the gpio pins to connect with alarm contact sensors that came with my house. I wrote a simply bash script that access the pins state via the command below and then posted the state to HA via MQTT:
From terminal access on HA OS I see gpiochip0 is exposed in the container. However, the gpioget and gpioset commands are not available.
I’ve seen some add-on that might work with a raspberry PI, but nothing for the odroid N2+. I was thinking I’d be able to do this in appdaemon as it has the ability to add addition OS level and python packages. The only issue, based on my reading the hardware isn’t exposed to the appdaemon container. If you have information that the pins can be access via appdaemon please let me know. Any other thoughts on how to access these pins without adding separate hardware, like and ESP device, please let me know.
Thanks for the suggestion. That one seems to be a remote GPIO implementation, where the gpio pins being used are on a separate Pi 5 and they use MQTT to send the events over to HA. In reality the implementation I had when using the supervised install was similar in concept. I had a script that ran at the OS level and then inject events into HA via MQTT. I’m going to see if a custom addon might be able to access the pins. I wish someone from the development team could weigh in and let me know if I’m wasting my time. They should be aware if there is a correct way to do an implementation. Anyway, I’m currently looking at building my first custom addon. There is a python package that might give access to the pins. We’ll see. All suggestions are welcomed. Thanks for the input.
I posted to the feature request page and was informed that the HA team decided they were not going to support GPIO pin access in HA OS via any manner. I asked if they might possibly reconsider this architecture decision, as I believe GPIO pins are essential in supporting smart house home security. I’ll post whatever response I receive.
Anecdotal evidence is that fewer and fewer people are running Home Assistant on a Raspberry Pi. No other host computer that I am aware of even have GPIO pins on the board.
I’ve utilized the odroid N2+ for years and it comes with GPIO pins. I believe it’s the best platform to build a robust smart house controller and it is supported by HA OS. My initial install was on a raspberry pi but I found it to be way to slow.
I believe the best smart home architecture start with a lower power primary controller as the brains of your system running HA and then a second server for resource heavy apps like frigate and voice processing. This separation ensure you have basic smart home features that can’t be knocked out by a secondary smart house feature. It also allows for a small battery back implantation for the master controller. As the master controller would also provide home security functionality, this ensures security features stays operational during a power outage.
I am disappointed that if I choose to use HA OS instead of the supervised install that I lose access to some nice hardware and software features/options. In reality it was this type of restriction that made me move over to the HA supervisor installation years ago. I would love to see HA OS move to distributed hardware model. One where I could install primary functionality on the master controller and then setup slave controllers that could run some of the ha addons.
I’m going to look at splitting my implementation across 3 devices now. One running HA OS providing HA GUI and smart house control. One providing the GPIO interface and smart networking that provides backup internet access via cellular. The last being a container server for frigate, voice processing and anything else. The first two will be on battery backup, the container serve will not.
It’s the features I documented here and here that I need to shuffle in order to move over to HA OS for the master controller. The slave controller will run a different Linux distribution for now.
Maybe someday HA will support a master/slave architecture where all devices are loaded with HA OS. The master controller would have the most restrictions. Then they could provide a little more flexibility on the slave controllers. Like supporting GPIO access on a slave controller.