Beiträge von OdroidXU4

    Ohje, ich verhau meinen Raspberry ganz schön, gut dass es nicht der reale DoorPI ist, sondern nur einer auf dem Schreibtisch welcher ausschließlich für die NFC-Tests zuständig ist.


    Ich hab das besagte Repository geklont, ja darin ist tagtool.py.

    Ein start mit python tagtool.py liefert dann gleich mal dass python3 benötigt wird.


    Installiert ist offensichtlich Python 2.7.16 und Python 3.7.3.

    System ist übrigens Raspbian 10.


    Ein Aufruf mit python3 tagtool.py bringt dann auch gleich dass diverse Module wie ndef, nfc config etc. fehlen.

    Versucht die alle nachzuziehen mit pip install ndef, bringt natürlich nichts da pip ja der Aufruf von Python 2 ist.

    Also über apt-get python3-pip installiert und dann pip3 install ndef dann kommt no module nfc usw.


    Letztendlich war dann irgendwann ein pip3 install tagtools erfolgreich...

    Jedoch kann ich dies irgendwie nicht aufrufen?

    Auch ein apt-get install tagtool habe ich gemacht, bis ich mal geschnallt hab, dass das ganz andere Tools für Audio files sind...


    Naja soweit bin ich nun dass python3 tagtool.py noch liefert no Module named nfc.

    Also pip3 install nfc liefert jedoch nen Fehler

    Python
        Complete output from command python setup.py egg_info:
        Traceback (most recent call last):
          File "<string>", line 1, in <module>
          File "/tmp/pip-install-s7hh7qf3/nfc/setup.py", line 6, in <module>
            from config import pypi_name
        ImportError: cannot import name 'pypi_name' from 'config' (/usr/local/lib/python3.7/dist-packages/config.py)
        
        ----------------------------------------
    Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-install-s7hh7qf3/nfc/


    Ich glaub ich komm hier nicht wirklich weiter...

    In der Config habe ich:


    Für den Test setze ich lediglich eine Symcon Variable, das klappt ja so alles.


    Sorry für die dumme Frage, aber wo finde ich die tagtool.py?


    In meinem /home/pi/libnfc ist nichts zu finden, vor allem da ich in Root geklont hatte bzw. ich hatte ja per PIP installiert?

    Hier die Original-Datei, wie gesagt diejenige von Github habe ich auch schon versucht, die war deutlich kürzer, sowie die modifiziert.

    Auch das 1. Log wo alles klappt mit sofortigem händischen Shutdown, sowie das anschließend 2. Log wo sich DoorPI selbst gleich wieder beendet.

    Macht er übrigens wohl auch, wenn gar kein Reader dran steckt???

    In einem anderen Beitrag PN532 Keyboard ist vom Gleichen Problem die Rede.

    Aber auch die gepostete Lösung 2 Posts danach ist bei mir nicht die Lösung.

    Meine Datei ist auch komplett anders als die auf Github, ich hab diese mal eingefügt aber immer noch das Gleiche Problem???


    Wenn ich NACH dem DoorPI shutdown ein nfc-list mache, kann auch er nicht auf das Device zugreifen...

    Also ich habe die Datei wie folgt geändert:

    /usr/local/lib/python2.7/dist-packages/doorpi/keyboard/from_pn532.py



    Die zuvor auskommentierten waren bereits drin, abgesehen von der Reihenfolge eigentlich das Gleiche?


    LG

    WOW. Ich glaub der Sache bin ich durch deine Hilfe ein ganzes Stück näher gekommen.


    Ich hatte heute ohne DoorPI zu starten NFCPY installiert. Anschließend hatte alles prima funktioniert, auch die Aktion sobald ein Tag in die Nähe kommt.


    Mit STRG-C habe ich dann DoorPI beendet und wollte ihn nochmal starten, das ging nicht, gleicher Fehler wie gestern, als ich NFCPY installiert hatte.

    Sobald das vorhanden ist fährt sich nach einem 2. Start DoorPI wieder von selbst herunter:


    Für mich liest sich das, als ob der Reader nicht mehr erreichbar ist, heißt für mich, er wird nicht sauber beendet, obwohl die grüne LED ausgeschaltet ist, sobald DoorPI heruntergefahren wurde.


    Wird das System neu gestartet ODER der Reader an/abgesteckt, funktioniert es wieder 1x.


    LG

    Morgen,

    Danke, das hatte ich gestern schon versucht mit nfcpy genau wie beschrieben, Ursache war dass DoorPI gar nicht mehr gestartet hatte.

    Ich seh mir das heute Nachmittag nochmal an, poste was genau der Fehler war bzw. Meine Config, wobie die quasi der obigen entspricht.

    Syntaxfehler hatte ich schon geschaut.

    LG

    Hallo rambaldi85


    ich habe soweit deinen Beitrag befolgt und ENDLICh nfc-list am Laufen.


    Sobald ein Tag aufgelegt ist, erscheint auch wie bei dir die ATQA UID SAK und ATS.


    Was ich mich nun aber Frag, wie du in deiner doorpi-Konfig auf den Wert B614818D kommst?


    Vermutlich ist das noch mein letztes Thema und dann hoffe ich dass es läuft.


    LG


    PS. Hab da wohl auch noch ein anderes Problem:

    Code
    2020-03-08 20:20:12,979 [ERROR]         [doorpi.keyboard.KeyboardInterface] keyboard nfcreader not found @ keyboard.from_pn532 (msg: No module named nfc)
    Traceback (most recent call last):
      File "/usr/local/lib/python2.7/dist-packages/doorpi/keyboard/KeyboardInterface.py", line 42, in load_single_keyboard
        keyboard = importlib.import_module('doorpi.keyboard.from_'+keyboard_type).get(
      File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
        __import__(name)
      File "/usr/local/lib/python2.7/dist-packages/doorpi/keyboard/from_pn532.py", line 87, in <module>
        import nfc
    ImportError: No module named nfc
    2020-03-08 20:20:12,980 [ERROR]         [doorpi.keyboard.KeyboardInterface] couldn't load keyboard nfcreader

    Hi,


    oh sorry, genau mein Thema...


    Hab inzwischen auch alles mit den nfc-list am Laufen, hat mich nun den ganzen Nachmittag gekostet.


    Jetzt ist nur noch die Frage, wie er auf den Wert kommt, auf den er abfragt.

    Hoffe er antwortet auf das Thema, ist doch schon paar Jahre alt...

    Morgen,


    sorry der späten Antwort, bekam wohl keine Mails bei abbonierten Themen...


    Ich hatte mit dem Thema schonmal herumprobiert, die älteren USB-Reader hatten die Schlüssel-ID direkt auf die Konsole geschrieben. Damit konnte über die DoorPI Config der Schlüsselwert einer Aktion zugewiesen werden z.B.

    Code
    [keyboards]
    rfidreader = rdm6300
    
    [rfidreader_InputPins]
    1234567 = out:Tueroeffner,1,0,3
    2345678 = out:Tueroeffner,1,0,3

    Das macht nun aber dieser Reader nicht, er schreibt die IDs nicht auf die Konsole und somit bekommt auch DoorPI nicht mit, was er machen soll.


    Meine Fragen wären nun, inwieweit ich diesen Reader bzw. die Ausgabe von pcsc_scan auf die Konsole bekomme (Evtl eigenes Skript?) oder ob es noch andere Möglichkeiten für DoorPI gibt, die Ausgabe des Readers zu verarbeiten?


    LG

    Hallo,


    in den letzten Monaten habe ich viel mit Yubikeys gemacht, dazu hab ich mir ein paar Yubikey 5 NFC geholt.


    Der Einzige Reader der den Yubikey liest ist der Weiße ACR122U ich habe den von Kmoon.


    Ich habe den Reader auch endlich auf meinem Linux am Laufen, mit:

    Code
    pcsc_scan


    wartet der Reader auf einen Tag und schreibt mir die Daten wenn einer in Reichweite kommt.


    Jetzt bin ich am überlegen, wie ich das ins Doorpi bekomme. Alle anderen versuchten Reader hatten direkt in die Konsole bzw. in ein beliebiges Feld wo der Cursors stand die ID eingetragen. Damit kam auch DoorPI zurecht.


    Gibt es eine Config, mit der ich direkt das Scannen veranlassen kann?

    Alternativ muss ich wohl dafür sorgen, dass der Reader immer scannt und der Output umgeleitet wird?

    Ideen?


    LG

    Hallo,


    die App läuft bei mir soweit, jedoch bekomme ich meine IP-Kamera nicht zum Laufen.


    Normal rufe ich sie mit:


    Code
    http://benutzer:passwort@1.2.3.4/media/?action=stream

    auf, geht nur nicht?


    Kann das überhaupt funktionieren?

    Hallo,


    ich müsste mit einem einzigen OnBoardPin, welcher gerade mein Licht schaltet eine weitere Aktion realisieren.


    Mein erster Gedanke:

    • wenn der Knopfdruck <1s dauert, dann Aktion 1 z.B. call:**000
    • wenn Knopfdruck >1s dauert, dann Aktion 2 z.B. call:**111

    Auch möglich wäre die Anzahl der Knopfdrücke innerhalb eines Zeitfensters zu ermitteln.


    Kann ich das rein im DoorPI bereits umsetzen?
    LG

    Guten Morgen,


    seit einigen Wochen stellen wir vermehrt fest, dass die DoorPI (Raspberry 3) Anlage plötzlich klingelt, obwohl niemand den Taster gedrückt hat.


    Für unsere Klingelevents werden je 2 Aktionen gestartet.
    10 = ipsrpc_setvalue:xxx,True20 = call:**123


    Es wird ein Wert in IP-Symcon gesetzt, welcher den Gong ansteuert und anschließend der Ruf zur Fritzbox.


    Das Lustige, beide Events werden ausgeführt, auf beide meiner Etagen.


    Bevor ich an die Pins mit einem C rangeh, hätte ich erstmal am Timing der Onboardpins gespielt:
    [onboardpins_keyboard]bouncetime = 200


    Ich gehe davon aus, die Bouncetime betrifft jeden der Pins? Ich finde man merkt eine etwas schlechtere Tasterreaktion beim Klingeln, wenn ich diese verdoppele. Aber irgendwie merke ich beim Licht-Ein Taster nichts?


    Betrifft diese Funktion alle Pins? Oder soll ich gleich einen C an die Pins hängen? Dachte die hätten intern im Raspberry schon alles sauber entkoppelt?

    Hallo,


    unsere DoorPI Anlage läuft derzeit eher nicht so optimal, inzwischen sind wir auch auf eine Fritzbox 7590 gewechselt, die Fritzfone sind nach wie vor die MT-F Telefone
    Wir haben 2 Wohnungen jeweils mit 2 der DECT Telefone.


    Anfangs lief alles relativ gut vor ca. einem halben Jahr. Gerade in letzter Zeit merkten wir immer wieder Themen wie:
    - Telefon läutet nur kurz (<10s)
    - Trotz abheben kein Gesprächsaufbau
    - keine Steuerung der DTMF Töne


    Letztens hatte es 3x innerhalb von 2h geläutet, jedesmal war irgendetwas anderes das nicht ging und zwang mich zum manuellen Türöffnen.
    Jedesmal hatte ich im Anschluss einen Test gemacht, da ging dann plötzlich wieder alles.


    Ich hatte im OG zuletzt auch einen 2. Ruf auf die Elcom App eines Tablets. Dies hatte ich mit:

    Code
    10 = call:**611#622


    gelöst. Hier war die Sache noch schlimmer, mal läutete nur das eine Telefon, mal nur das Tablet, andere Male beide. Sehr oft konnte gerade das Handy mit Gesprächsannahme dies aber nicht durchführen. In der Fritzbox erschien dann aus unerklärlichen Gründen, dass die Telefonie nicht genehmigt wurde. (forbidden 403) Beim direkten testen funktionierts dann aber doch?


    Jetzt bin ich am suchen, ich bin mir relativ sicher, dass die Sache nicht nur alleine am Raspberry/DoorPI liegt, sondern sicher auch die Fritzbox ihren Teil dazu beiträgt.


    Die Einstellung "call_timeout" denke ich war standard auf 20s. Ich hatte sie zeitweise auf 30s erhöht, da 20s für uns zu kurz sind.
    Hier möchte ich nun beobachten, nachdem ich wieder auf 20s gestellt habe, ob ich weiterhin zu kurze Rufe habe.


    Den obigen Doppelruf habe ich aktuell deaktiviert, nur das Telefon klingelt, Tablet ist aus. Hier möchte ich sehen, ob es auch bei jedem Läuten/Tastendruck anständig klingelt.


    Ich habe DoorPI an IP-Symcon angebunden, eine LED Leiste blinkt in Grün bei einem Klingeln.
    Jedesmal egal was nachträglich mit der Kommunikation war, hatte dies zuverlässig funktioniert. Auch der Türgong wurde immer korrekt angesteuert.
    Die Erkennung auf Seiten Raspberry ist also durchaus vorhanden und wird korrekt weitergegeben.


    Die Kommunikation kann also durchaus von der Fritzbox kommen, oder die USB-Freisprecheinrichtung wird vom Raspberry nicht korrekt aktiviert?
    Dies erkennt man i.d.R. an einem kleinen Knacksen am Lautsprecher. Dieses bleibt aus, wenn keine Kommuniaktion stattfindet, evtl. ist doch auch Raspbbery Seite noch was zu optimieren?


    Was meint ihr, wo könnte ich was noch ausprobieren?
    Speziell, wie wirken sich die folgenden Einstellungen aus:

    Code
    call_timeout
    ua.max_calls


    LG

    Morgen,


    hm naja wie man´s sieht.
    Im Beitrag Einbau der VOIP Video Türsprechanlage im Haus seht ihr im oberen Drittel ein Bild, wo die Polycom Platine auf dem Ritto Lautsprechermodul montiert ist.
    Die Technik ist also die vom Polycom.


    Der eigentliche Lautsprecher und das Mikrofon sind die, welche bereits im Ritto Modul verbaut waren.
    Die sind hier Herstellerbedingt auch schon gut eingepasst und entsprechend entkoppelt, um das Echo-Problem zu verbessern.


    Da sehe ich wäre ein kleines Update fällig, inzwischen sind draußen an der Türe nämlich 3 Module mit einem Ritto Blindmodul, in welches ich die Raspicam gebaut hab.
    Update folgt heute noch...