Remote GPIO with factory fails on Debian Stretch

[pfletch101]

Operating system: Raspbian Stretch and Debian Stretch - latest releases
Pi model: Pi 3 Model B+
GPIO Zero version: 1.4.1
Pin factory used: pigpio
See http://rpf.io/gpzissue for information on how to find out these details

I am exploring GPIO programming on my Pi 3B+, and I am currently looking at remote GPIO. To (I hoped!) somewhat simplify things, I am using a regular Debian VM as the controller. The Pi has been set up to allow remote control of GPIO, and the controller has the appropriate libraries installed. My Python 3 test program is as follows:

from gpiozero import LED
from gpiozero.pins.pigpio import PiGPIOFactory
from time import sleep

factory=PiGPIOFactory(host='[Pi IP Address]')
ledR=LED(2,pin_factory=factory)
while True:
	ledR.on()
	sleep(1)
	ledR.off()
	sleep(1)

This crashes spectacularly as follows:

peter@DebianVM:~/work$ python3 testpig.py
/usr/local/lib/python3.5/dist-packages/gpiozero/devices.py:452: PinFactoryFallback: Falling back from rpigpio: No module named 'RPi'
  'Falling back from %s: %s' % (name, str(e))))
/usr/local/lib/python3.5/dist-packages/gpiozero/devices.py:452: PinFactoryFallback: Falling back from rpio: No module named 'RPIO'
  'Falling back from %s: %s' % (name, str(e))))
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Can't connect to pigpio at localhost(8888)

Did you start the pigpio daemon? E.g. sudo pigpiod

Did you specify the correct Pi host/port in the environment
variables PIGPIO_ADDR/PIGPIO_PORT?
E.g. export PIGPIO_ADDR=soft, export PIGPIO_PORT=8888

Did you specify the correct Pi host/port in the
pigpio.pi() function? E.g. pigpio.pi('soft', 8888)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
/usr/local/lib/python3.5/dist-packages/gpiozero/devices.py:452: PinFactoryFallback: Falling back from pigpio: failed to connect to localhost:8888
  'Falling back from %s: %s' % (name, str(e))))
/usr/local/lib/python3.5/dist-packages/gpiozero/devices.py:452: PinFactoryFallback: Falling back from native: unable to open /dev/gpiomem or /dev/mem; upgrade your kernel or run as root
  'Falling back from %s: %s' % (name, str(e))))
Traceback (most recent call last):
  File "testpig.py", line 1, in <module>
    from gpiozero import LED
  File "/usr/local/lib/python3.5/dist-packages/gpiozero/__init__.py", line 22, in <module>
    from .devices import (
  File "/usr/local/lib/python3.5/dist-packages/gpiozero/devices.py", line 486, in <module>
    Device.pin_factory = _default_pin_factory()
  File "/usr/local/lib/python3.5/dist-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!

However, if I specify the location of the remote Pi on the command line (and whether or not I remove the host argument from the 'factory=...' line):
peter@DebianVM:~/work$ GPIOZERO_PIN_FACTORY=pigpio PIGPIO_ADDR=[Pi IP Address] python3 testpig.py
the script runs correctly and the LED on the remote Pi turns on and off in the expected sequence. Running the original script on another Pi on my network works fine (controlling the LED on the specified remote Pi as programmed). The crash only occurs when I try to run it on a 'regular' Debian VM.

According to the documentation, these two ways of specifying the 'target' of remote GPIO commands are equivalent. Clearly they are not! It looks as if, when the remote setting are not specified on the command line, the library code is crashing when it tries to initialize itself. What am I missing?

Edited X 2 to correct typo and correct omission in script listing

[bennuttall]

This is because at import time, no default pin factory could be found, even though you set it yourself in the script. It's a bug really, and will be addressed in a future release, but for now all you need to do is use an env var. You can set it to GPIOZERO_PIN_FACTORY=mock and just use a different one in-line.

See #600.

[pfletch101]

Until the bug is fixed, the documentation needs to reflect this reality, rather than giving an example that doesn't work!

[bennuttall]

Ok

[pfletch101]

If you wish (and do not think it presumptuous!) I would be happy to suggest appropriate changes to the documentation.

[bennuttall]

I've added a note here: https://gpiozero.readthedocs.io/en/latest/remote_gpio.html#pin-factories

Any thoughts?

[pergolafabio]

@bennuttall is this issue alread fixed?
i run Home Assisant, and have the same issues connecting to a remote PI

thnx in advance