Appdaemon and RPi.GPIO

Third party integrations AppDaemon
11

Thanks ReneTode, I think we’re narrowing in on the problem.

Current conig:

{
  "log_level": "info",
  "system_packages": [
    "gcc",
    "python-dev",
    "python3-dev"
  ],
  "python_packages": [
    "RPi.GPIO"
  ]
}

(No I probably don’t need python-dev and python3-dev, I was planning to remove one once it’s working).

Collecting RPi.GPIO
  Downloading https://files.pythonhosted.org/packages/f0/19/89e634790eb10d64ca87ce5c01751e784a730cf102262205d815275e883a/RPi.GPIO-0.6.4.tar.gz
Installing collected packages: RPi.GPIO
  Running setup.py install for RPi.GPIO: started
    Running setup.py install for RPi.GPIO: finished with status 'error'
    Complete output from command /usr/bin/python3.6 -u -c "import setuptools, tokenize;__file__='/tmp/pip-install-ugtyz0bv/RPi.GPIO/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-record-476q2v6o/install-record.txt --single-version-externally-managed --compile:
    running install
    running build
    running build_py
    creating build
    creating build/lib.linux-armv7l-3.6
    creating build/lib.linux-armv7l-3.6/RPi
    copying RPi/__init__.py -> build/lib.linux-armv7l-3.6/RPi
    creating build/lib.linux-armv7l-3.6/RPi/GPIO
    copying RPi/GPIO/__init__.py -> build/lib.linux-armv7l-3.6/RPi/GPIO
    running build_ext
    building 'RPi._GPIO' extension
    creating build/temp.linux-armv7l-3.6
    creating build/temp.linux-armv7l-3.6/source
    gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Os -fomit-frame-pointer -g -Os -fomit-frame-pointer -g -Os -fomit-frame-pointer -g -DTHREAD_STACK_SIZE=0x100000 -fPIC -I/usr/include/python3.6m -c source/py_gpio.c -o build/temp.linux-armv7l-3.6/source/py_gpio.o
    In file included from source/py_gpio.c:23:0:
    /usr/include/python3.6m/Python.h:11:20: fatal error: limits.h: No such file or directory
     #include <limits.h>
                        ^
    compilation terminated.
    error: command 'gcc' failed with exit status 1
    
    ----------------------------------------
Command "/usr/bin/python3.6 -u -c "import setuptools, tokenize;__file__='/tmp/pip-install-ugtyz0bv/RPi.GPIO/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-record-476q2v6o/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-install-ugtyz0bv/RPi.GPIO/
You are using pip version 10.0.1, however version 18.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

Any last ideas?

12

all i every time do is googling for the error and see if someone else had it and what packages come up.

in this case i found this page

yeah it goes about installing a different program, but on the page i find 3 different solutions:
install musl-dev or
install libc-dev or
install linux-headers

all would be system packages and i dont know whit which to go

then i added gpio to my search and found this:
http://forum.tinycorelinux.net/index.php?topic=20221.0

and they also talk about linux-headers, so i would go with that.

and yeah you are getting closer :wink:

13

Thanks for that. I google every time as well, I just struggle actually interpreting some of the issues I find.

adding linux-headers to the config errored.

But, the following config installs with no problems:

{
  "log_level": "info",
  "system_packages": [
    "gcc",
    "libc-dev",
    "python3-dev"
  ],
  "python_packages": [
    "RPi.GPIO"
  ]
}

Now I’m getting another error in my code, but I’m researching that first.

Thank you so much for all your help!

2 Likes
14

I don’t know if this deserves a separate issue or not. It is related, but a distinct issue.

Now I’m getting the following error in Appdaemon logs:

2018-11-04 17:23:34.999899 WARNING AppDaemon: Unexpected error in worker for App circuit:
2018-11-04 17:23:35.002117 WARNING AppDaemon: Worker Ags: {'name': 'circuit', 'id': UUID('8ca2c402-ee66-4975-9fce-67f80f9cbb36'), 'type': 'attr', 'function': <bound method Circuit.trigger of <circuit.Circuit object at 0x74729990>>, 'attribute': 'state', 'entity': 'input_boolean.trigger_universal_remote', 'new_state': 'on', 'old_state': 'off', 'kwargs': {'handle': UUID('b535d8e1-bf74-4de3-920f-f12d2eb80e5e')}}
2018-11-04 17:23:35.009009 WARNING AppDaemon: ------------------------------------------------------------
2018-11-04 17:23:35.013335 WARNING AppDaemon: Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/appdaemon/appdaemon.py", line 595, in worker
    self.sanitize_state_kwargs(app, args["kwargs"]))
  File "/config/appdaemon/apps/circuit.py", line 19, in trigger
    GPIO.setup(14, GPIO.OUT)
RuntimeError: No access to /dev/mem.  Try running as root!
2018-11-04 17:23:35.014570 WARNING AppDaemon: ------------------------------------------------------------

I’ve found that if I could run:

sudo adduser hass gpio

Then it may fix the issue, but I don’t think I can run this command since I am using HassOS?

If I was running Home Assistant in a docker env I would be able to, is that correct?

So now, to proceed, I need to swap to docker, is that correct?

15

you dont want to run appdaemon as root (sudo)
yeah, the problem with this is that you try to do advanced stuff with a system developed for noob use.
so you runin to all kind of trouble that normally would be easier to repair.

it seems the AD user which is probably the same as the hass user isnt able to read or write to /dev/mem

the whole dev dir is owned by root.
you could try to see if you could find the dir dev/mem and change the access so that the user running AD can access it. or add root access to the user. both solutions probably wont be easy on hassos and you need root access. (which is possible but not easy on default)

i would see if you get any response when you ask this in the hassio section. (maybe other have tried to use gpio also)

that said i googled for homeassistant gpio hassio and i noticed that there is a default component for home assistant.

so you might have travelled the wrong way.

add the gpio to your home assistant and then you can control them with appdaemon as well.

16

It took hours for me but this is the runing version on my hassio.

system_packages:
  - python3-dev
  - gcc
  - make
  - musl
  - musl-dev
  - libc-dev
python_packages:
  - RPi.GPIO
init_commands: []
log_level: info
1 Like
17

So what did you do, to run it as root.
I did the same implementation but still have the no Access problem.

18

actually, I couldn’t remember the case. Since I got other problems for controlling the relay, I have moved to venv version of the home assistant. I’m using a bottle script as a web service to trigger the relay.

19

Like a number of others on this forum and elsewhere, I have been trying to use
Appdaemon on a Raspberry pi to read data from GPIO pins and use it in Home Assistant.

In my case I’m trying to read the codes received by a 433MHz receiver attached to the pi
to GPIO PIN 27 using the rpi_rf module’s rpi-rf_receive.py script
(https://github.com/milaq/rpi-rf/blob/71fbe0507588cadd0e58978d2ed72a3cb5994f16/scripts/rpi-rf_receive)

But no luck as I keep getting this error:
File “/usr/lib/python3.8/site-packages/rpi_rf/rpi_rf.py”, line 188, in enable_rx
GPIO.setup(self.gpio, GPIO.IN)
RuntimeError: No access to /dev/mem. Try running as root!

Firstly, in my setup (Hass.io 32 bit for Raspberry pi 3b) there is no such directory as
/dev/mem
There is however this one
/sys/class/gpio
and when I enable the Raspberry PI GPIO integration in the configuration.yaml for pin 27
the folder GPIO27 appears in the above directory and events accrue in Home Assistant’s database.

It seems to be a permissions problem for AD apps accessing the GPIO pins of the pi.
So then I wondered what user Appdaemon apps run under and could I elevate that user’s permissions?

According to this little App I wrote it is actually the root user!
But root must have access to the GPIOs musn’t it?
Or is this a red herring?
And isn’t the advice not to run Appdaemon under the root user?

import appdaemon.plugins.hass.hassapi as hass
import os
import pwd

class DetectMotion(hass.Hass):
    
    def initialize(self):
        self.log("ok WE GOT THIS FAR now................")
        self.listen_now()

    def listen_now(self):
        self.log(pwd.getpwuid( os.getuid() )[ 0 ])

By the way I do have this in my Appdaemon configuation and all appears to go well according to the
Appdeamon logs.

system_packages: []
python_packages:
  - argparse
  - datetime
  - RPi.GPIO
  - rpi_rf
init_commands: []

Is there any way to fix this permissions problem without having to set up Home Assistant using venvs
or more complex onboarding?

Thanks in advance.

20

sorry, but i cant help with permissions on hassio.
i have never used it, and the permissions that the addon (AD docker) has is out of the reach from appdaemon.

not long ago i installed AD on a PI zero.
just a simple pip install, and i have working apps that use gpio

hassio is a very restricted area, to make sure that simple users dont come into trouble. and it also restricts the possibilities from AD.

so i see 2 ways to go:

  1. forget about hassio, or install hassio on another device then the PI that wants to use GPIO
  2. get in touch with frenck, and see if he can tell you how to get the needed permissions.

dont forget: AD is independant. it doesnt need to be on the same device that you run home assistant on. so its possible to have hassio on 1 PI and AD on another PI.

21

Thanks, all good advice. Will try contacting frenk first then, if no luck, your other suggestions. I’m a bit of a noob here so could you point me to some webpage that explains alternative suitable ways to install Home Assistant and AD on the same raspberry Pi?

22

the best way is to go to the AD discord.
were always there.

but i advise to keep hassio, and then get a second RPI and install AD on that one.
(you could still keep what you already got, but just add a new RPI)

if you dont want extra hardware:

then i advise:

  1. save your ha configuration
  2. reinstall the PI with pinoob or whatever linux version is im moment normal for RPI
  3. read about pi venv (its just a few commands to create a venv)
  4. create 1 venv in which you install HA
  5. create another venv in which you install AD.
  6. read the docs from AD to configure AD correct

then you can do what you want,m whenever you want.
support for every step is there daily on our discord server.

23

Excellent! Will do and thanks so much for your prompt responses.

1 Like
24

I got in touch with frenck. You might be interested to read his reply. If I understand it correctly, it is not a permissions problem but instead a bug in Appdaemon.

25

you understand it wrong.

its a bug in the addon.
and the addon has nothing to do with appdaemon.
the addon is a small piece of code written by frenck that makes it possible to run appdaemon on hassio.

thats why frenck says that he will correct it, while he cant correct anything in appdaemon, because frenck is no dev from appdaemon.

thats also why it can be used when you install AD stand alone, and get in trouble with hassio. :wink:
its like i suspected the bug in the addon makes that AD cant reach the pins.

26

Oh I see! Thanks. All clear now.

27

Ok, I have followed your six steps and all seems to be working fine now. I am able to access the GPIO pins without any difficulty from an app I wrote running under AD.
Would you mind if I asked another question?
I want to switch HomeAssistant from using its default SQlite to MySQL (or Maria). Should this database be set up in the HA venv or AD venv or its own? I wish to write more AppDaemon apps that will process received 433mhz signals on the RPI GPIO pin (27) and insert a subset of these into the states (etc) tables directly of HA.
I hope this makes sense!

28

this question is not really related to this topic, it would have been better to call me in new topic or to come to our discord server.

but when i respond anyway ill give you an answer.

is mySQL or mariaDB a python program??
i dont think so, so its not setup in any venv, because you use python venv for AD and HA :wink:

apps that respond to a GPIO pin make sense, but you dont want to input GPIO data directly into the HA DB!!!
the only one that puts data into the DB should be HA.
the way you would need to handle it is to write apps, that give commands to HA, and HA then writes it into the DB.
if you try to write to the HA states table directly, then HA doesnt see that. so that info goes completely unknown.
if you want that just to save data, then you can, but i would advise to use a different DB for that.

if this answers your questions enough then great. if not, please PM me or come to the AD discord server: https://discord.gg/pHsjADY

29

Thanks. I think I see where to go next. Maybe something like the command line sensor… The reason why I’m following this approach is that HA, though it has the GPIO switch platform, doesn’t seem capable of reading varying data arriving via a GPIO pin then filtering and dealing with it. As in this page:

But my variation on the rpi-rf receive script rpi-rf_receive will be able to do this (sorting out the wanted sniffed codes from the noise arriving from the hundreds of nearby 433Mhz sensors in my neighbourhood). The idea is to put only those signals coming from a list (a sort of list of “paired sensors”) into HA. I will continue this discussion soon on Discord once I have thought it over. Thanks again.

1 Like
30

I know this is an old thread, but I wanted to share my solution because it took forever to figure out.
I am running HA and AppDaemon in Docker containers and attempting to use RPi.GPIO through the Adafruit Neopixel library. The solution to No access to /dev/mem (at least for my case) was to allow access to the gpiomem and spidev0.0 devices from the docker container. So docker run --name=appdaemon <other arguments> --device /dev/gpiomem --device /dev/spidev0.0 when initializing the container. I don’t have enough knowledge to comment on the device security risks of this, so that’s worth looking into.