Beiträge von sgaechter

    Hallo Armin.

    Ich nehme an, Reboot hatst du schon probiert?

    Siehst du beim Aufruf der MJPG-Streamer URL."http://<URL_des_pis>:9000/stream.html" auch schwarz?

    Was siehst du, wenn du den Befehl "sudo systemctl status mjpg_streamer.service" aufrufst?


    Versuche malüber die Konsole den MJPG Service zu beenden : "sudo systemctl stop mjpg_streamer.service" und anschliessend:

    "raspistill -o testshot.jpg"


    Nun solltest du im gleichen Ordner eine Datei namens "testshot.jpg" haben. Wenn du dir diese über FTP runter ziehst und anschaust, solltest du deas Bild deiner Kamera sehen. Ist das schwarz, würde ich mal mit

    "sudo apt-get update & sudo apt-get upgrade" alles aktualisieren und mit dem oberen Befehl nochmals versuchen.

    Ist der nächste Versuch ebenfalls schwarz, tippe ich auf eine kaputte Kamera. Da kannst du mit einem Ersatz anklemmen mal versuchen. Nach dem Neustart des Pi's sollte dann der MJPG-Streamer wieder laufen und du kannst über die URL sehen, ob das was gebracht hat.


    War der Versuch nach dem Update erfolgreich, sind Kamera und Treiber schon mal in Ordnung.

    Danach kannst du mit "sudo systemctl start mjpg_streamer.service" den Dienst wieder starten und nochmals über die URL testen. hast du dort kein Bild, würde ich den MJPG-Streamer neu installieren.



    Gruss

    Sven

    Hallo Bgll68.


    Die Fehlermeldung sagt, dass das File nicht vorhanden ist.

    In deinem Screenshot fällt mir auf, dass du das HOME-Verzeichnis zeigst. In der Fehlermeldung sehe ich aber, dass DoorPi unter "/usr/local/lib/python2.7/dist-packages/DoorPi-2.5.1-py2.7.egg/doorpi/" installiert sein muss. Ich weiss nicht genau, wie deine Installation ins HOME rein kam. Hast du da alles hin kopiert?

    Gemäss Fehlermeldung erwartet DoorPi dein Keyboard "from_mfrc522.py" unter "/usr/local/lib/python2.7/dist-packages/DoorPi-2.5.1-py2.7.egg/doorpi/keyboards".

    Schau mal dort nach und kopiere das file dort hin und teste nochmals.


    Gruss

    Sven

    Hallo Jürgen.


    Habe über die Feiertage die Buster-Odysee hinter mir. Nachdem DoorPi zwei Wochen verrückt gespielt hat (GPIO's, PyFace usw...), habe ich alles wieder auf Stretch installiert - und siehe Da: Alles wieder in Butter. Ich würde dir empfehlen, mit dieser Übung zu warten, so lange DoorPi noch auf Python 2 basiert. Im Forum sind Stimmen zu lesen, welche bereit wären, bei einer Portierung mitzuhelfen. Wer weiss, vielleicht gehörst du ja auch dazu.


    Ich würde, wenn möglich den alten IT-Grundsatz "Don't touch a running system" ernst nehmen ;)


    Gruss

    Sven

    Hallo deviloper .


    Danke für deine Arbeit. Du hast mir mein fehlendes Puzzleteil zugespielt.

    In deinem Keyboard ist noch ein Syntaxfehler drin: In Zeile 81 hast du eine schliessende Klammer zuviel und das Shebang am Anfang fehlt, damit keine Codierungsfehler auftreten.:

    Code
    1. #!/usr/bin/env python
    2. # -*- coding: utf-8 -*-

    Bei mir sieht die funktionierende Config-Section so aus:

    Code
    1. [fpreader_InputPins]
    2. 1 = sleep:0
    3. 2 = sleep:0
    4. [fpreader_keyboard]
    5. port = /dev/ttyUSB0 # hier ist in deinem Beispiel der falsche Keyname angegeben
    6. security = 80
    7. [keyboards]
    8. fpreader = fingerprint

    So habe ich das Keyboard dann ans Laufen gekriegt.


    Vielen Dank für deine Arbeit. Da dran habe ich über ein Jahr geknobelt und habe es nie hin gepriegt - jetzt weiss ich auch, wo mein Denkfehler lag :/


    Ich würde vorschlagen, ich teste eine Woche und anschliessend kannst du ja einen pull request zum DoorPi Repository machen, damit Thomas es in den MASTER-Zweig aufnehmen kann.


    Gruss

    Sven

    Hallo motom001.


    Nur so zur Verfollständigung. Beim unter #2 beschreibenen Script ist die Idee, dieses als separater Service laufen zu lassen. Es "horcht" MQTT und nutzt den Webservice als "Interface" zu DoorPi. Somit wird dieses Script nicht als Action in DoorPi integriert.

    Demzufolge ist das "client.loop_forever()" dort schon richtig, sonst beendet sich das Script nach dem ersten MQTT- Event selber und der Service (sofern er so konfiguriert wird) muss das Script wieder starten.


    Aber nun zu deiner Anmerkung iS Keyboard: Ich bin ganz deiner Meinung. DoorPi bringt alle Voraussetzungen mit, solche Dienste per Keyboard abzubilden. Das wäre natürlich dann auch der konfortable Weg. und erst noch ressourcenschonender.


    Leider fand ich bisher keine Dokumentation, wie ein solches Keyboard genau programmiert wird (sprich API Doku). Ich habe erfolglos versucht, die bestehenden Keyboards zu analysieren um das herauszufinden.

    Ich bin gerne bereit, Keyboards für MQTT (und auch für Telegram und weitere wie z.B Fhem) zu erstellen. Doch leider sind meine Hilferufe im Forum bisher in der Tiefe verhallt. Wenn du mir auf die Sprünge hilfst, bin ich gerne Bereit, Zeit zu investieren. (check mal deine Pn's, auch von motom001_new) :)


    Kunstflieger: Damit keine Unsicherheit entsteht: Wenn du das Script als "SERVICE" einrichtest und nicht aus DoorPi heraus anstupst (das ginge ja grundsätzlich über "os_execute:" auch), ist motom001 's Bemerkung für dich eine Randnotiz. ;)


    happy basteling.

    Sven

    Hallo Kunstflieger.


    Jetzt raffe ich, was du meinst... Da hat sich einen automatischen Zeilenumbruch reingeschmuggelt.

    Das Ganze gehört auf die gleiche Linie (WoltLab stellt den Sorcecode selbst in der dafür vorgesehenen Box nicht richtig dar. das ist ärgerlich....).

    Die korrekte URL in der Klammer heisst:

    Code
    1. 'http://localhost:8080/control/trigger_event?event_name=OnKeyPressed_file.dooropen&event_source=doorpi.keyboard.from_filesystem'

    Kopiere ihn im Python Script einfach zwischen die Klammern, ohne Zeilenumbruch.

    Danach wird wohl auch der Subscriptor funktionieren...

    Hallo Kunstflieger.

    Befehl 'event_source=doorpi.keyboard.from_filesystem'

    Du hast recht, dieser wird un der Doorpi.ini nicht weiter aufgeführt. Dieser Teil der aufgerufenen URL gehört zum constructor der Api.

    MQTT broker läuft schon und die DoorPi sendet auch schon fleißig Status an mein Dashboard. Daher meinte ich, dass die Publisher Funktion schon geht. Aber damit DoorPi als Subscriber auf Topics und Schlagwörter achtet, das muss ich noch rausfinden.

    Aha demzufolge läuft der Broker auf deinem DoorPi?

    Wie werden denn die Messages aufbereitet?

    Ich glaube, dann kannst du den Subscriber dort irgendwo registrieren und einfach die URL aus meinem Python-Script aufrufen lassen.

    Gruss Sven

    Hallo Kunstflieger.

    Voraussetzung ist ein MQTT Broker in deinem Netz und ein Python Script (in dieser Art) als Service:

    Quelle: tutorials-raspberrypi.de



    Sinnvollerweise erstellst du einen neuen Event für einen Eingang vom Keyboard "File" und nennst ihn "dooropen":


    Da ich selber momentan kein MQTT in Betrieb habe, kann ich die Lösung nicht testen, aber grundsätzlich sollte sie dich zumindest auf die Fährte bringen :-)



    Gruss

    Sven

    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...