Considering how poor the documentation is (no mention of host requirements) and how unreliable Pi GPIO sensors were (it may have been fixed: https://github.com/home-assistant/home-assistant/issues/10498 ) I’d be tempted to use this instead:
It’s a small python program you install on the host and control via MQTT.
I/O configuration is with a simple YAML file.
Anyone found what is the host requirements?
It appears to be a mystery.
Yep. I’m also curious about host requirements too. 
I actually got this working, you just need to get pigpiod running. On raspbian it is already installed for you and you just need to enable it for remote access. Use the ‘pigs’ command to verify its working. I’ve only used the binary_sensor so far.
Could you please edit the page to include the host requirements you used (link top right):
Added this:
Remote GPIO must be enabled on remote rPI, pigpio must be installed and pigpiod must be running.
This component has a problem with device update after HA starts. If for any reason pigpiod is restarted or started after HA starts, the device update isn’t done. You will have to restart HA for the host to be recognized again.
I’ve confirmed pigpiod is running and have restarted HA but still getting the same errors;
Error while setting up platform remote_rpi_gpio
Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/helpers/entity_platform.py”, line 126, in _async_setup_platform
SLOW_SETUP_MAX_WAIT)
File “/usr/local/lib/python3.7/asyncio/tasks.py”, line 416, in wait_for
return fut.result()
File “/usr/local/lib/python3.7/concurrent/futures/thread.py”, line 57, in run
result = self.fn(*self.args, **self.kwargs)
File “/usr/src/homeassistant/homeassistant/components/remote_rpi_gpio/switch.py”, line 40, in setup_platform
address, port, invert_logic)
File “/usr/src/homeassistant/homeassistant/components/remote_rpi_gpio/init.py”, line 24, in setup_output
from gpiozero import LED
File “/usr/local/lib/python3.7/site-packages/gpiozero/init.py”, line 22, in
from .devices import (
File “/usr/local/lib/python3.7/site-packages/gpiozero/devices.py”, line 486, in
Device.pin_factory = _default_pin_factory()
File “/usr/local/lib/python3.7/site-packages/gpiozero/devices.py”, line 453, in _default_pin_factory
raise BadPinFactory(‘Unable to load any default pin factory!’)
gpiozero.exc.BadPinFactory: Unable to load any default pin factory!
I’m running hass.io in docker on a Ubuntu 18.04 server, not on a RPi if that makes a difference.
Did you try a pigs command, like ‘pigs t’ ?
make pigpiod run at boot with ‘systemctl enable pigpiod’
look at /lib/systemd/system/pigpiod.service, does it have a line like ‘ExecStart=/usr/bin/pigpiod -l’ ?
If it does, the ’ -l ’ means to disable remote sockets, not good.
try removing the ’ -l ’ and explicitly put in the ip address of your hassio using this command;
ExecStart=/usr/bin/pigpiod -n ipaddress1 -n ipaddress2
of course ‘ipaddress’ is your hassio address.
Here is more information of how hassio is communicating with the remote pigpiod
https://gpiozero.readthedocs.io/en/stable/remote_gpio.html
Finally, there may be an issue with pigpiod wanting to use ipv6 instead of ipv4, that is where using the
‘pigpiod -n ipaddress’ thing comes in.
Good luck!
Thank you for the link to the docs. I found out that I have to manually install and start pigpiod if I’m running Raspbian Lite.
Here is a thread that helped me with my setup;
Thanks @gumby2, the ‘pigs t’ command works and pigpiod is definitely running, I’ve changed the ExecStart command to include my hassio IP as above but still getting the same error in my hassio logs.
It seems that my hassio instance is unable to load any default pin factory to communicate with pigpio on the remote RPi, so still searching for a solution.
I think it has something to do with the GPIOZERO_PIN_FACTORY environment variable. I wrote a quick test script on a Windows machine (not running Hassio) and was seeing the same error there until I set GPIOZERO_PIN_FACTORY=pigpio
I worked around this by using the following node-red node:
I understand this may not be an option if you don’t currently use Node-Red.
It’s a shame though, because I would have much more control over things leveraging the Hassio remote_rpi_gpio integration.
Just installed a brand new hassio instance on an RPi3B+ and the switch component works perfectly, still unsure if the issue I’m having with my Ubuntu/Docker instance is being caused by a pin factory mismatch or if the new component doesn’t work on an upgraded system.
Very odd… Glad you got it working somehow. Now we’ve just gotta get it working on docker.
Can you run printenv on that RPi3 to see if it has that ENV var?
I’ve enabled remote access on my host RP, and still getting an error. I’m running 0.94.3 on a RP3 B+. I tested and successfully connected to the host via SSH and RDP using TightVNC that confirmed Host remote connection is OK.
I created a test pyton program and confirmed that my gpio pins are responding to my 8 channel relay and my HC-SR04 sensor & DS18B20 sensor. I can trigger the relays and get the distance or temp readings from my Sensors. Anything that I missed or did that should be revised ?
Hi @Mctalian no ENV var when I ran printenv on the RPi3B+, I’ve confirmed it’s an issue with the Ubuntu/Docker setup as I did a fresh install of 0.94.3 the same as on the working RPi3B+ and still get the same error about the pin factory.
I was getting this error if the remote RPi was started after my Hassio RPi, if you make any changes or restart the remote RPi you have to restart HA for it to reconnect, hope that helps.
