Beiträge von sgaechter

    Hallo Gonzo.
    Wie gewünscht, das Script mit while True- Schleife

    Ungetestet, aber sollte klappen.


    Habe auf Zeile 66 noch die Sicherheit etwas erhöht. Nun muss ein Finger einen Übereinstimmungs-Score von 70 haben, dass die Türe auf geht. Kann natürlich auch wieder angepasst werden. :-)


    Gruss
    Sven

    Hallo,


    konnte das Projekt soweit umsetzten.
    Was mir nur nicht so recht gefällt das man das script finger.py immer mit einem Befehl starten muss.
    Gibt es keine Möglichkeit das der Fingerprint die ganze zeit aktiv ist?


    Gruß Bernd

    Hallo Bernd.


    Ja, du kannst den Leser die ganze Zeit an lassen, sofern dich das ständige Geflacker des Lesers nicht stört.


    Starte das Sceipt bwim Start von Doorpi oder bau' dir einen Service,
    Packe den gesamten Code des Scripts “finger.pi“ ab
    “## Tries to search the finger and calculate hash“
    in eine “while True:“ Schleife und entferne die While-Schleife “while time.time() > t_end and“ und lass den Rest stehen. Schon macht der Leser was du willst.


    Ich bastle noch immer am entsprechenden Keyboard, doch bin ich noch nicht so weit, wie ich sein möchte...
    Gruss Sven


    Gesendet von meinem BAH-W09 mit Tapatalk

    Hallo Korky.
    Danke, du hast mir gerade die Landebahn geebnet.
    Alex01 : SIP braucht in der Tat noch mehr Ports für die Kommunikation. Vor einem Jahr musste ich im Geschäft die Firewall austauschen und da musste ich neben 5060 auch noch den Range 30000 - 30005 eingehend auf unsere PBX freigeben.
    Kurz gegoogelt und gefunden: hier ist alles recht schön beschrieben: https://www.tecchannel.de/a/vo…ner-nat-firewall,433069,6
    Ich hoffe das hilft dir nun weiter.


    Da ich persönlich kein Freund von eingehenden Portweiterleitungen auf Geräte im Heimnetz bin, würde ich für den DoorPi eine DMZ oder ein VLAN bauen. Aber das überlasse ich jedem wie er will.


    Gesendet von meinem BAH-W09 mit Tapatalk

    Hallo Alex01.


    Was genau meinst du mit "Dann passiert aber nichts und nach ca. 10 Sekunden löst es aus." ?
    Kommt keine Sprachverbindung zustande?
    Funktioniern denn dein Mikro und der Lautsprecher am Pi?
    Events für den einkommenden Rufaufbau brauchts keine. Ausgehend muss das natürlich irgendwas triggern, aber das weisst du ja sicher.


    Meine DoorPi.ini ist umfangreich und hat noch Kommunikation mit meiner Hausautomation drin, aber wenn du meinst, damit was anfangen zu können, dann hier:

    Verwendung auf eigene Gefahr und ohne Supportanspruch meinerseits 8)



    Gruss
    Sven

    Hallo Kunstflieger.
    Wie sieht dein Setup aus?
    -nutzt du die GPIo's für die Klingelknöpfe, oder Piface?
    -wie lang sind die Drähte?
    - ziehst du das Potential runter beim drücken der Knöpfe, oder hast du sie einfach 3v - - - > Input an geklemmt?



    Hatte ähnliches mal, weil mein Klingelknöpfe zu heiss bekam (Sonnenseite). Danach machte der ganz "lustige" Zustände.


    Gruss
    Sven

    Hallo Alex01.


    Eingehend ist dein Problem wohl, dass du die Anrufer Nummer nicht in der Config hinterlegt hast. DoorPi nimmt nur Anrufe von Admin-Nummern entgegen. Da musst du folgende Einträge in die Doorpi.ini aufnehmen:



    Code
    1. [AdminNumbers]
    2. +49160xxxxxxx@ims.telekom.de = Active

    wobei ich mir nicht sicher bin, ob der CLIP so stimmt. unter Umständen kannst du das hinter dem "@" weglassen. Am besten probierst du mal aus.


    Beim ausgehenden Call scheint dein angerufenes Gerät ein Problem zu haben. Der 606er bedeutet:



    Code
    1. 606 Not Acceptable Das Endgerät des angerufenen Teilnehmers lehnt die SIP-Anfrage als unzulässig ab


    Probier doch mal eine Verbindung DoorPi ---> Handy. Da hast du das codec-gedusel schon mal ausgeblendet.


    Hier noch meine Einstellungen, wie ich sie in meiner DoorPi schon zwei Jahre problemlos nutze:


    Vier Erfolg beim weitertüfteln.


    Gruss
    Sven

    Hallo Forumgemeinde.
    Ich möchte gerne den Staus seines in DoorPi definierten Ein- bzw Ausgangs über HTTPGET abfragen. Ich stelle mir das in etwa so vor:


    Mit dem keyword "query_output" oder Wahlweise "query_input" anstatt "trigger_event"......


    Code
    1. http://doorpi:8080/control/query_output?output_name=doorpi.Tueroeffner&output_source=doorpi.keyboard.from_piface

    ..... würde ich gerne folgendes zurück erhalten:



    Code
    1. {
    2. "message": "query Output was success",
    3. "status": true # wenn offen / false wenn geschlossen
    4. }


    Somit könnte ich meine externen Komponenten (Hausautomation) besser an Doorpi anbinden. Aktuell sende ich aus DoorPi HTTP-Requests an die Geräte, wenn der Staus wechselt. Das hat aber in der Vergangenheit schon öfters nicht geklappt, darum möchte ich es gerne umdrehen und den Staus der Doorpi-Ins und Outs abfragen, bevor ich Aktionen in der Hausautomation ausführe.


    Gibt's eine solche Möglichkeit schon?


    Vielen Dank für die Feedbacks.

    Hallo Pula. Kannst du mir sagen wo ich die Doku und ein Verdrahtungsbeispiel dazu finde? Bin auf I2c nicht so fit.


    .. Fällt mir gerade ein: dann kann ich die USB Anbindung für meine Soundkarte, die auch in der Aussenstation an einem Mini USB- Hub hängt wohl vergessen.... Doch wieder 2 Strippen...

    Hallo Snoopylix
    Bei der FB 7490 gibts pro Anrufbeantworter zwei Aufnahmemöglichkeiten. Einerseits den klassischen AB mit der Nummer **600: hier kann ein interner Anrufer kein Memo hinterlassen, da direkt die AB Ansage intern ertönt. Aber ein Memo hinterlegen ( beim ersten AB ist es die Nr. **605) geht mit einer internen Nummer. Ob es diese Option bei der 7270er auch schon gab, weiss ich leider nicht (mehr). Die 7390er hatte die Funktion schon.
    Was mich jedoch noch etwas stört, ist die Tatsache, dass die Nachricht in jedem Fall so lange aufzeichnet, wie in der doorpi.ini als "max_call_time" hinterlegt ist. Wäre schön, wenn da ein findiger Kopf eine Lösung über das Input level des Mikrosignals finden würde..
    Gruss Sven

    In the doorpi.ini you registered some keyboards to listen ro inputs wether the gpio or piFace? Then you have a section where you register the used ins for example:


    [gpiopins_InputPins]


    1 = call:11
    2 = call:12


    //the command “call:11“ defines the phone you want to call (in this case the number 11), if the input 1 gets pressed.


    Regards sven



    Gesendet von meinem E6653 mit Tapatalk

    Hallo zusammen.


    Bin gerade meine DoorPi am verfeinern. Dabei habe ich mir eine Aussenstation mit einem Arduino NANO und der Soundkarte zusammengebastelt.
    Am Arduino hängen die Klingeltaster, die Photodiode und mein Fingerleser. Von aussen nach innen funktioniert alles prima. Die Klingel Commands werden sauber übertragen, der Fingerleser öffnet meine Tür, Audio passt ohne Hall und Delay's.


    Ich will nun Outputs auf dem Arduino steuern. Der Sketch ist fertig und über Putty funktionieren die Commands sauber und der Ardu macht, was er soll.
    Aktuell habe ich DoorPi 2.5.1 mit dem USB_plain- Keyboard im Einsatz.


    Offensichtlich will aber DoorPi keine Commands abfeuern. Wenn ich einen gebridgeten Arduino an den Raspi und auf der anderen Seite an meinen PC hänge, sehe ich mit Hterm keinen der benötigten Commands.


    Vielleicht kann mir jemand von euch auf die Sprünge helfen.


    Hier der Auszug meiner Doorpi.ini und der Arduino Sketch:


    Und hier noch der Sketch, ab Linie 122 wird's interessand:



    Vielen Dank für die Hilfe.

    Ich habe meinen Fingarabdruckleser des Typs ZFM-20 (auch bekannt als "Arduino fingerprint sensor") an mein DoorPi geklemmt. da es dafür (noch) kein Keyboard gibt, habe ich mir das "virtuelle Keyboard" zu Nutze gemacht um die Freigabe des Fingerabdrucklesers zu implementieren.


    Was es Braucht:

    • Funktionierendes DoorPi, vorkonfiguriert auf Raspberry Pi B+ oder 3 (bei mir ist der 3-er im Einsatz)
    • Fingerabdruckleser des Typs ZFM-20 (ebay, AliExpress...)
    • USB-TTL-Konverter (z.B. mit dem CP2102-Chip) oder einen Arduino Nano mit gebrücktem GND-Rst, so kann dieser als USB-TTL fungieren.
    • wahlweise zwei LED's (grün / rot oder Dual-LED)
    • Kabel, Lötkolben, Widerstände...


    Vorbereitung der Hardware:

    • Fingerabdruckleser in entsprechend sinnvolles Gehäuse packen
    • Ich habe für die initialisierung des Lesevorganges einen Taster auf das Gehäuse gepackt. (zukünftig will ich den Leser anderweitig einbauen und die Auslösung dann über eine Lichtschranke realisieren.)
    • ebenfalls fanden die beiden LED's darauf platz (diese signalisieren den Lesvorgang erfolgreich / fehlerhaft)
    • PiFace Board ist von Vorteil, würde aber auch über GPIO mit entsprechenden Widerständen und Relais-Board funktionieren (war mir aber zu Umständlich)
    • Wie man den Fingerabdruckleser genau anschliesst und wie die Library dafür installiert wird, könnt ihr Bastian Raschke's Webseite entnehmen, da spare ich mir das Wiederkäuen.
    • Anschliessend Fingerleser gemäss Bastian's Anleitung testen.



    Vorbereitung der Software:

    • Die Python-Library für den Fingerabdruckleser hat ebenfalls einige Beispiele mitgeliefert:
    • Mit dem Beispiel "example_enroll.py" können die Finger entsprechend eingelesen werden
    • Das "example_search.py" habe ich entsprechend erweitert, damit das erfolgreiche Lesen eine Aktion in DoorPi auslöst
    • Ich habe das Script abgeändert und in "finger.py" umbenannt. Anschliessend habe ich es unter "/usr/local/etc/DoorPi/scripts/" abgelegt (ausführbar machen nicht vergessen, aber das wisst ihr sicher)

    Der CODE muss an diversen Stellen noch am jeweiligen System angepasst werden. Dies habe ich im Code kommentiert:


    Damit die Events von DoorPi verarbeitet werden können habe ich das "virtuelle Keyboard" aktiviert und mir folgende virtuelle Inputs erstellt (Kommentare mit "//" bitte bei allen folgenden Code's rauslöschen):



    Die virtuellen Inputs lösen die folgenden Events aus:




    EVENT_OnKeyPressed_onboardpins.3:

    • Dieser Event wird vom Input 3 getriggert. Hier hängt der Taster zum starten des Fingerlesevorgangs dran


    EVENT_OnKeyPressed_onboardpins.4

    • Minimale Sicherheit: Wenn jemand das Lesergehäuse vor der Haustür öffnet, werde ich über das Script "sabotage.sh" via Telegram informiert, anschliessend stoppt DoorPi und nichts geht mehr (Vorsicht, In diesem Fall braucht's noch einen Schlüssel oder einen ssh-Zugang auf die DoorPi um neu zu starten).


    EVENT_OnKeyPressed_webservice.dooropen:

    • Dieser Event wird von "finger.py" angestossen, wenn der Lesevorgang erfolgreich war
    • Zugleich wird die grüne LED für 3s. eingeschaltet (zeigt den erfolgreichen Lesevorgang an)


    EVENT_OnKeyPressed_webservice.redled:

    • Dieser Event schaltet die rote LED, wenn der Lesevorgang zu lange kein Ergebnis bringt (der Vorgang bricht nach 10s ab), oder der vorgehaltene Finger nicht verzeichnet ist.


    Wenn dann alles aufgebaut ist, kann mittels Knopfdruck der Lesevorgang gestartet werden: Ist der Finger korrekt, wird die Türe freigegeben.



    Das System hat noch einige leaks, so sind teilweise Wartezeiten zwischen Knopfdruck und Lesevorgang (der Leser wird zuerst initialisiert) sowie nach Abschluss des Lesevorgangs bis zum öffnen der Tür in Kauf zu nehmen.

    • Das hat mit dem Verarbeiten der Events zu tun. Je nach dem was DoorPi sonst noch treibt, geht's schneller.
    • Dieser Tatsache könnte mit einem DoorPi-Keyboard sicher abgeholfen werden - Leider reichen meine Python-Kenntnisse dafür (noch) nicht aus


    Zum Thema Sicherheit ist vorweg zu nehmen, dies ist ein Experimental aufbau! Bitte nicht bei der nächsten Sparkasse verbauen :)

    • Tauscht jemand den Leser mit einem baugleichen Modell mit vorgespeicherten Fingern, kann die Tür problemlos geöffnet werden. Deshalb habe ich den Sabotagekontakt vorgesehen.
    • Hier würde das Speichern und Abgleichen des Hash's, welcher die Library anbietet, entgegenwirken. Da hänge ich mich dann mal dran.


    Kritik und Verbesserungsvorschläge sind willkommen. :)

    Dateien

    • finger.zip

      (1,36 kB, 141 Mal heruntergeladen, zuletzt: )

    Nun habe ich endlich eine DoorPi- interne Lösung für mein Dauertüröffnerproblem gefunden:


    Mittels Events, welche den Status des Eingangs abfragen, habe ich es hingekriegt:




    Code
    1. [EVENT_OnKeyPressed_onboardpins.2]
    2. 10 = out:Tueroeffner,1,0
    3. [EVENT_OnKeyUp_onboardpins.2]
    4. 10 = out:Tueroeffner,0,1
    5. [onboardpins_InputPins]
    6. 2 = sleep:0

    Was das Ding macht:
    - Mit dem ersten Event schalte ich den Ausgang dauerhaft auf Ein, wenn der Eingang "HIGH" ist.
    - Mit dem zweiten schalte ich den Eingang wieder aus, sofern der Eingang wieder "LOW" ist.
    - Der Inboardpin muss natürlich initialisiert werden. Da er aber sonst (noch) keine Aufgabe hat, deklariere ich ihn mit "sleep:0"


    Emprovement's:
    Der zweite Event hat bei mir ca. 5 Sekunden Verzögerung, damit kann ich aber leben.
    Allenfalls liegt's auch dran, dass ich denselben Pin mit 10 s Verzögerung beim Öffnen der Tür über DTMF nutze..

    Hallo Ruhri.


    Dein Ansatz war schon mal gut, jedoch schaltet der Ausgang nie mehr aus, auch wenn der Eingang längst geöffnet ist. Der Ausgang wird erst zurückgestellt, wenn der Ausgang über einen anderen Event erneut geschaltet wird (Türöffner-Event über DTMF). Toggeln funktioniert leider nicht. Werde es wohl über ein externes Script lösen müssen.
    Danke für's mitdenken.

    Lies bitte den Thread 1 in aller Ruhe durch. Ich habe nichts davon geschrieben, dass der “Eingang geschlossen ist, und der Ausgan gröffnetwerden soll...
    Lediglich: while Input1 true --> output 1 true and output 2 blink.


    Wenn das DoorPi nicht kann, reicht mir diese Info. Dann löse ich es über ein Script ausserhalb DoorPi.

    Hallo zusammen.


    Ich möchte an meiner Haustüre, welche mit einem Türöffner im Rahmen ausgerüstet ist, eine Daueröffnung realisieren. Der Öffner ist auf Dauerspannung ausgelegt, der hält das somit aus. Aktuell habe ich dafür einen Arduino (wo auch der Fingerleser dran hängt) verwendet.


    Nun möchte ich das gerne über DoorPi realisieren. Wenn Eingang x geschlossen wird --> Ausgang "Türöffner" auf Ein schalten. Sobald der Eingang x wieder geöffnet wird, soll der Ausgang wieder geöffnet werden. Gleichzeitig möchte ich eine LED blinken lassen, die mir anzeigt, dass die Türe nun im Daueroffen-Modus ist. Wie realisiere ich das?
    Geht das ev. über einen DoorPi-Event, oder bleibt mir nur die Beuge über ein Script?


    Interessant wäre, wenn zum Schalten des Ausgangs auch ein URL- Aufruf (ähnlich XML-Api der Homematic) genutzt werden könnte. So könnte ich über meine Homematic einen Auf - Zu - Befehl abschicken usw.


    Danke für eure Hinweise.