Posts by swissflyer

    Danke dir für deine Recherche und den Watchdog-Hinweis.


    Habe am Nachmittag den Crontab-Job für heute Abend eingerichtet und er ist sauber durchgelaufen. Nun setze ich die Zeiten für Morgen nochmals auf die finale Einstellungen und wenn das auch positiv verläuft, dann ersetze ich die Zeituhren durch den Pi.


    Wenn der Pi dann seine Einsatzzeit hinter sich hat, werde ich einmal versuchen, den Vorschlag von Jürgen umzusetzen (die Ein-/Ausschalt-Befehle via Shell-Script zu lösen).

    pilight hat doch auch eine Konfigurationsmöglichkeit bzgl. der Überwachung durch den hardware-watchdog, oder? Ist das standardmäßig aktiviert? Wenn ja, dann mal deaktivieren.

    Man kann offensichtlich einen watchdog mittels folgender Eingabe in der config.json starten:

    Code
    { "watchdog-enable": 1 }
    
    pilight monitors its own CPU and RAM resource usage. This information is used to shutdown or terminate pilight when it uses too much CPU or RAM. If want to disable this watchdog feature and therefor the automatic termination of pilight when needed, you can set this setting to 0. This setting can be either 0 or 1.

    Ich habe diesen Eintrag nicht in meiner json-Datei. Daher gehe ich davon aus, dass der Watchdog auch nicht läuft.




    Ausgabe von ls -la /dev/watchdog*:

    Code
    crw------- 1 root root  10, 130 Dez 22 16:07 /dev/watchdog
    crw------- 1 root root 251,   0 Dez 22 16:07 /dev/watchdog0


    Ausgabe von free -m:

    Code
            total    used    free    shared    buff/cache    available
    Mem:      926     144     537         6           243          720   
    Swap:      99       0      99


    Ausgabe von top -n 2 -d 4 | grep -i pilight:


    Code
      656 root     -81   0  121380  11904   7828 S   0.2   1.3   0:02.92 pilight-daemon

    Das kann es doch nicht sein (!) – jetzt habe ich den Pi mal heruntergefahren und vom Strom getrennt, wieder eingesteckt, neu gestartet und jetzt funktionieren die send-Befehle wieder.


    Jetzt funktioniert auch der komplette crontab-Job auf einmal wieder... Aber wie soll ich ein solches System 2,5 Wochen unbeobachtet laufen lassen?! Da kann ich nicht einmal garantieren, dass das einen Tag normal läuft.

    Evtl. mal auch mit tcpdump nach schauen, was bei Lichter an und was bei Lichter bleiben aus, über den Port 5000 geht: Code
    sudo tcpdump -c 100 -vvveni lo port 5000

    Habe ich gemacht:


    Send-Befehl "EIN":



    Send-Befehl "AUS":

    .... ob Du die pilight daemons mit einer Option (-D oder gleichwertig) für den debug-Modus starten kannst.

    Ja, das gibt es:


    https://manual.pilight.org/programs/debug.html

    https://manual.pilight.org/programs/daemon.html


    sudo pilight-daemon -D gibt allerdings keinen einzigen Fehler aus.


    Einen Hardware-Defekt kann ich auch ausschliessen. Der Empfänger (Steckdose) reagiert auf die Eingaben mit der Funk-Fernbedienung und den Sender am Pi habe ich ebenfalls bereits testweise durch einen anderen (identischen) ausgewechselt.


    Wenn Du es nicht weißt, dann kannst Du den avahi-daemon deinstallieren. Denn bei einem PI der nicht mit einem Netzwerk verbunden ist brauchst Du den avahi-daemon keines Falls.

    Der Pi soll nach der Aktion über Weihnachten/Neujahr wieder in meinem Heimnetzwerk sein, daher muss ich den avahi-daemon wohl behalten.



    D. h. es wird eine crontab des users pi sein, oder? Wenn Du sudo brauchst dann solltest Du besser eine root-crontab für die Befehle mit root-Rechten benutzen und eine pi-user-crontab für die Befehle ohne root-Rechte. Oder Du benutzt die systemweite crontab, in der Du den user eintragen musst. BTW: systemweit ist nicht systemeigen.

    Da bin ich jetzt ehrlich gesagt etwas überfragt... Ich editiere die crontab (mit dem normalen Pi-User) mittels "crontab -e", daher gehe ich davon aus, dass es die Pi-user-crontab ist. Diese funktioniert ja auch, sonst würde die Musik nicht beginnen zu spielen. Das sudo vor dem pilight-restart-Befehl habe ich nur eingefügt, weil ich das im normalen Terminal ebenfalls benötige.

    Sind in diesem Fall, die Lichter auch dunkel geblieben?

    Ja, die Befehle funktionieren nicht mehr (auch nicht wenn ich sie normal im Terminal eingebe). Da auch keine Fehlermeldung mehr auftritt, weiss ich auch nicht wo ich nun nach Problem suchen soll?


    BTW: Brauchst Du den avahi-daemon auf deinem PI?

    Da ich nicht weiss, für was dieser zuständig ist – kann ich dir die Frage leider nicht beantworten.



    EDIT:

    Jürgen Böhm Danke für deinen nützlichen Beitrag. Ich bin eigentlich auch eher ein Fan von "sauber" Arbeiten – wenn die von dir vorgeschlagene Variante dem entspricht (was es sicherlich tut) werde ich das dann auch einmal versuchen so umzusetzen. Momentan sind aber die pilight-send-Befehle wirkungslos und das muss ich zuerst wieder irgendwie korrigieren können. Alles was ich da zwischenzeitlich anpasse/ändere ist nur eine weitere mögliche Fehlerquelle.


    EDIT2:

    pilight status ist übrigens in Ordnung (loaded und active/running).

    Wie ist noch vor 13:38 Uhr, die Ausgabe von: Code
    sudo netstat -tulpena

    Musste ich nochmals kurz durchspielen: Zum erwähnten Zeitpunkt (kurz nachdem die Musik gestartet is) sieht die Ausgabe davon wie folgt aus:


    Ist der absolute Pfad für mpc richtig (mit /mpc)?

    Hier nun der (Test-)Inhalt meines Cronjobs:


    Code
    29 13 * * * sudo service pilight restart
    30 13 * * * /usr/local/bin/pilight send -S 127.0.0.1 -P 5000 -p mumbi -s 7 -u 2 -t
    31 13 * * * /usr/bin/mpc play 1
    38 13 * * * /usr/bin/mpc stop
    39 13 * * * sudo service pilight restart
    40 13 * * * /usr/local/bin/pilight send -S 127.0.0.1 -P 5000 -p mumbi -s 7 -u 2 -f

    Die Musik spielt - die Lichter bleiben dunkeln. Letzters ist aber klar, da auch die normalen Eingaben im terminal nicht mehr funktionieren und ich hab mal wieder keine Ahnung was jetzt nicht mehr läuft (erhalte auch keine Fehlermeldung mehr).

    Ups – die beiden Slashes vor mpc sind mir reingerutscht (die sind auf dem Pi nicht enthalten). Aber du hast natürlich recht, dass dies keine absoluten Pfade sind (suche ich noch heraus, weiss diese gerade nicht).


    Mit der Musik hatte ich im Übrigen nie Probleme, das lief immer sehr zuverlässig und war auch letztes Jahr bereits im Einsatz.


    Betreffend deinem Vorschlag: Das habe ich auch schon probiert- aufgrund der Möglichkeit, dass nicht exakt zur gleichen Zeit zwei Befehle aufgegeben werden können. Es ist etwas Schade, dass man mit Crontab keine Sekunden festlegen kann.

    Ja, es gibt einen Unterschied und man sollte für einen cronjob immer absolute Pfade verwenden.

    ok – Danke für den Input.


    Zurzeit funktionieren mal wieder gar keine send-Befehle - ärgerlich. Es erscheinen aber auch keine Fehlermeldungen mehr. So etwas kann ich nicht unbeaufsichtig laufen lassen.


    Mein crontab-job sollte später eigentlich so aussehen:


    Code
    00 17 * * * /usr/local/bin/pilight send -S 127.0.0.1 -P 5000 -p mumbi -s 7 -u 2 -t
    00 17 * * * /mpc play 1
    00 22 * * * /mpc stop
    00 22 * * * /usr/local/bin/pilight send -S 127.0.0.1 -P 5000 -p mumbi -s 7 -u 2 -f


    Zusätzlich habe ich aber aber auch noch eine pilight_restart.timer welche den Pilight-Dienst 45 Sek. nach dem Neustart nochmals neu startet (das hat mit angeschlossenem Router dann funktioniert, jetzt scheint es aber ohne diesen auch keine Auswirkungen mehr zu haben).

    Ja, wenn ich das mal früher gesehen/gelesen hätte... Das hätte mir einiges an Zeit und Nerven gespart.


    Das Netz ist voll mit Beiträgen über diesen SSDP-Fehler – und ich habe etliche davon gelesen und in keinem davon kam dieser Hinweis. Alle haben versucht, wie ich/wir ja auch, Ip-Regeln oder die Schnittstelle anzupassen.


    ----


    Um was ich zurzeit nicht herumkomme, ist ein sudo service pilight restart auszuführen, bevor die pilight-send-Befehle gesendet werden. Zudem scheinen die Send-Befehle nicht wirklich sauber zu funktionieren – teilweise muss ich die Befehle zwei-/dreimal senden, bevor die Dosen schalten... Das ist natürlich nicht optimal.


    ----


    Frage: Spielt es eine Rolle ob man im Cronjob-File mit absoluten Pfadangaben arbeitet oder nicht? Oder konkret: Gibt es hierbei einen Unterschied:


    /usr/local/bin/pilight send -S 127.0.0.1 -P 5000 -p mumbi -s 7 -u 2 -t

    und

    pilight send -S 127.0.0.1 -P 5000 -p mumbi -s 7 -u 2 -t

    Meine Güte – ICH HABs...


    Der Standalone-Eintrag in der config.json ("standalone": 1,) macht zusätzliche Anpassungen notwendig.


    Da mit diesem Standalone-Eintrag (1) der SSDP abgeschalten wird, muss man nun dem "pilight-send"-Befehl manuell hinzufügen wo der Deamon zu finden ist. Dafür musste ich zuerst im json-File den Eintrag "port": 5000, ergänzen und anschliessend den pilight-send-Befehl wie folgt ausführen:


    pilight-send -S 127.0.0.1 -P 5000 -p mumbi -s 7 -u 2 -t


    und voilà: Ohne angeschlossenen Router klappt das nun! Ich hau mich jetzt hin...

    Ist das eine Fehlermeldung oder lediglich ein Hinweis von pilight?

    Die Meldung wird als Hinweis ausgegeben – aber im Grunde genommen ist es ein Fehler, weil ja der gewünschte Befehl dadurch nicht ausgeführt wird.


    Im ganzen heisst die Meldung:

    (/home/pilight/source/daemon-dev/send.c #331) [Dec 21 22:08:27:606339] NOTICE: no pilight ssdp connections found

    Schreibe in die Network-Section auch die Zeile: Code
    LinkLocalAddressing=no

    damit das eth0-Interface sich keine LL-IPv4-Adresse zuweist. Dann sollte das eth0-Interface ohne Kabelverbindung, immer "off" sein.

    Habe ich nachgeholt und auch getestet – das Ergebnis ist leider unverändert geblieben...


    Irgendwie muss man doch diesem doofen Pilight diese SSDP-Abfrage unterbinden können.

    Ja, Du kannst die bestehende eth0.network-Datei verändern

    Wenn ich das richtig gelesen habe, genügt mir eigentlich folgender Inhalt der eth0.network:


    Code
    [Match]
    Name=eth*
    
    [Network]
    DHCP=yes

    Aber genügt das wirklich schon? Wird in diesem Falle nur eine IP-Adresse vergeben, wenn das Lan-Kabel angeschlossen wird? Oder vielleicht besser gefragt: Ist eth0 vor dem Verbinden mit einem Lan-Kabel wirklich "off"?



    EDIT: Habe es mit obiger eth0.network-Datei probiert -> Pi heruntergefahren, Lan-Kabel getrennt und neu gebootet. Beim Ausführen des Pilight-Befehls habe ich nun wieder den SSDP-Fehler NOTICE: no pilight ssdp connections found


    Wenn ich das LAN-Kabel dann wieder einstecke, bekomme ich meine IP-Adresse zugewiesen. Pilight funktioniert dann aber erst nach einem "sudo service pilight restart" wieder (wahrscheinlich weil es die Infos vom Netzwerk erst wieder neu erfassen muss).

    Das müsste man testen, denn per DHCP wäre es ja so, dass das eth0-Interface des PI schon beim booten down wäre und keine IP-Adresse hat.

    Ok – dann ist es wohl einen Test wert...


    Quote

    ... und der DHCP-Client wird ja auch nur dann aktiv wenn eine Kabelverbindung zum Router/DHCP-Server vorhanden ist. D. h. wenn Du den PI, nicht via eth0-Interface erreichen musst, wird dem eth0-Interface auch keine IP-Adresse zugewiesen.

    Kann man das dann ebenfalls in der eth0.network-Datei festlegen/definieren oder braucht es weitere Dateien oder gar zusätzliche Software?

    Was genau meinst Du mit abgeschaltetem eth0-Netzwerk? Lediglich keine Kabelverbindung am eth0-Interface (mit einer zugewiesenen IP-Adresse) oder ein eth0-Interface ohne zugewiesene IP-Adresse (d. h. down) und ohne Kabelverbindung?

    Habe das eth0-Interface mit sudo ifconfig eth0 down abgeschalten -> dann resultiert bereits der SSDP-Fehler beim versenden der Pilight-Befehle (egal ob der Router dann noch per Lan-Kabel angebunden ist oder nicht).



    BTW: Das mit dem dhcp-Client für das eth0-Interface wäre ja nur eine temporäre Konfiguration (für die Dauer der Tests) und der DHCP-Client wird ja auch nur dann aktiv wenn eine Kabelverbindung zum Router/DHCP-Server vorhanden ist. D. h. wenn Du den PI, nicht via eth0-Interface erreichen musst, wird dem eth0-Interface auch keine IP-Adresse zugewiesen.

    Frage: Wenn das so umgesetzt würde, bringt das dann dem Pilight irgendetwas (da dieses ja unbedingt eine Antwort via eth0 haben möchte)?

    Vorgestern Abend blieb die Beleuchtung aber aus. Receiver gecheckt, der Befehl wird gesendet.

    Vorhin vor Ort gewesen, den Sender etwas anders plaziert, die Funksteckdose um 180° in der Mehrfachsteckdose gedreht, derselbe Platz.

    Die Dose schaltet wieder. Manchmal habe ich das Gefühl, das der Sender einfach nur Sch**ße ist.

    Ja das ist wirklich mühsam. Vorallem habe ich keine Chance von extern die Anlage zu überwachen (da vor Ort kein LAN/WLAN zur Verfügung steht). Der Pi steht ein paar Dörfer weit weg, da kann ich nicht jeden Tag hinfahren um zu schauen, ob die Lichter brennen (dann kann ich die gleich von Hand anschalten) – daher brauche ich schon eine Lösung die auch funktioniert...

    Versuch es mal, mit einem eth0-Interface, das down ist


    Ein abgeschaltenes eth0-Netzwerk funktioniert leider nicht – habe ich bereits probiert gehabt, da taucht dann wieder der SSDP-Fehler auf. Dies wohl deswegen, da dann pilight gar keine Antwort mehr von eth0-Netzwerk bekommt. Wie bereits geschrieben ist hier der Standalone-Eintrag buggy -> deshalb haben auch so viele ihre Probleme damit.


    DHCP kann/soll ich nicht verwenden, da dies offensichtlich Probleme mit meinem anderen AdHoc-Netzwerk geben kann (siehe dein Beitrag hier: *Klick*).

    Wird diese IP-Adresse immer zugewiesen oder nur dann, wenn der PI per Kabel mit dem Router verbunden ist (d. h. per dhcp)?

    In der network-Datei steht DHCP=no. Ich verstehe aber nicht, worauf du mit dieser Frage hinaus willst? Wenn ich es richtig verstehe, wird einfach für die eth0-Schnittstelle immer die in der network-Datei angegebene IP-Adresse verwendet (192.168.1.110/24)


    Hinweis (keine Ahnung ob das gut ist oder nicht): In der eth0.network-Datei steht unter Neighbor nochmals die IP-Adresse des Heimnetz-Routers, sowie dessen MAC-Adresse.



    EDIT: Der Input betreffend network-Datei habe ich ebenfalls von dir erhalten. Siehe hier: IBSS-Network (AdHoc) mit systemd + wpa_supplicant