Thanks @cinquemic but that’s not the case, I’ve tried several different relay boards and 12V relay driver boards, all with the same result. I’ve also measured the GPIO pin output with a scope and it sits at 3.3V when off and pulls straight to 0V when switched on. As I’ve mentioned in previous comments the GPIO pins of the RPi running Hassio work perfectly but on a remote RPi they are inverted. I opened an issue on the HA GitHub so hoping it will be resolved soon.
How good is this remote binary sensor? I recently purchased a nodecmu, and a doorbell press only changes my sensor for max 2 secs… But the change in HA is instant, so that’s good…
Is this also instant when using remote gpio on a PI? I read in other threads , that’s based on scan interval training… So I can miss my doorbell hits…
Can anyone confirm this?? I was t to buy a PI, but I want to make sure the binary sensors changes are also instant
Thnx
hmm, i follow your guide, copy pasted that whole text, rebooted PI 3+ (debian lite)
restarted HA, confirmed id with that “pigs t” command but still this error :
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!
how can we resolve that ?
hmm, seems the error is documented here :
If you receive an error such as gpiozero.exc.BadPinFactory: Unable to load any default pin factory! try changing the pinfactory from pigpio to mock , this adresses a known issue.
but i have no idea how to change that to “mock” ?
Ok, hi everyone!
So, I’ve got a working workaround for the gpiozero.exc.BadPinFactory error.
Explanation:
According to the linked known issue, the ENV needs to be set before the script loading the pigpio library runs. This means that the docker container within HassOS either needs the ENV injected at runtime or it needs to be manually set before hass init within the container.
Because hass is the first (and only) thing that runs within the container, I edited the docker entrypoint script and added it there. This should work until a new release is pulled down.
Here’s what you need to do:
First, to do this you need to get root access to the HassOS system itself.
You can do this by setting up root SSH access to port 22222 according to this page, or you can plug a keyboard into your pi/whatever and login as root (no password should be required).
You should be at the hassos prompt. (Looks like hassio >)
Type login
You should now be at the host prompt.
You need to get access to the homeassistant docker container.
Type docker exec -ti homeassistant bash
You should now be within the homeassistant container itself.
Be careful here
Type vi /bin/entry.sh to open vi
It will look like this:
#!/bin/bash
set -e
udevd --daemon
udevadm trigger
if CMD="$(command -v "$1")"; then
shift
exec "$CMD" "$@"
else
echo "Command not found: $1"
exit 1
fi
Press the [INSERT] key to enter edit mode.
Make it look like this, add the line for the ENV variable:
#!/bin/bash
set -e
# add the line below
export GPIOZERO_PIN_FACTORY=mock
udevd --daemon
udevadm trigger
if CMD="$(command -v "$1")"; then
shift
exec "$CMD" "$@"
else
echo "Command not found: $1"
exit 1
fi
press [ESC] key to exit edit mode.
type :wq to write and exit.
type exit 2 times to exit out.
Go into HA UI and restart the container using Configuration.
You should be done now. 
1 Like
Hi, thnx, check my 2 post earlier, much easier to load it as custom component, so it retains after a HA update…
But anyway, I asked for a PR, so it’s resolved in 0.100 release
That’s the point, if its fixed in 0.100, there’s no need for a perm fix.
This will persist until a container update… to 0.100 
Yeah ,or just load it as a custom component for now, much easier and comfortable for users
Do you mean , load it as a custom?
an alternative for now, until 0.100 is out =>
download all the files, located from here, since its already in the .dev branche, you dont need the change the manifest file, if already points to new gpiozero 1.5.1
so download all files, below, place it in the folder under config => …\custom_components\remote_rpi_gpio
then restart hassio, in log folder you should see something like this example… then you now its loaded as custom
once 0.100 is out, then just remove that folder, dont need it anymore
WARNING (MainThread) [homeassistant.loader] You are using a custom integration for remote_rpi_gpio which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you do experience issues with Home Assistant.
1 Like
ok, i am testing the remote gpio, using gpio pin #18
i have a attached a doorbell to it, so it reads like 1-2 sec max 3 v
smetimes it works , sometime it doesnt … how is that possible? only my nodemcu esp8266 , this worked 100%
oh, and btw, is there somekind of sensor, so you can see if the raspberry is online/offline?
There has been lots written on RPi GPIO’s missing inputs, IIRC it had to do with kernel interrupts being missed if the kernel was busy. I am not sure if this has improved with Buster and newer kernel, but I have 2 remote GPIO sensors working reliably (so far on a Pi3B+ w Buster). Those both have long state changes however, not push button presses. People have messed with adding debounce, capacitance and other ideas, YMMV. Google it.
Try using an extra pin as input, software pull up, and ground the pin; make this a binary sensor when the pi turns on the sensor will too, and can be displayed in HA if remote connection is up. My 2 cents…
yeah, for me its now also working reliable, i think it was just a bad connection after all
also configured a binary sensor with remote gpio , my doorbell triggers the sensor for 2 seconds
btw, if you are using remote gpio , do you also have this issue since 100.0 ?
I do not have that error on .100.2, however I am not using hassio, I am in a venv on a Ubuntu Server PC… what version of gpiozero is Hassio using?
Since release 100, it’s running on 1.5.1, before it was 1.4.1, but then we had an issue about badpinfactory
So that version was also not running quite well…
What difference does it make if you are running ubuntu? And I am hassio?
AFIK It could be different due to the way the venv locks down the python versions, but the containers lock versions for all the OS packages, not just python. There may also be slight differences in the interface with the network and remote machines. I am no expert, just saying I think its possible for one to have a problem and not the other.
One other thing I have noticed is the if the remote RPi is rebooted, the remote RPi will not be available in my HA until HA is restarted, a source of a little frustration.
ah, didnt notice that yet 
Hi everyone, hate to drag up an old thread but this one seems most relevant to what I am experiencing.
Basically using switch: on remote gpio pins (with a relay connected high=on, low=off) has the following effect: when ha is restarted the relay is off (which is good), From overview I then switch the relay on and nothing happens, I then turn the switch off and the relay turns on. It then works as if invert_logic isn’t set.
I saw mention of this problem higher up and was wondering if it got fixed?
I am running HA on a raspberry pi 4 (Buster), which was manually installed and is version 0.104.2, everything else in HA seems to work perfectly.
Here’s a copy of my switch in HA config. It does the same thing on both remote pi’s
- platform: rpi_gpio
ports:
15: "House 15:Dummy amp"
- platform: remote_rpi_gpio
host: 192.168.0.25
invert_logic: true
ports:
14: TVpi 14 Sub Woofer
- platform: remote_rpi_gpio
host: 192.168.0.24
invert_logic: true
ports:
17: Oldpi port 17'
Hope someone can help.
Thanks
1 Like