Gpiozero with pigpio on appdaemon - how?

Hi,

My use case is the following:

  • HA installed on RPi1
  • RPi2 located physically at another location (sane LAN), RPi1 cannot be moved to that location
  • Simple door lock binary switch is wired and controlled by RPi2 using GPIO
  • I want to lock/unlock the door using HA on RPi1

From Dr. Google I gathered that in general I have 3 options:

  1. Local MQTT server and so on
  2. REST web server on RPi2 using Flask and so on
  3. Remote GPIO using gpiozero+pigpio

It seems to me that the GPIO option is the most straight forward and easiest way.

Starting to gather the ā€˜intel.ā€™ I kind of hit a wall almost on phase one - I donā€™t know how to add the correct import of gpiozero and ipgpio to the appdaemon python file. Can someone point me to the right direction?

For now I have set the appdaemon config to:

{
  "log_level": "info",
  "disable_auto_token": false,
  "system_packages": [],
  "python_packages": [
    "pigpio",
    "gpiozero"
  ]
}

but having this code on the app fails:

import appdaemon.plugins.gpiozero as gpiozero

and also this one fails:

import gpiozero as gpiozero

(if needed I can post here the log)

Thanks.

you use hassio, so adding packages like this are never easy and for sure not straight forward.
did you restart appdaemon after adding the packages?
did appdaemon start without errors after that?

i can help you trying to set this up but it could be a painfull route.

i think you got a way better option:
install appdaemon on the RPI 2
just a simple pip install.
then you can directly connect to HA from the RPI 2 and use normal ways to use the gpio settings, and if you need to install packages you can just use pip.

1 Like

Hi @ReneTode, you are right, forgot to mention using hassioā€¦

yes, I restarted appdaemon and it started without any issues, here are the relevant log parts after restarting:

[cont-init.d] 81-python-packages.sh: executing... 
Collecting pigpio
  Downloading https://files.pythonhosted.org/packages/c2/d5/ea6915387db93c47f1078fe51ede004667d663c86a29354cb3c1f912a90d/pigpio-1.42-py2.py3-none-any.whl
Installing collected packages: pigpio
Successfully installed pigpio-1.42
You are using pip version 18.1, however version 19.0.3 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
Collecting gpiozero
  Downloading https://files.pythonhosted.org/packages/32/f7/26943d000d357907357f5a52aaf19083d17b2c1ae11e380c2e5a5109ba9e/gpiozero-1.5.0-py2.py3-none-any.whl (139kB)
Collecting colorzero (from gpiozero)
  Downloading https://files.pythonhosted.org/packages/cc/a2/718e78485d0a42c3c2971e0d4a0eb9878bd1121cd640f0773de0695c858e/colorzero-1.1-py2.py3-none-any.whl
Installing collected packages: colorzero, gpiozero
Successfully installed colorzero-1.1 gpiozero-1.5.0
You are using pip version 18.1, however version 19.0.3 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
[cont-init.d] 81-python-packages.sh: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
2019-02-28 20:14:17.628764 INFO AppDaemon: Loading App Module: /config/appdaemon/apps/gpiozero_test.py
2019-02-28 20:14:17.631801 WARNING AppDaemon: ------------------------------------------------------------
2019-02-28 20:14:17.632334 WARNING AppDaemon: Unexpected error loading module: /config/appdaemon/apps/gpiozero_test.py:
2019-02-28 20:14:17.632828 WARNING AppDaemon: ------------------------------------------------------------
2019-02-28 20:14:17.638694 WARNING AppDaemon: Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/appdaemon/appdaemon.py", line 2026, in check_app_updates
    self.read_app(mod["name"], mod["reload"])
  File "/usr/lib/python3.6/site-packages/appdaemon/appdaemon.py", line 1809, in read_app
    self.modules[module_name] = importlib.import_module(module_name)
  File "/usr/lib/python3.6/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 994, in _gcd_import
  File "<frozen importlib._bootstrap>", line 971, in _find_and_load
  File "<frozen importlib._bootstrap>", line 955, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 665, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 678, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/config/appdaemon/apps/gpiozero_test.py", line 3, in <module>
    import ipgpio as ipgpio
ModuleNotFoundError: No module named 'ipgpio'
2019-02-28 20:14:17.639228 WARNING AppDaemon: ------------------------------------------------------------
2019-02-28 20:14:17.639861 WARNING AppDaemon: Removing associated apps:
2019-02-28 20:14:17.640549 WARNING AppDaemon: gpiozero_test

Regardless of the above, Iā€™m more than willing to follow your suggested path :smiley:
Just to make sure we are aligned - when someone activates the unlock input boolean on HA UI (RPI1), it should eventually make GPIO pull_up on RPI2. Iā€™m stating as you wrote

which sounds to me the opposite wayā€¦

Let me know whatā€™s next - Thanks!!

if you install AD on the RPI2 you can listen_state to see what is going on in HA
then you can let the callback to the pullup locally

you still need working code though, and at least i can say that you cant import that way, because you havent installed ipgpio but gpiozero and pigpio

so i think it should be

import pigpio and not import ipgpio :wink:

ooooopps, you are right :grimacing:

It runs now without an error on the log. Tomorrow Iā€™ll try to see if it really works remotely.

While at, in parallel testing your suggested path, I installed AD on RPI2 but it didnā€™t create any folder and any config files. the AD itself is there and I can check itā€™s version for example. How should I continue with this route? (i.e. where/how to create the folders/files - which I assume should be similar to what I have now on my hassio).
correct me if Iā€™m wrong but I think that your suggestion of having AD on RPI2 is more secure than using remote GPIO, right?

no its not particular more secure.
but you have an automation environment local, so you can do more with it.
depending on the way remote gpio works, it might also be more dependable and or more easy to program, but i cant say that for sure, because i dont have anything like that (yet)

about the structure:
you can create the AD configuration directory anywhere you like.
how to configure AD can be found in the docs https://appdaemon.readthedocs.io/en/latest/CONFIGURE.html

Failed to make it work using remote GPIO
but
made it using your suggestion of installing AD on RPI2 :+1::+1::+1:

quick config question - should I use different api_key (on appdaemon.yaml file) than the one on my RPI1? or it doesnā€™t matter? same question for the HASS token. I see that it works with same values, but Iā€™m asking on ā€œbest practiceā€ (if yes, then also how do I generate the api_key?).

you dont need api key anymore (unless you have dashboards that show cams, then you need it in HA and in the dashboard.

but in appdaemon.yaml you leave it out.
i would suggest 2 different long lived tokens for the different appdaemon instances.

allthough i didnt work with it, i just suspected that it would be more easy to get local GPIO working then remote.
glad you worked it out.

I do have cameras, but didnā€™t arrive to the Dashboard yet, anyway, itā€™s on RPI1ā€¦ I still have a long path ahead of meā€¦

Thanks for everything, cheers.

1 Like

Hi,

I hope it is not too offtopic -
Iā€™v been able to make the AD service run at boot (not exactly as described on the AD site though) but have couple of related questions:

  1. How can I see a log (for example when having self.log("..."))?
  2. Iā€™ve noticed I can see some errors when running $ sudo systemctl status [email protected] Can this be also written to the same log from point 1?
  3. Doesnā€™t auto-update work here like it works with AD on HASSIO? Do I have to reload and restart the service on every change?
  4. On the service file I used User=pi. Is it ok or should it be User=%I? Couldnā€™t find anything clear on this with Dr. Googleā€¦

Thanks again.

its your topic :wink:

in the appdaemon.yaml you can set the place where the log entries are saved. default to STDOUT and STDERR but you can set any file wilh path you like for that.

yeah it does, but when you make errors that prevent the app from starting, it wont start and just generate an error

if you have installed AD as user pi, it should be oke how you do it.
does the service start on reboot? then it is oke (look at the logs(after you have set them) if AD is restarted oke)

Well, once public, itā€™s of everybody on this forum and stating a subject saying one thing while discussion goes somewhere else, makes the things a bit harder for other peopleā€¦ Anyway, thatā€™s all a theoretic discussion :wink:

yes, but is it possible to see this STDOUT flow on my terminal? (is this pure linux question?) - having it saved to a file is less comfortable for real-time debugging/testing (besides sdcard wearā€¦)

I was logged in through VNC as pi user and used ā€˜sudoā€™ to run pip3.

yes, ok, thanks - I saw it by running $ sudo systemctl status [email protected], besides having some automation already firing :smiley:

STDOUT saves it to the default linux logs, where other stuff goes also, when you start appdaemon as service. when starting it manual as terminal it goes to the terminal screen.
so it doesnt matter what you do when it starts as service, to see it realtime, you need to til a log. and by setting it as dedicated log its just more easy.
you just have to decide which program to use to tail the log.

that wasnt the best decision. for future: never use sudo with pip, unless you really need to.
with sudo its installed as root user, which makes that the filerights are different.
that can cause trouble when you start the service as pi user and not as root user.

never depend on something running by seeing something running. ALWAYS check your logs after restarting to see if everything is started allright, and that there were no errors.
for sure with something like appdaemon, you dont know if every part is started.
but at least you can know that what you placed in the service did something :wink:

OK, much clearer now.

Well, this was the instruction on the AD docsā€¦

Note taken, thanks! :wink:
BTW, systemctl status does show the initialization log output (with errors if exist, for example py file without definition in apps.yaml)

hmm, you are right.
ill talk about that with Andrew.

yeah with that command you look at the systemlogs where STDOUT is going, if i am correct.