Beiträge von Pmike

    Hallo Nea,
    danke für den Tipp. Leider funktioniert es damit auch nicht, oder ich mache etwas falsch.


    Zum Log: Ich habe zuerst OnCallIncoming ausgelöst und ungefähr eine Minute nachdem der Anruf abgebrochen wurde, habe ich OnKeyPressed_onboardpins.20 ausgelöst und das Script hat seine Aufgabe erledigt.



    Das sudo habe ich bei dem Versuch gleich mit entfernt. Der Eintrag in der INI ist somit:
    [EVENT_OnCallIncoming]
    1 = sleep:1
    2 = os_execute:!BASEPATH!/scripts/runomx.sh
    3 = out:power_supply,1



    Den zweiten funktionierenden Eintrag habe ich belassen:
    [EVENT_OnKeyPressed_onboardpins.20]
    1=call:**620
    3=os_execute:!BASEPATH!/scripts/runomx.sh


    Anbei das Log, mit der Hoffnung auf Hilfe.
    VG
    pmike


    Off-Topic: Ich dachte, wenn ich ein Thema abonniert habe, bekomme ich eine Mail, sobald jemand etwas darin schreibt. Falsch?

    Danke für den Tipp mit der Pfadvariablen. Auch der vollständige Pfad bringt keine Änderung.
    Ohne sudo ist das Ergebnis das Gleiche. Ich hatte ein Rechteproblem vermutet.


    Das Script funktioniert immer auf der Konsole und auch beim OnKeyPressed_onboardpins.20 Event. Allerdings nicht beim OnCallIncoming Event für den identischen Aufruf. Was soll der Ort der Ablage des Scripts daran ändern? Bei mir läuft der DoorPi unter dem pi-Account und da hatte ich die Scripte vorher, ähnlich wie du, im Homeverzeichnis. Wo sie jetzt sind, ist schon einer der Versuche, die Lösung zu finden.


    Ich vermute deshalb ein Problem mit Rechten, da durch die Kombination von so vielen Komponenten wie Python Runtime, Linphone, GPIO Steuerung etc. doch einige Prozesse gestartet werden, die sich auch in ihren Rechten beschränken dürfen, aber nicht zwingend die Rechte erweitern können.

    Hallo,
    ich habe ein merkwürdiges Verhalten und bitte um Hilfe, da ich vielleicht den Wald vor lauter Bäumen nicht sehe. Meine INI reagiert u.a. auf zwei Events:


    Die Doorpi-Version ist laut changelog.txt 2.4.1.8.


    [EVENT_OnCallIncoming]
    1=os_execute:sudo !BASEPATH!/scripts/runomx.sh
    2=out:power_supply,1


    [EVENT_OnKeyPressed_onboardpins.20]
    1=call:**620
    3=os_execute:!BASEPATH!/scripts/runomx.sh


    Die Reihenfolge der Befehle spielt keine Rolle, alles getestet. Drücke ich die Taste (Pin 20), erfüllt das Script seinen Zweck. Kommt der Call, wird nur das Netzteil mit dem zweiten Befehl aktiviert.
    Hat irgendjemand eine Idee oder ähnliches erlebt?


    Wer vermutet, das Script spielt inhaltlich oder rechtetechnisch eine Rolle: Fehlanzeige, denke ich. Selbst mit sudo keine Chance, trotzdem hier der Inhalt:


    #!/bin/bash
    #
    #
    logfile=../log/omx.log
    # Stellt sicher, dass omxplayer immer wieder gestartet wird.
    if [ $(ps -A | grep -c omxplayer) = 0 ];
    then
    echo "$(date) omx wiederbeleben" >> $logfile
    omxplayer --fps 15 --live --threshold .01 --video_fifo .01 http://172.30.1.46:8080/stream/video.mjpeg local & disown 1>/dev/null 2>/dev/null
    echo "$(date) omx ende" >> $logfile
    fi
    exit


    Wäre toll, wenn jemand helfen kann. :)


    Danke
    pmike

    Zunächst mal muss ich sagen: Super Projekt und super Forum! Respekt!
    Dazu noch die Erlösung von meiner teilweise defekten Anlage des Vorbesitzers mit Baujahr '78 (Siemens Italien). Und ich konnte ohne Geld an die Klingel-Mafia einfach nur das Innenleben ersetzen und das Retro-Gehäuse erhalten. :)


    Da bei mir und vielleicht auch bei Anderen die Distanz zwischen Innen- und Außenstation mehr als 10m Kabellänge beträgt, wird es schwierig für Bild und Ton, egal ob I2C oder SPI, denke ich.


    Ich habe das bei mir so gelöst, dass ich einen "Internen" und einen "Externen" DoorPi installiert habe. Bin gerade in der produktiven Testphase. Der Innere ist praktisch nur ein SIP Phone mit Audio und einem Analog-LCD-TV und zwei Tasten für Gesprächsannahme und Türöffner.


    Dabei arbeite ich teilweise mit den Eventauslösern über das Web-Interface zwischen den beiden, um Anpassungen zu vermeiden, die ein Update behindern. Funktioniert alles prima, wenn man richtig liest & sich nicht vertippt. ;)
    Das Schöne für mich, ist der Umstand, dass ich nicht Python lernen muß und das Trace schnell die Fehler aufzeigt.


    Toll wäre daher für mich, wenn man den "Internen" per ini so konfigurieren könnte, dass er nicht automatisch abhebt bzw. über die ini konfiguriert mit dem anderen Daten, Stati etc. austauschen kann. Man will ja nicht zur Tür rennen, wenn man auf dem Telefon auch abheben kann. ;)


    Da ich den Zero nicht kenne, weiß ich nicht, ob das hier vielleicht eine Option ist: RPi innen und außen mit Zero oder Full-RPi als Konfig-Option.


    Liebe Grüße
    pmike