Anbindung DoorPi FHEM

  • Habe heute wenig Zeit, diverse Termine.


    Also erst einmal nur als Telegramm, bitte in diesem Rohzustand noch keinen Lexikoneintrag daraus machen.


    Generelle Funktion: DoorPi steuert den Türöffner, FHEM steuert ein eventuelles Verschließen der Tür (z.B. mit einer Keymatic). Die "locked"/"unlocked" Kommandos und weitere Kommandos (z.B. für Licht und Videostream) werden im FHEM-Frontnend nur angezeigt, wenn sie in der doorpi.ini definiert wurden (siehe Punkt 5).


    1. FHEM nach Anleitung installieren. Test: FHEM läuft, Webzugriff unter http://<IP-Adresse>8083/fhem zeigt das FHEM-Logo.


    2. FHEM updaten mit dem Befehl "update" in der FHEM-Kommandozeile.


    3. Auf dem FHEM-Rechner mit den Befehlen

    Code
    sudo cpan JSON
    sudo cpan Test:JSON


    notwendige Module nachinstallieren.


    3. Auf dem FHEM-Rechner das Modul 70_DoorPi.pm manuell aus dem Ordner /opt/fhem/contrib/DoorPi in den Ordner /opt/fhem/FHEM verschieben. Sich bitte einen Device-Namen für das <DoorPi-Device> ausdenken, z.B. "DoorStation"


    4. doorpi.ini muss folgende Events beinhalten. Die tatsächlichen Calls können entweder direkt in der doorpi.ini stehen, oder in einem separaten Shell-Skript

    Code
    [EVENT_BeforeSipPhoneMakeCall]
    10 = url_call:<URL of FHEM>/fhem?XHR=1&cmd.<DoorPi-Device>=set <DoorPi-Device> call start
    20 = take_snapshot
    [EVENT_OnCallStateDisconnect]
    10 = url_call:<URL of FHEM>/fhem?XHR=1&cmd.<DoorPi-Device>=set <DoorPi-Device> call end 
    [EVENT_OnCallStateDismissed]
    10 = url_call:<URL of FHEM>/fhem?XHR=1&cmd.<DoorPi-Device>=set <DoorPi-Device> call dismissed
    [EVENT_OnCallStateReject]
    10 = url_call:<URL of FHEM>/fhem?XHR=1&cmd.<DoorPi-Device>=set <DoorPi-Device> call rejected

    5. doorpi.ini muss über ein virtuelles Keyboard verfügen. Darin können verschiedene actions definiert werden.


    6. Jetzt das FHEM-Device definieren:

    Code
    define DoorStation DoorPi <IP address>

    Wenn es keine Fehler gibt, wird danach die DoorStation-Seite angezeigt, auf der man alle weiteren Einstellungen ganz komfortabel vornehmen kann. Welche Einstellungen das sind, bekommt man angezeigt, wenn man ganz unten rechts auf "Device specific help" klickt.



  • 3. Auf dem FHEM-Rechner das Modul 70_DoorPi.pm manuell aus dem Ordner /opt/fhem/contrib/DoorPi in den Ordner /opt/fhem/FHEM verschieben. Sich bitte einen Device-Namen für das <DoorPi-Device> ausdenken, z.B. "DoorStation"

    Hier beginnen meine Probleme ^^ ich habe keinen Ordner DooPi und finde auch kein Modul
    edit: komme auch nicht mehr ins Webinterface von FHEM. CPU Last ist auch relativ hoch.

  • Wie komme ich an das logfile? Oberfläche kann ich ja nicht erreichen. Update hatte ich vor den JSON Modulen gemacht.
    Ist das schädlich für den Pi dass die CPU so hoch ist? Befehl ist im Anhang


    Edit: logfile auch im Anhang

  • OK, ich hatte nicht daran gedacht, dass der contrib-ordner manuell geupdatet werden muss - das wrde ich in der Anleitung noch ändern müssen. Einstweilen bitte die anliegende Datei in 70_DoorPi.pm umbenennen und in /opt/fhem/FHEM legen.


    Bitte den FHEM-Prozess killen und ihn mit /etc/init.d/fhem start neu starten.


    LG


    pah

  • So bin nun bis zum Definieren des Devices gekommen. Wenn ich in FHEM in der Textzeile define Klingel DoorPi 192.168.178.46eingebe und ENTER drücke, dann kommt " Connection lost, trying a reconect every 5 seconds". Danach komme ich nicht mehr auf die Oberfläche. Wenn ich FHEM stoppe und dann wieder starte, ist aber das Device nicht da.


    Eingetragen in die ini habe ich


    irgendwelche Auffälligkeiten? Log habe ich nochmal angehängt. Danke

  • 1. Um Himmels Willen, bitte nicht eine 50-seitige Logdatei anhängen ! FHEM-Log überschreiben bzw. löschen.


    2. Statt der


    <doorpi action ... >


    Einträge muss in der doorpi.ini natürlich eine echte action drin stehen. Ich nehme an, dass doorpi darüber stolpert und deshalb den leeren Eintrag zurückliefert.


    3. Natürlich muss man vor dem Neustart von FHEM die mit "define ..." erzeugte Konfiguration sichern, sonst ist sie beim Neustart nicht mehr da. Ich hänge mal beispielhaft meine doorpi.ini in einer entschärften Version, sowie mein Helper-Skript an. Achtung, bei mir sind die ganzen doorpi-Sachen in /home/doorpi untergebracht.


    Mein Arbeitstag beginnt, bin erst heute abend wieder da um ggf. Fragen zu beantworten. Also vlt. bei FHEM-Fragen im FHEM-Forum anmelden.


    LG


    pah

  • Habe nun überall erstmal den sleep:0 Befehl dahinter geschrieben und es läuft erstmal. Außer bei den folgenden steht:

    • [file_InputPins]
    • dooropen = out:Tueroeffner,1,0,1
    • doorlocked = sleep:0 (hier soll keine Aktion ausgeführt werden, sondern nur den Status in FHEM sehen)
    • doorunlocked = sleep:0 (hier soll keine Aktion ausgeführt werden, sondern nur den Status in FHEM sehen)

    Wenn ich meine Tür zuziehe dann ist sie sozusagen verriegelt, da 2 Riegel in die Fallen gehen und sich auch nicht mehr zurückdrücken lassen, außer innen mit dem Drücker oder mit dem Schlüssel, deswegen brauche ich die lock und unlock Funktion im dem Sinne nicht. Ich habe einen Reedkontakt am Input 4 des PiFaces.


    Ich würde gern einen Grundriss auf dem Tablet machen wo ich optisch auch sehe, ob die Tür auf oder zu ist und wo ich ggf. sie auch öffnen kann. Da wäre zwar erstmal nur die Tür zu sehen, aber falls ich irgendwann FHEM doch noch verstehen sollte, kommt da sicher nochwas hinzu. Im Moment verstehe ich nämlich noch nicht wie DoorPi mit FHEM interagiert bzw wo da der Mehrwert liegt.


    So nun meine Fragen.

    • Gibt es etwas womit ich den Grundriss aufs Tablet bekomme mit den beschriebenen Funktionen?
    • Wie sähe der Befehl hinter doorlocked und doorunlocked aus bzw geht das überhaupt so?
    • Kann ich über FHEM die Tür auch öffnen? Wenn ja wie?

    Es klingt sicher sehr unbeholfen, aber ich stehe ja noch am Anfang. Danke

  • Zu 1: Ja, recherchiere bitte unter "Floorplan" "FHEM"
    Zu 2: Die virtuellen (von FHEM bedienten) Inputpins doorlocked und doorunlocked schalten bei mir den realen Outputpin hardlock ein oder aus => dient als Signal an meinen Arduino


    Zu 3: Natürlich - ich bediene mit FHEM einfach den virtuellen Inputpin dooropen, der wiederum schaltet den realen Outputpin door für 3 Sekunden auf Low.


    Aus diesem Grunde fragt ja das FHEM-Modul beim Start die Konfiguration von doorpi ab - und meckert z.B., wenn dooropen nicht als virtueller Inputpin definiert wurde.


    Also Kommuniukation FHEM -> DoorPi über diese virtuellen Inputpins = webservice-Keyboard in der doorpi-Sprache


    Kommunikation DoorPi -> FHEM durch URL-Aufrufe (entweder direkt, oder im Helper-Skript via curl).


    LG
    pah

  • Dank dir erstmal @pahenning . Kannst du mir nochmal aus der Klemme helfen? Das Funktionsprinzip ist mir zumindest jetzt klarer. Nur direkt mit dem Webinterface komme ich noch nicht ganz klar. Wenn ich (im Anhang) auf set drücke sollte sich die Tür öffnen? Das hatte nämlich nicht geklappt als ich das gedrückt habe. Leider ist mein Englisch auch nicht das beste, weil du ja eigentlich alles erklärt hast bei device specific help. Bei lockstate und door steht auch unknown. Speziell bei dooropencmd, doorlockcmd und doorunlockcmd weiß ich nicht was ich für Werte eintragen soll. Theoretisch brauche ich ein Bilderbuch(bebilderte Anleitung) :saint: Wird wohl noch ne Menge Arbeit ^^

  • Also das mit der Menge Arbeit war auf mich bezogen. :) Sollte nich heißen dass ich erwarte das du sowas erstellst. @pahenning Hast du schon mal ne Antwort was in die cmd Felder eingetragen werden muss?


    Edit: habe übrigens nach jedem reboot wieder 100% Auslastung :( und muss den Prozess killen und neu starten...