agners
commented
1 year ago HAOS uses the same kernel as Raspberry Pi OS, so it seems odd that this does work on Raspberry Pi OS and does not on HAOS.
Can you check the Linux kernel version you are using on Raspberry Pi OS (using uname -a?).
Are you using 32-bit version of Raspberry Pi OS as well?
What is surprising to me is that there is no error on Pilight. I would expect if something is preventing access to get some type of error from whichever process is trying to access the GPIO pins.
Over time, there have been different API's available to control the GPIO (/dev/mem, /sys/class/gpio and the latest /dev/gpiochipX. Do you know what Pilight is using?
LeoCal
github-actions[bot]
Describe the issue you are experiencing
Hello,
I'm facing an issue with HA OS to send a signal from an add-on container (running Pilight) to the GPIO of a Raspberry PI 4. Although the add-on seems to be working fine (Pilight logs show the command is well received from the daemon running in the add-on), it seems the OS is somehow preventing the signal to get to the GPIO (I measured with a multimeter directly on the GPIO data PIN).
Suspecting an issue with the 433MHz module or the RPI itself, I've done the following experiments: 1) I installed Raspberry OS (Bullseye version) on the same RPI4, then installed Pilight directly on the OS via "apt install" -> all working fine 2) I installed Docker on Raspberry PI OS, then installed Pilight container (pretty much same Dockerfile content) -> all working fine
In both cases, the 433MHz transmitter is correctly turning on/off 433MHz devices; moreover, my multimeter shows the signal makes it to the data PIN via GPIO.
But as I would really like to move to HA OS (instead of HA core), I loaded again HA OS and ran a few other experiments: 1) I've disabled protection mode for the Add-On, giving pretty much permission to access the entire system (yes, I know it's not a good practice, but I need to start troubleshooting somewhere) -> nothing, it doesn't work 2) I've manually run the "docker run ... --privileged ..." command that was working directly on Docker, and again, it doesn't work.
Is it a bug in the HA OS? Or perhaps is that a known limitation? I do you suggest going about it?
I'd really like to move to run HA OS instead of HA Core, but this is one of the last things I need to sort out before the move.
What operating system image do you use?
rpi4 (Raspberry Pi 4/400 32-bit OS)
What version of Home Assistant Operating System is installed?
9.4
Did you upgrade the Operating System.
Yes
Steps to reproduce the issue
Please see my full description of how to reproduce the issue above.
Anything in the Supervisor logs that might be useful for us?
Anything in the Host logs that might be useful for us?
System information
System Information
Home Assistant Cloud
logged_in | false -- | -- can_reach_cert_server | ok can_reach_cloud_auth | ok can_reach_cloud | okHome Assistant Supervisor
host_os | Home Assistant OS 9.4 -- | -- update_channel | stable supervisor_version | supervisor-2022.11.2 agent_version | 1.4.1 docker_version | 20.10.19 disk_total | 219.4 GB disk_used | 3.0 GB healthy | true supported | true board | rpi4 supervisor_api | ok version_api | ok installed_addons | Pilight Server (1.7.2), File editor (5.4.2), Terminal & SSH (9.6.1), pilight (1.0.4)Dashboards
dashboards | 1 -- | -- resources | 0 mode | auto-genRecorder
oldest_recorder_run | 15 dicembre 2022, 20:09 -- | -- current_recorder_run | 17 dicembre 2022, 16:52 estimated_db_size | 1.54 MiB database_engine | sqlite database_version | 3.38.5Additional information
No response