Raspberry Pi 5 PIR GPIO für Touchscreen Aktivierung im Autostart

[woupi]

Hallo,

ich habe mich hier neu angemeldet da ich ein Problem habe und hoffe, dass mir hier einer weiter helfen kann.
Ich habe auf der suche nach Lösungen ein Thema hier aus dem Forum gefunden, was aber leider nicht ganz passt und eröffne darum ein neues.

Ich habe mir einen Raspberry PI 5 und einen Touchscreen Monitor zugelegt. Beides soll in einem Zimmer an der Wand hängen und meine VIS aus iobroker zeigen.
Der Monitor soll sich nach einer einstellbaren Zeit abschalten und über einen Bewegungsmelder wieder aktiviert werden.
Dazu habe ich einen Bewegungsmelder (HC-SR501 PIR Sensor - Infrarot Bewegungsmelder) an die GPIO des Raspberry angeschlossen. Ich benutze GPIO PIN 5V, PIN GND und PIN 23.
Auf der suche nach Lösungen habe ich viele Seiten gefunden die sich allerdings immer auf RPi.GPIO.
Da die Lösungen/Skripte alle nicht funktioniert haben, habe ich weiter gesucht und wenn ich es richtig verstanden habe, auch den Grund gefunden. RPi.GPIO wird von Raspberry PI OS 5 nicht unterstützt.
Stattdessen muss GPIOzero verwendet werden.

Ich muss dazu sagen, dass dies mein erster Raspberry ist und ich auch mit Python noch nie etwas zu tun hatte. Folglich natürlich auch keine Ahnung von RPi.GPIO und GPIOzero habe.
Da ich wie gesagt nichts passendes gefunden habe, habe ich KI benutzt um mir ein Skript (pir.py) zu erstellen.
Wenn ich das skript vom Terminal aus mit python3 pir.py starte, funktioniert es.
Das war der "leichte" Teil.
Dann habe ich versucht diese Skript automatisch beim Start ausführen zu lassen. Meine suche danach hat erstmal zwei Ansätze gefbracht.
1. crontab und
2. systemctl
Beide führen aber leider nicht dazu, dass das skript bei Start ausgeführt wird.
Dann hat mich einer aus dem iobroker Forum darauf hin gewiesen, dass das so eventuell nicht funktioniert und das skript über LXDE Autostart gestartet werden muss, sicher ist er sich aber auch nicht.
Auch das habe ich probiert und das skript wird auch gestartet.
Nach ca. 10 min beendet sich das skript allerdings wieder.

Ob das skript läuft oder nicht prüfe ich mit pgrep -f pir.py, etwas anderes habe ich leider nicht gefunden. Wenn nichts zurückgegeben wird, läuft es nicht. Wenn eine ID zurück gegeben wird prüfe ich mit ps -p und der ID ob python3 ausgegeben wird.
Daraufhin habe ich auch mal im Taskmanager nachgesehen und festgestellt, dass es, wenn das Skript läuft, eine Task python3 gibt und wenn das skript nicht läuft, nicht.

Den Grund warum das skript beendet wird kenne ich nicht, was aber noch aufgefallen ist, ist das gleichzeitig meine VIS im browser nicht mehr angezeigt wird da steht dann "Oh nein! Fehler beim Anzeigen dieser Webseite. Fehlercode: 9". Klicke ich dann auf Neu Laden wird sie weder angezeigt.
Da dies gleichzeitig passiert, vermute ich da einen Zusammenhang.

Ich hoffe ich habe alles wichtige nun geschrieben, hier aber natürlich noch das skript:

Code: Alles auswählen

from gpiozero import MotionSensor
import subprocess
import time

# GPIO-Pin für den Bewegungssensor
MOTION_SENSOR_PIN = 23

# Befehl zum Einschalten des Touchscreen-Monitors
TURN_ON_COMMAND = "xset -display :0 dpms force on"

# Initialisierung des Bewegungssensors
motion_sensor = MotionSensor(MOTION_SENSOR_PIN)

# Funktion zum Einschalten des Touchscreen-Monitors
def turn_on_screen():
    subprocess.run(TURN_ON_COMMAND, shell=True)

# Hauptfunktion
def main():
    try:
        while True:
            # Ueberprüfe auf Bewegung
            if motion_sensor.motion_detected:
                turn_on_screen()
                print("Bewegung erkannt! Bildschirm eingeschaltet.")
                # Warte eine Weile, bevor du erneut nach Bewegung suchst
                time.sleep(10)
            else:
                # Warte kurz, um die CPU nicht zu belasten
                time.sleep(0.1)
    except KeyboardInterrupt:
        print("Programm beendet.")

if __name__ == "__main__":
    main()

Und hier noch die Autostart Datei die sich unter /home/pi/.config/lxsession/LXDE-pi/autostart befindet:

Code: Alles auswählen

@lxpanel --profile LXDE-pi
@pcmanfm --desktop --profile LXDE-pi
#@xscreensaver -no-splash
@xset s on
@xset s 0 0
@xset s blank
@xset s expose
@xset dpms 900 0 0
@xset +dpms
@chromium-browser --start-fullscreen http://xxx.xxx.xxx.xxx/vis-2/?HomeVis2_1#Home
@unclutter -idle 1
@python3 /home/pi/pir.py

Den Raspberry PI habe ich übrigens auf x11 umgestellt.

Ich hoffe sehr, das mir hier einer Helfen kann, nach jetzt drei Tagen suchen und versuchen und zwei mal Raspberry komplett Neu Installation bin ich ziemlich verzweifelt.
Danke und VG

[woupi]

Kurze Rückmeldung.
Das skript ist die ganze Nacht durch gelaufen. Ich habe noch Debugging--Anweisungen eingebaut (Laufzeit, Uhrzeit und CPU Temp) und diese in einem file speichern lassen.
Dadurch konnte ich sehen, dass der Raspberry mit seiner CPU Temperatur (bis über 80°) sehr hoch geht und das obwohl nur das skript läuft.

Jetzt ist meine Vermutung, dass diese gestern als ich auch noch zusätzlich auf dem Raspberry ein paar andere Dinge gemacht habe, die Temperatur zu hoch gegangen ist und deshalb das skript abgeschaltet wurde.
Vorsicht, eine sehr laienhafte Vermutung.

VG

[__deets__]

Das Skript sollte nicht wegen der Temperatur gestoppt werden. Die ist nicht gut, aber es gibt kein Verstaendnis im System dafuer, dass da ein bestimmtes Skript Last verursacht, und darum abgeschossen wird. Und eigentlich hast du ja auch sleeps drin. Wobei man das noch besser hinbekaeme, indem man die IRQ-Events benutzt.

Ich wuerde dir empfehlen, dein Skript NICHT ueber die Desktop-Umgebung, sondern als systemd service zu starte.n Der Vorteil: du kannst die auch automatisch neu starten lassen, wenn der mal abschmiert (aus welchem Grund auch immer), und das journal enthaelt log-Daten, ob und warum das ggf gecrasht ist. Und mit systemctl status meine-unit kannst du auch ohne pgrepperei rausfinden, ob es laeuft.

[Dennis89]

Hallo,

von der RasperryPi-Foundation wird beim Pi5 auf die Benutzung eines Kühlers hingewiesen. Hast du einen verbaut?

Ich habe leider keinen Pi5 und kann die Temperaturen ohne Kühler nicht testen.



Grüße
Dennis

[__deets__]

@Dennis: der Kuehler erhoeht die Leistung, weil er das automatische Drosseln verhindert. Aber kaputt geht da nix, ich habe den hier auf dem Tisch tagelang laufen auf 4 Kernen 100% Last, fuer ein Kundenprojekt. Vollkommen stabil.

[__blackjack__]

@woupi: Anmerkungen zum Quelltext:

Auf Modulebene sollte nur Code stehen der Konstanten, Funktionen, und Klassen definiert. Das Hauptprogramm steht üblicherweise in einer Funktion die `main()` heisst. `motion_sensor` gehört dort nicht hin.

Kommentare sollen dem Leser einen Mehrwert über den Code geben. Faustregel: Kommentare beschreiben nicht *was* der Code macht, denn das steht da bereits als Code, sondern warum er das macht. Sofern das nicht offensichtlich ist. Offensichtlich ist in aller Regel auch was in der Dokumentation von Python und den verwendeten Bibliotheken steht.

`MotionSensor` hat eine Methode um auf Bewegung zu warten.

``shell=True`` sollte man vermeiden wenn man kann, und hier ist das problemlos möglich. Der Aufruf braucht keine zusätzliche Shell zwischen den beiden Prozessen.

Ungetestet:

Code: Alles auswählen

#!/usr/bin/env python3
import subprocess

from gpiozero import MotionSensor

MOTION_SENSOR_PIN = 23

TURN_ON_COMMAND = ["xset", "-display", ":0", "dpms", "force", "on"]


def turn_on_screen():
    subprocess.run(TURN_ON_COMMAND, check=True)


def main():
    try:
        motion_sensor = MotionSensor(MOTION_SENSOR_PIN)
        while True:
            motion_sensor.wait_for_motion()
            turn_on_screen()
            print("Bewegung erkannt! Bildschirm eingeschaltet.")
            motion_sensor.wait_for_no_motion()

    except KeyboardInterrupt:
        print("Programm beendet.")


if __name__ == "__main__":
    main()

Die 80°C werden wohl weniger von diesem Programm kommen, sondern eher von Chromium oder einem Dienst.

[woupi]

Erstmal vielen Dank für eure Antworten, auf die ich hier mal reagieren möchte.

Das Skript sollte nicht wegen der Temperatur gestoppt werden. Die ist nicht gut, aber es gibt kein Verstaendnis im System dafuer, dass da ein bestimmtes Skript Last verursacht, und darum abgeschossen wird. Und eigentlich hast du ja auch sleeps drin. Wobei man das noch besser hinbekaeme, indem man die IRQ-Events benutzt.

War meine laienhafte Vermutung. Komischerweise läuft es jetzt auch.

Ich wuerde dir empfehlen, dein Skript NICHT ueber die Desktop-Umgebung, sondern als systemd service zu starte.n Der Vorteil: du kannst die auch automatisch neu starten lassen, wenn der mal abschmiert (aus welchem Grund auch immer), und das journal enthaelt log-Daten, ob und warum das ggf gecrasht ist. Und mit systemctl status meine-unit kannst du auch ohne pgrepperei rausfinden, ob es laeuft.

Das mit systemctl hatte ich versucht. Dazu habe ich Anleitungen gefunden. Diese Anleitung bezogen sich alle auf ältere Raspberry. Das skript wurde allerdings nicht gestartet.
Da ich bis jetzt weder etwas mit Raspberry noch mit Python zu tun hatte kann ich aber nicht sagen, ob die Anleitungen einfach nicht zum Raspberry PI 5 passen oder ob es einen anderen Grund gibt.
Wenn ich das Skript über den Terminal gestartet habe, lief es. Darum habe ich weiter gesucht und im iobroker Forum sagte mir dann einer, das das wahrscheinlich mit systemctl nicht geht.

Deine Aussage bedeutet für mich jetzt aber, dass das nicht stimmt und dass ich weiter versuchen muss.

...von der RasperryPi-Foundation wird beim Pi5 auf die Benutzung eines Kühlers hingewiesen. Hast du einen verbaut?

Seit heute morgen ja, vorher nein. Jetzt pendelt sich die CPU Temp. so auf 50° ein.

@Dennis: der Kuehler erhoeht die Leistung, weil er das automatische Drosseln verhindert. Aber kaputt geht da nix, ich habe den hier auf dem Tisch tagelang laufen auf 4 Kernen 100% Last, fuer ein Kundenprojekt. Vollkommen stabil.

Das ist eine gute Info. Besser ist aber die CPU Temp. nicht so hoch zu bringen und darum habe ich jetzt den Lüfter auch noch eingebaut.

@woupi: Anmerkungen zum Quelltext:

Auf Modulebene sollte nur Code stehen der Konstanten, Funktionen, und Klassen definiert. Das Hauptprogramm steht üblicherweise in einer Funktion die `main()` heisst. `motion_sensor` gehört dort nicht hin.

Kommentare sollen dem Leser einen Mehrwert über den Code geben. Faustregel: Kommentare beschreiben nicht *was* der Code macht, denn das steht da bereits als Code, sondern warum er das macht. Sofern das nicht offensichtlich ist. Offensichtlich ist in aller Regel auch was in der Dokumentation von Python und den verwendeten Bibliotheken steht.

`MotionSensor` hat eine Methode um auf Bewegung zu warten.

``shell=True`` sollte man vermeiden wenn man kann, und hier ist das problemlos möglich. Der Aufruf braucht keine zusätzliche Shell zwischen den beiden Prozessen.

Die 80°C werden wohl weniger von diesem Programm kommen, sondern eher von Chromium oder einem Dienst.

Da ich vom Programmieren im Allgemeinen und von Python im speziellen keine Ahnung habe, bin ich dir zu extremen Dank verpflichten. Ich werde heute Abend deinen Code ausprobieren und auch versuchen den automatischen Start wieder über systemctl ausführen zu lassen.

Sobald ich das gemacht habe, werde ich eine Rückmeldung geben und würde mich sehr über weiter Unterstützung freuen, falls es auf nicht auf Anhieb funktioniert.

PS:
Ich habe gerade über VPN und putty nachgesehen ob das Skript noch läuft. Leider läuft es wieder nicht mehr. Da die Temperatur jetzt allerdings bei ca. 50° liegt und auch die ganze Zeit gelegen hat, ist eure Aussage bestätigt. An der Temperatur liegt es nicht.

Vielen Dank nochmal an alle und VG

[__deets__]

Das mit systemctl hatte ich versucht. Dazu habe ich Anleitungen gefunden. Diese Anleitung bezogen sich alle auf ältere Raspberry. Das skript wurde allerdings nicht gestartet.
Da ich bis jetzt weder etwas mit Raspberry noch mit Python zu tun hatte kann ich aber nicht sagen, ob die Anleitungen einfach nicht zum Raspberry PI 5 passen oder ob es einen anderen Grund gibt.
Wenn ich das Skript über den Terminal gestartet habe, lief es. Darum habe ich weiter gesucht und im iobroker Forum sagte mir dann einer, das das wahrscheinlich mit systemctl nicht geht.

Deine Aussage bedeutet für mich jetzt aber, dass das nicht stimmt und dass ich weiter versuchen muss.

Ohne die Unit zu sehen, kann man das natuerlich nicht gut beurteilen. Allerdings gibt es durchaus einen Hinweis, der noch fehlen koennte (und die Aussage von dem iobroker-Forums-Kollegen erklaert): xset wird Verbindung zu der grafischen Umgebung aufbauen wollen, und dazu muss die Umgebung stimmen.

Ich habe das gerade mal ausprobiert, und so geht es fuer mich:

1) Ich habe eine Datei playback.py, die ein pygame Fenster oeffnet (das ist aber egal, dein Skript tut genauso)

Code: Alles auswählen

#!/usr/bin/python3
import pathlib
import time

import pygame.mixer


BASE = pathlib.Path(__file__).parent

WAV = BASE / "717412__timbre__trap-ed-in-portishead-stems-from-co-producer.wav"

assert WAV.exists()


def main():
    pygame.init()
    pygame.mixer.init()
    pygame.mixer.music.load(WAV)
    pygame.mixer.music.play()

    (width, height) = (300, 200)
    screen = pygame.display.set_mode((width, height))
    pygame.display.flip()

    time.sleep(10)


if __name__ == '__main__':
    main()

Dann habe ich eine Datei

Code: Alles auswählen

~/.config/systemd/user/playback.service

mit folgendem Inhalt:

Code: Alles auswählen

[Unit]
PartOf=graphical-session.target
After=graphical-session.target

[Install]
WantedBy=graphical-session.target

[Service]
ExecStart=/home/ich/projects/private/usb-triggered-audio-playback/playback.py

Und dann mit

Code: Alles auswählen

systemctl --user daemon-reload
systemctl --user start playback

spielt die Musik & es oeffnet sich ein Fenster.

Und mit status bekommt man sehr schoen zu sehen, was die unit gemacht hat (um eben zu debuggen):

Code: Alles auswählen

$ systemctl --user status playback
○ playback.service
     Loaded: loaded (/home/ich/.config/systemd/user/playback.service; disabled; vendor preset: enabled)
     Active: inactive (dead)

Feb 06 11:07:14 paddie systemd[2254]: Started playback.service.
Feb 06 11:07:24 paddie playback.py[25491]: pygame 2.1.2 (SDL 2.0.20, Python 3.10.12)
Feb 06 11:07:24 paddie playback.py[25491]: Hello from the pygame community. https://www.pygame.org/contribute.html
Feb 06 11:07:24 paddie systemd[2254]: playback.service: Consumed 2.137s CPU time.
Feb 06 11:07:29 paddie systemd[2254]: Started playback.service.
Feb 06 11:07:40 paddie playback.py[25661]: pygame 2.1.2 (SDL 2.0.20, Python 3.10.12)
Feb 06 11:07:40 paddie playback.py[25661]: Hello from the pygame community. https://www.pygame.org/contribute.html
Feb 06 11:07:40 paddie systemd[2254]: playback.service: Consumed 2.186s CPU time.

[woupi]

Ohne die Unit zu sehen, kann man das natuerlich nicht gut beurteilen. Allerdings gibt es durchaus einen Hinweis, der noch fehlen koennte (und die Aussage von dem iobroker-Forums-Kollegen erklaert): xset wird Verbindung zu der grafischen Umgebung aufbauen wollen, und dazu muss die Umgebung stimmen.

Genau, es ging um xset. Er meinte es müsste in den X Autostart, also LXDE-pi/autostart, kennt sich aber auch nicht aus.

Dann habe ich eine Datei

Code: Alles auswählen

~/.config/systemd/user/playback.service

mit folgendem Inhalt:

Code: Alles auswählen

[Unit]
PartOf=graphical-session.target
After=graphical-session.target

[Install]
WantedBy=graphical-session.target

[Service]
ExecStart=/home/ich/projects/private/usb-triggered-audio-playback/playback.py

Und dann mit

Code: Alles auswählen

systemctl --user daemon-reload
systemctl --user start playback

Das hatte ich auch so gemacht, klar natürlich mit anderen Pfaden, aber sonst war das genauso.

Code: Alles auswählen

$ systemctl --user status playback
○ playback.service
     Loaded: loaded (/home/ich/.config/systemd/user/playback.service; disabled; vendor preset: enabled)
     Active: inactive (dead)

Feb 06 11:07:14 paddie systemd[2254]: Started playback.service.
Feb 06 11:07:24 paddie playback.py[25491]: pygame 2.1.2 (SDL 2.0.20, Python 3.10.12)
Feb 06 11:07:24 paddie playback.py[25491]: Hello from the pygame community. https://www.pygame.org/contribute.html
Feb 06 11:07:24 paddie systemd[2254]: playback.service: Consumed 2.137s CPU time.
Feb 06 11:07:29 paddie systemd[2254]: Started playback.service.
Feb 06 11:07:40 paddie playback.py[25661]: pygame 2.1.2 (SDL 2.0.20, Python 3.10.12)
Feb 06 11:07:40 paddie playback.py[25661]: Hello from the pygame community. https://www.pygame.org/contribute.html
Feb 06 11:07:40 paddie systemd[2254]: playback.service: Consumed 2.186s CPU time.

Hier wurde dann ausgegeben, dass das Skript nicht gestartet wurde, den genauen Wortlaut des Fehlers kenne ich jetzt nicht mehr, werde es aber heute Abend nochmal versuchen und wenn es nicht funktioniert den Wortlaut hier mal posten.

Vielen Dank für die Anleitung.
VG

[woupi]

Ich habe mich gerade per VPN mit meinem Heimnetz verbunden und über putty die pir.py gelöscht und neu erstellt.
Dazu habe ich deinen code verwendet.
Anschließend habe ich ihn über das Terminal gestartet. und mit pgrep -f pir.py geprüft ob es ausgeführt wird.
Wird es.

Ob nun der Touchscreen auf Bewegung wieder aktiviert wird kann ich dann gleich zu Hause prüfen.

Wenn ich es noch schaffe, werde ich mich auch noch systemctl geben.

VG

[woupi]

Ich habe jetzt noch

Code: Alles auswählen

mkdir -p ~/.config/systemd/user

erstellt. Dann

Code: Alles auswählen

sudo nano ~/.config/systemd/user/pir.service

mit

Code: Alles auswählen

[Unit]
PartOf=graphical-session.target
After=graphical-session.target

[Install]
WantedBy=graphical-session.target

[Service]
ExecStart=/home/pi/pir.py

erstellt. Anschließend habe ich folgende Befehle ausgeführt:

Code: Alles auswählen

systemctl --user daemon-reload
systemctl --user start pir
systemctl --user status pir

Das ist die Ausgabe:

Code: Alles auswählen

x pir.service
     Loaded: loaded (/home/pi/.config/systemd/user/pir.service; disabled; preset: enabled)
     Active: failed (Result: exit-code) since Tue 2024-02-06 14:26:56 CET; 19s ago
   Duration: 392us
    Process: 10111 ExecStart=/home/pi/pir.py (code=exited, status=203/EXEC)
   Main PID: 10111 (code=exited, status=203/EXEC)
        CPU: 581us

Feb 06 14:26:56 raspberrypi (pir.py)[10111]: pir.service: Failed at step EXEC spawning /home/pi/pir.py: Permission denied
Feb 06 14:26:56 raspberrypi systemd[1048]: Started pir.service.
Feb 06 14:26:56 raspberrypi systemd[1048]: pir.service: Main process exited, code=exited, status=203/EXEC
Feb 06 14:26:56 raspberrypi systemd[1048]: pir.service: Failed with result 'exit-code'.

Findet Ihr einen Fehler?

[__deets__]

Steht da doch. Das Skript kann nicht ausgefuehrt werden. Ist das denn so genau ausfuehrbar? Also hat es ein shebang und das x-bit ist gesetzt?

[woupi]

Entschuldigung, aber wie ich schon geschrieben habe, habe ich keine Ahnung von Python. Ich weiß nicht wie ich prüfen kann ob shebang und das x-bit ist gesetzt wurde.
Ich habe gerade auch mal danach gesucht, aber auf die schnelle keine Befehle gefunden.

Was ich geprüft habe ist pgrep -f pir.py und anschließend ps -p

Code: Alles auswählen

pi@raspberrypi:~ $ pgrep -f pir.py
6994
6995
6996
pi@raspberrypi:~ $ ps -p 6994
    PID TTY          TIME CMD
   6994 pts/0    00:00:00 sudo
pi@raspberrypi:~ $ ps -p 6995
    PID TTY          TIME CMD
   6995 pts/1    00:00:00 sudo
pi@raspberrypi:~ $ ps -p 6996
    PID TTY          TIME CMD
   6996 pts/1    00:00:00 python3

[__deets__]

Ein shebang ist die Startzeile, und die muss - damit das *ohne* Python davor ausgefuehrt werden kann - so oder so aehnlich aussehen:

Code: Alles auswählen

#!/usr/bin/python3

Und wenn man so ein Skript dann ausfuehren will, muss mit

Code: Alles auswählen

chmod a+x <skript>

die Ausfuehrbarkeit hergestellt werden.

Oder man packt eben python3 davor in der Exec-Zeile, wie du das selbst auch in der Autostart-umgebung gemacht hast.

[woupi]

Ok, es waren die rechte, Danke. Jetzt sieht es so aus.

Code: Alles auswählen

pi@raspberrypi:~ $ systemctl --user status pir
* pir.service
     Loaded: loaded (/home/pi/.config/systemd/user/pir.service; disabled; preset: enabled)
     Active: active (running) since Tue 2024-02-06 15:13:14 CET; 6s ago
   Main PID: 15085 (python3)
      Tasks: 5 (limit: 4442)
        CPU: 119ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/pir.service
             `-15085 python3 /home/pi/pir.py

Feb 06 15:13:14 raspberrypi systemd[1048]: Started pir.service.

Das sieht doch gut aus, oder?

[__deets__]

Es laeuft, ja. Und da sollte auch stehen, wenn's abgeschmiert ist. Und du kannst in der Unit auch noch autmatisch neu starten lassen in dem Fall. Also alles deutlich robuster als das autostart-gefummel.

[woupi]

Vielen Dank.
Ich habe gerade einen reboot gemacht. Das Ergebnis von status ist nun:

Code: Alles auswählen

$ systemctl --user status pir
* pir.service
     Loaded: loaded (/home/pi/.config/systemd/user/pir.service; disabled; preset: enabled)
     Active: inactive (dead)

Wenn ich das richtig verstehe, habe ich mich zu früh gefreut.

[__deets__]

systemd-units kann und muss man enablen, wenn sie automatisch gestartet werden sollen.

[woupi]

Ok, Danke, ja stimmt. Habe ich jetzt gemacht:

Code: Alles auswählen

systemctl --user enable pir

enabled ist er jetzt , aber immer noch Active: inactive (dead).

Code: Alles auswählen

* pir.service
     Loaded: loaded (/home/pi/.config/systemd/user/pir.service; enabled; preset: enabled)
     Active: inactive (dead)

[__deets__]

Hast du danach neu gestartet? Denn ohne das wird der auch nicht gestartet.