Ankündigung

Einklappen
Keine Ankündigung bisher.

zeitlich verzögerte Ausführung einer Logik getriggert via UDP Telegramm

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    zeitlich verzögerte Ausführung einer Logik getriggert via UDP Telegramm

    Hallo Marcus,

    ich habe ein Problem mit einer Logik, die über UDP Telegramme getriggert wird. Die Sache ist leider etwas heikel, da es um den Fingerprintleser an der Türe geht. Meine Freundin hat heute mehrere Male den Finger über den Leser gezogen, weil die Tür dabei nicht auf ging, obwohl der Leser mit grün (= erfolgreich) quitiert hat. Darauf hin hat sie bei den Schwiegereltern den Ersatzschlüssel geholt und ist damit dann rein. Als sie drin war ging dann plötzlich die Tür auf. Den WAF kannst du dir wahrscheinlich vorstellen.

    In den Logs sehe ich, das Eintreffen der UDP Telegramme und das die Logik getriggert werden soll. Tatsächlich getriggert wird sie aber erst einige Zeit später, was man an der Ausgabe in der Logik sieht. Die Logs habe ich mal auf den IMHO relevanten Teil runter gebrochen und unten mal gepostet. Verdächtig finde ich, dass der Scheduler im Minutentakt neue Workerthreads hinzufügt, aber vielleicht ist das auch normal!?

    Obwohl nicht wirklich notwendig, da entsprechend über das Routing im Switch abgesichert, habe ich mal alle IP und KNX Adressen usw. aus dem Log entfernt und durch Dummy Werte ersetzt. Diese sollten hier aber auch keine Rolle spielen.

    Code:
    ...
    2013-06-10 12:40:09,698 SmartHome.py DEBUG    udp:xxx.xxx.xxx.xxx:yyyyy Incoming connection from xxx.xxx.xxx.xxx:yyyyy -- __init__.py:handle_read:157
    2013-06-10 12:40:09,698 SmartHome.py DEBUG    Triggering fingerprint - by: network source: xxx.xxx.xxx.xxx destination: None value: 1_0000_0_xxxxxxxxxxxxxx_2_- -- scheduler.py:trigger:117
    2013-06-10 12:40:09,701 fingerprint  DEBUG    Payload = 1_0000_0_xxxxxxxxxxxxxx_2_- -- fingerprint.py:<module>:10
    2013-06-10 12:40:09,701 fingerprint  INFO     Unknown finger -- fingerprint.py:<module>:31
    2013-06-10 12:40:11,317 Scheduler    DEBUG    series next time: 2013-06-10 12:40:21+02:00 -- scheduler.py:_next_time:238
    2013-06-10 12:40:12,833 SmartHome.py DEBUG    udp:xxx.xxx.xxx.xxx:yyyyy Incoming connection from xxx.xxx.xxx.xxx:yyyyy -- __init__.py:handle_read:157
    2013-06-10 12:40:12,833 SmartHome.py DEBUG    Triggering fingerprint - by: network source: xxx.xxx.xxx.xxx destination: None value: 1_0002_7_xxxxxxxxxxxxxx_1_1 -- scheduler.py:trigger:117
    ...
    2013-06-10 12:40:21,076 SmartHome.py DEBUG    udp:xxx.xxx.xxx.xxx:yyyyy Incoming connection from xxx.xxx.xxx.xxx:yyyyy -- __init__.py:handle_read:157
    2013-06-10 12:40:21,076 SmartHome.py DEBUG    Triggering fingerprint - by: network source: xxx.xxx.xxx.xxx destination: None value: 1_0002_7_xxxxxxxxxxxxxx_1_1 -- scheduler.py:trigger:117
    ...
    2013-06-10 12:40:38,142 SmartHome.py DEBUG    udp:xxx.xxx.xxx.xxx:yyyyy Incoming connection from xxx.xxx.xxx.xxx:yyyyy -- __init__.py:handle_read:157
    2013-06-10 12:40:38,142 SmartHome.py DEBUG    Triggering fingerprint - by: network source: xxx.xxx.xxx.xxx destination: None value: 1_0000_0_xxxxxxxxxxxxxx_2_- -- scheduler.py:trigger:117
    ...
    2013-06-10 12:40:43,064 SmartHome.py DEBUG    udp:xxx.xxx.xxx.xxx:yyyyy Incoming connection from xxx.xxx.xxx.xxx:yyyyy -- __init__.py:handle_read:157
    2013-06-10 12:40:43,064 SmartHome.py DEBUG    Triggering fingerprint - by: network source: xxx.xxx.xxx.xxx destination: None value: 1_0000_0_xxxxxxxxxxxxxx_2_- -- scheduler.py:trigger:117
    2013-06-10 12:40:43,163 fingerprint  DEBUG    Payload = 1_0000_0_xxxxxxxxxxxxxx_2_- -- fingerprint.py:<module>:10
    2013-06-10 12:40:43,163 fingerprint  INFO     Unknown finger -- fingerprint.py:<module>:31
    2013-06-10 12:40:43,164 Scheduler    INFO     Adding worker thread. Total: 12 -- scheduler.py:_add_worker:250
    ...
    2013-06-10 12:40:47,948 SmartHome.py DEBUG    udp:xxx.xxx.xxx.xxx:yyyyy Incoming connection from xxx.xxx.xxx.xxx:yyyyy -- __init__.py:handle_read:157
    2013-06-10 12:40:47,948 SmartHome.py DEBUG    Triggering fingerprint - by: network source: xxx.xxx.xxx.xxx destination: None value: 1_0002_4_xxxxxxxxxxxxxx_1_1 -- scheduler.py:trigger:117
    ...
    2013-06-10 12:40:56,472 SmartHome.py DEBUG    udp:xxx.xxx.xxx.xxx:yyyyy Incoming connection from xxx.xxx.xxx.xxx:yyyyy -- __init__.py:handle_read:157
    2013-06-10 12:40:56,472 SmartHome.py DEBUG    Triggering fingerprint - by: network source: xxx.xxx.xxx.xxx destination: None value: 1_0002_7_xxxxxxxxxxxxxx_1_1 -- scheduler.py:trigger:117
    ...
    2013-06-10 12:41:07,877 SmartHome.py DEBUG    udp:xxx.xxx.xxx.xxx:yyyyy Incoming connection from xxx.xxx.xxx.xxx:yyyyy -- __init__.py:handle_read:157
    2013-06-10 12:41:07,877 SmartHome.py DEBUG    Triggering fingerprint - by: network source: xxx.xxx.xxx.xxx destination: None value: 1_0002_7_xxxxxxxxxxxxxx_1_1 -- scheduler.py:trigger:117
    ...
    2013-06-10 12:41:21,003 SmartHome.py DEBUG    udp:xxx.xxx.xxx.xxx:yyyyy Incoming connection from xxx.xxx.xxx.xxx:yyyyy -- __init__.py:handle_read:157
    2013-06-10 12:41:21,003 SmartHome.py DEBUG    Triggering fingerprint - by: network source: xxx.xxx.xxx.xxx destination: None value: 1_0002_7_xxxxxxxxxxxxxx_1_1 -- scheduler.py:trigger:117
    ...
    2013-06-10 12:41:35,048 SmartHome.py DEBUG    udp:xxx.xxx.xxx.xxx:yyyyy Incoming connection from xxx.xxx.xxx.xxx:yyyyy -- __init__.py:handle_read:157
    2013-06-10 12:41:35,048 SmartHome.py DEBUG    Triggering fingerprint - by: network source: xxx.xxx.xxx.xxx destination: None value: 1_0002_7_xxxxxxxxxxxxxx_1_1 -- scheduler.py:trigger:117
    ...
    2013-06-10 12:41:44,253 fingerprint  DEBUG    Payload = 1_0000_0_xxxxxxxxxxxxxx_2_- -- fingerprint.py:<module>:10
    2013-06-10 12:41:44,253 Scheduler    INFO     Adding worker thread. Total: 13 -- scheduler.py:_add_worker:250
    2013-06-10 12:41:44,253 fingerprint  INFO     Unknown finger -- fingerprint.py:<module>:31
    ...
    2013-06-10 12:41:52,355 SmartHome.py DEBUG    udp:xxx.xxx.xxx.xxx:yyyyy Incoming connection from xxx.xxx.xxx.xxx:yyyyy -- __init__.py:handle_read:157
    2013-06-10 12:41:52,355 SmartHome.py DEBUG    Triggering fingerprint - by: network source: xxx.xxx.xxx.xxx destination: None value: 1_0002_7_xxxxxxxxxxxxxx_1_1 -- scheduler.py:trigger:117
    ...
    2013-06-10 12:42:05,117 SmartHome.py DEBUG    udp:xxx.xxx.xxx.xxx:yyyyy Incoming connection from xxx.xxx.xxx.xxx:yyyyy -- __init__.py:handle_read:157
    2013-06-10 12:42:05,118 SmartHome.py DEBUG    Triggering fingerprint - by: network source: xxx.xxx.xxx.xxx destination: None value: 1_0000_0_xxxxxxxxxxxxxx_2_- -- scheduler.py:trigger:117
    2013-06-10 12:42:08,521 SmartHome.py DEBUG    udp:xxx.xxx.xxx.xxx:yyyyy Incoming connection from xxx.xxx.xxx.xxx:yyyyy -- __init__.py:handle_read:157
    2013-06-10 12:42:08,521 SmartHome.py DEBUG    Triggering fingerprint - by: network source: xxx.xxx.xxx.xxx destination: None value: 1_0002_7_xxxxxxxxxxxxxx_1_1 -- scheduler.py:trigger:117
    ...
    2013-06-10 12:42:17,121 SmartHome.py DEBUG    udp:xxx.xxx.xxx.xxx:yyyyy Incoming connection from xxx.xxx.xxx.xxx:yyyyy -- __init__.py:handle_read:157
    2013-06-10 12:42:17,121 SmartHome.py DEBUG    Triggering fingerprint - by: network source: xxx.xxx.xxx.xxx destination: None value: 1_0000_0_xxxxxxxxxxxxxx_2_- -- scheduler.py:trigger:117
    2013-06-10 12:42:21,310 Scheduler    DEBUG    series next time: 2013-06-10 12:42:31+02:00 -- scheduler.py:_next_time:238
    2013-06-10 12:42:22,205 SmartHome.py DEBUG    udp:xxx.xxx.xxx.xxx:yyyyy Incoming connection from xxx.xxx.xxx.xxx:yyyyy -- __init__.py:handle_read:157
    2013-06-10 12:42:22,205 SmartHome.py DEBUG    Triggering fingerprint - by: network source: xxx.xxx.xxx.xxx destination: None value: 1_0002_7_xxxxxxxxxxxxxx_1_1 -- scheduler.py:trigger:117
    ...
    2013-06-10 12:42:45,346 fingerprint  DEBUG    Payload = 1_0000_0_xxxxxxxxxxxxxx_2_- -- fingerprint.py:<module>:10
    2013-06-10 12:42:45,346 Scheduler    INFO     Adding worker thread. Total: 14 -- scheduler.py:_add_worker:250
    2013-06-10 12:42:45,346 fingerprint  INFO     Unknown finger -- fingerprint.py:<module>:31
    ...
    2013-06-10 12:43:46,436 fingerprint  DEBUG    Payload = 1_0000_0_xxxxxxxxxxxxxx_2_- -- fingerprint.py:<module>:10
    2013-06-10 12:43:46,436 Scheduler    INFO     Adding worker thread. Total: 15 -- scheduler.py:_add_worker:250
    2013-06-10 12:43:46,436 fingerprint  INFO     Unknown finger -- fingerprint.py:<module>:31
    ...
    2013-06-10 12:44:47,525 Scheduler    INFO     Adding worker thread. Total: 16 -- scheduler.py:_add_worker:250
    ...
    2013-06-10 12:44:47,526 fingerprint  DEBUG    Payload = 1_0002_4_xxxxxxxxxxxxxx_1_1 -- fingerprint.py:<module>:10
    2013-06-10 12:44:47,526 fingerprint  INFO     User 2 with finger 4 -- fingerprint.py:<module>:43
    2013-06-10 12:44:47,526 fingerprint  DEBUG    eg.flur.tuer.auf = True via Logic None -- item.py:_update:214
    2013-06-10 12:44:47,526 fingerprint  DEBUG    Payload = 1_0002_7_xxxxxxxxxxxxxx_1_1 -- fingerprint.py:<module>:10
    2013-06-10 12:44:47,526 fingerprint  INFO     User 2 with finger 7 -- fingerprint.py:<module>:43
    2013-06-10 12:44:47,526 fingerprint  DEBUG    eg.flur.tuer.auf = True via Logic None -- item.py:_update:214
    2013-06-10 12:44:47,526 fingerprint  DEBUG    Payload = 1_0002_7_xxxxxxxxxxxxxx_1_1 -- fingerprint.py:<module>:10
    2013-06-10 12:44:47,526 fingerprint  INFO     User 2 with finger 7 -- fingerprint.py:<module>:43
    2013-06-10 12:44:47,527 fingerprint  DEBUG    eg.flur.tuer.auf = True via Logic None -- item.py:_update:214
    2013-06-10 12:44:47,527 fingerprint  DEBUG    Payload = 1_0002_7_xxxxxxxxxxxxxx_1_1 -- fingerprint.py:<module>:10
    2013-06-10 12:44:47,527 fingerprint  INFO     User 2 with finger 7 -- fingerprint.py:<module>:43
    2013-06-10 12:44:47,527 fingerprint  DEBUG    eg.flur.tuer.auf = True via Logic None -- item.py:_update:214
    2013-06-10 12:44:47,527 fingerprint  DEBUG    Payload = 1_0002_7_xxxxxxxxxxxxxx_1_1 -- fingerprint.py:<module>:10
    2013-06-10 12:44:47,527 fingerprint  INFO     User 2 with finger 7 -- fingerprint.py:<module>:43
    2013-06-10 12:44:47,527 fingerprint  DEBUG    eg.flur.tuer.auf = True via Logic None -- item.py:_update:214
    2013-06-10 12:44:47,527 fingerprint  DEBUG    Payload = 1_0002_7_xxxxxxxxxxxxxx_1_1 -- fingerprint.py:<module>:10
    2013-06-10 12:44:47,527 fingerprint  INFO     User 2 with finger 7 -- fingerprint.py:<module>:43
    2013-06-10 12:44:47,527 fingerprint  DEBUG    eg.flur.tuer.auf = True via Logic None -- item.py:_update:214
    2013-06-10 12:44:47,528 fingerprint  DEBUG    Payload = 1_0002_7_xxxxxxxxxxxxxx_1_1 -- fingerprint.py:<module>:10
    2013-06-10 12:44:47,528 fingerprint  INFO     User 2 with finger 7 -- fingerprint.py:<module>:43
    2013-06-10 12:44:47,528 fingerprint  DEBUG    eg.flur.tuer.auf = True via Logic None -- item.py:_update:214
    2013-06-10 12:44:47,528 fingerprint  DEBUG    Payload = 1_0002_7_xxxxxxxxxxxxxx_1_1 -- fingerprint.py:<module>:10
    2013-06-10 12:44:47,528 fingerprint  INFO     User 2 with finger 7 -- fingerprint.py:<module>:43
    2013-06-10 12:44:47,528 fingerprint  DEBUG    eg.flur.tuer.auf = True via Logic None -- item.py:_update:214
    2013-06-10 12:44:47,528 fingerprint  DEBUG    Payload = 1_0002_7_xxxxxxxxxxxxxx_1_1 -- fingerprint.py:<module>:10
    2013-06-10 12:44:47,528 fingerprint  INFO     User 2 with finger 7 -- fingerprint.py:<module>:43
    2013-06-10 12:44:47,528 fingerprint  DEBUG    eg.flur.tuer.auf = True via Logic None -- item.py:_update:214
    2013-06-10 12:44:47,528 fingerprint  DEBUG    Payload = 1_0002_7_xxxxxxxxxxxxxx_1_1 -- fingerprint.py:<module>:10
    2013-06-10 12:44:47,529 fingerprint  INFO     User 2 with finger 7 -- fingerprint.py:<module>:43
    2013-06-10 12:44:47,529 fingerprint  DEBUG    eg.flur.tuer.auf = True via Logic None -- item.py:_update:214
    ...
    2013-06-10 12:44:47,600 SmartHome.py DEBUG    1.0.254 set x/x/x to True -- __init__.py:parse_telegram:177
    2013-06-10 12:44:47,600 SmartHome.py DEBUG    eg.flur.tuer.auf = True via KNX 1.0.254 -- item.py:_update:214
    2013-06-10 12:44:47,631 SmartHome.py DEBUG    1.0.254 set x/x/x to True -- __init__.py:parse_telegram:177
    2013-06-10 12:44:47,632 SmartHome.py DEBUG    eg.flur.tuer.auf = True via KNX 1.0.254 -- item.py:_update:214
    2013-06-10 12:44:47,663 SmartHome.py DEBUG    1.0.254 set x/x/x to True -- __init__.py:parse_telegram:177
    2013-06-10 12:44:47,663 SmartHome.py DEBUG    eg.flur.tuer.auf = True via KNX 1.0.254 -- item.py:_update:214
    2013-06-10 12:44:47,695 SmartHome.py DEBUG    1.0.254 set x/x/x to True -- __init__.py:parse_telegram:177
    2013-06-10 12:44:47,695 SmartHome.py DEBUG    eg.flur.tuer.auf = True via KNX 1.0.254 -- item.py:_update:214
    2013-06-10 12:44:47,727 SmartHome.py DEBUG    1.0.254 set x/x/x to True -- __init__.py:parse_telegram:177
    2013-06-10 12:44:47,727 SmartHome.py DEBUG    eg.flur.tuer.auf = True via KNX 1.0.254 -- item.py:_update:214
    2013-06-10 12:44:47,749 SmartHome.py DEBUG    1.1.3 set 1/5/72 to 60 -- __init__.py:parse_telegram:177
    2013-06-10 12:44:47,775 SmartHome.py DEBUG    1.0.254 set x/x/x to True -- __init__.py:parse_telegram:177
    2013-06-10 12:44:47,775 SmartHome.py DEBUG    eg.flur.tuer.auf = True via KNX 1.0.254 -- item.py:_update:214
    2013-06-10 12:44:47,809 SmartHome.py DEBUG    1.0.254 set x/x/x to True -- __init__.py:parse_telegram:177
    2013-06-10 12:44:47,809 SmartHome.py DEBUG    eg.flur.tuer.auf = True via KNX 1.0.254 -- item.py:_update:214
    2013-06-10 12:44:47,840 SmartHome.py DEBUG    1.0.254 set x/x/x to True -- __init__.py:parse_telegram:177
    2013-06-10 12:44:47,840 SmartHome.py DEBUG    eg.flur.tuer.auf = True via KNX 1.0.254 -- item.py:_update:214
    2013-06-10 12:44:47,871 SmartHome.py DEBUG    1.0.254 set x/x/x to True -- __init__.py:parse_telegram:177
    2013-06-10 12:44:47,871 SmartHome.py DEBUG    eg.flur.tuer.auf = True via KNX 1.0.254 -- item.py:_update:214
    2013-06-10 12:44:47,903 SmartHome.py DEBUG    1.0.254 set x/x/x to True -- __init__.py:parse_telegram:177
    2013-06-10 12:44:47,903 SmartHome.py DEBUG    eg.flur.tuer.auf = True via KNX 1.0.254 -- item.py:_update:214
    Und hier die entsprechende Logik:

    Code:
    DELIMITER = '_'
    SN = 'xxxxxxxxxxxxxx'
    
    if not trigger['source'] == 'xxx.xxx.xxx.xxx':
        logger.info("logic called from an invalid ip adress ({0})".format(trigger['source']))
        exit()
    
    # retrieve the payload
    payload = trigger['value']
    logger.debug("Payload = {0}".format(payload))
    
    # split the payload
    parts = payload.split(DELIMITER)
    
    # assign the single values
    user = int(parts[1])
    finger = parts[2]
    serial = parts[3]
    action = int(parts[4])
    relais = parts[5]
    
    if user > 2:
        logger.info("Unknown user id ({0})".format(user))
        exit()
    
    if not serial == SN:
        logger.info("Unknown serial number")
        exit()
    
    if action == 2:
        logger.info("Unknown finger")
        exit()
    
    if not action == 1:
        logger.info("Unknown action")
        exit()
    
    if finger == '-':
        finger = None
    else:
        finger = int(finger)
    
    logger.info("User {0} with finger {1}".format(user, finger))
    
    if finger == 4 or finger == 7:
        # open the door
        sh.eg.flur.tuer.auf(True)
    elif finger == 3:
        # open the garage door
        sh.aa.garage.tuer(True)
    elif finger == 8:
        # open the garage gate
        sh.aa.garage.tor(sh.aa.garage.tor.oben())
    die so konfiguriert wurde:

    Code:
    ['fingerprint']
        filename = 'fingerprint.py'
        nw = yes
        nw_udp_listen = xxxxx  # port number
    Wäre schön, wenn du da mal drüber schauen könntest. Ich könnte dafür zwar auch ein Plugin schreiben, aber letztlich sollte das doch eigentlich problemlos auch als Logik funktionieren.
    Mit freundlichen Grüßen
    Niko Will

    Logiken und Schnittstelle zu anderen Systemen: smarthome.py - Visualisierung: smartVISU
    - Gira TS3 - iPhone & iPad - Mobotix T24 - ekey - Denon 2313 - Russound C5 (RIO over TCP Plugin) -

    #2
    Hallo Niko,

    erst einmal Sorry für die Erklärungsnot in die Dich SH.py gebracht hat.

    Das Problem liegt in den 'exit()' aufrufen. Die haben dazu geführt das die Threads sterben. Das hat dann zu dem zyklischen hinzufügen von Threads geführt. Das sterben der Threads (Unknown finger) ging aber schneller als das hinzufügen.

    Der Code in github fängt diesen Umstand jetzt ab.

    Bis bald

    Marcus

    Kommentar


      #3
      Hallo Marcus,

      kein Problem, sowas kommt vor. Aber Danke für die Erläuterung und das Fixen, werde ich heute Abend gleich testen. Das erklärt auch, warum das bei mir nie aufgetreten ist sondern hauptsächlich bei meiner Freundin. Sie hat noch etwas Probleme damit, den Finger auf die korrekte Art und Weise über den Leser zu ziehen. Daher kommt es öfters mal vor, dass der Finger abgewiesen wird und damit scheitern dann auch die korrekt erkannten Versuche danach in eben diesem Verhalten.

      Ist das denn der richtige Weg mit dem "exit()" oder macht man das normalerweise anders? Habe das glaub aus einer Logik aus dem Wiki übernommen.
      Mit freundlichen Grüßen
      Niko Will

      Logiken und Schnittstelle zu anderen Systemen: smarthome.py - Visualisierung: smartVISU
      - Gira TS3 - iPhone & iPad - Mobotix T24 - ekey - Denon 2313 - Russound C5 (RIO over TCP Plugin) -

      Kommentar


        #4
        Hallo Niko,

        exit() und sys.exit() werden jetzt abgefangen und können daher in den Logiken verwendet werden.
        Die Methoden an sich sind ok. Manche Programmierer, ich gehöre nicht dazu, finden multiple returns (in diesem Fall exit) blöd. Ich finde es macht den Code übersichtlicher.

        Bis bald

        Marcus

        Kommentar


          #5
          Hallo Marcus,

          Zitat von mknx Beitrag anzeigen
          Die Methoden an sich sind ok. Manche Programmierer, ich gehöre nicht dazu, finden multiple returns (in diesem Fall exit) blöd. Ich finde es macht den Code übersichtlicher.
          Dann sind wir da ja einer Meinung

          Ich dachte nur evtl. sollte man mit return oder ähnlichem aussteigen anstelle von exit.
          Mit freundlichen Grüßen
          Niko Will

          Logiken und Schnittstelle zu anderen Systemen: smarthome.py - Visualisierung: smartVISU
          - Gira TS3 - iPhone & iPad - Mobotix T24 - ekey - Denon 2313 - Russound C5 (RIO over TCP Plugin) -

          Kommentar


            #6
            Hinweis zum Ekey-Fingerprint-UDP

            Hallo Marcus, Niko,

            sorry für das Ausgraben dieses alten Threads, aber evtl. ja für die Mitleser interessant.

            Ich hatte lange das Problem bei mir, dass der von Niko gepostete Code bzgl. Ekey-Fingerprint bei mir Null,Null was bewegt hat. Das Log blieb einfach leer.

            Nach dem Update auf die Dev-Versionen des NW-Plugins und einiger anderer habe ich dann plötzlich Fehlermeldungen entdeckt das es wohl ein UTF-8 Problem innerhalb des UDP's gibt und daher die Logik nie angetriggert worden ist.
            Nach einer leichten temporären Modifikation des NW-plugins (ersetze decode() durch decode("utf-8", "ignore")) kam dann die Wahrheit ans Licht, nämlich das bei mir warum auch immer der EKEY-UDP-Converter mit dem standardmäßig durch EKEY gesetzten Delimiter = _ wohl Probleme beim decode hat. Daraufhin habe ich diesen in der EKEY-UDP-SW auf Delimiter = ; gesetzt und schon klappt es wunderbar mit dem NW-Plugin und der Logik von Niko.

            Daher auch an dieser Stelle meinen besonderen Dank an Euch beide! Bin nun wieder ein paar % weiter in der Migration von meinem <sagichnicht> auf smarthome.py!

            @Marcus: Macht es evtl. Sinn den decode("utf-8", "ignore") dauerhaft im NW-Plugin einzubauen? Würde dann eben keine Exception mehr werfen sondern dann eben weiter durchlaufen. Brauche es nun nicht mehr, macht es aber evtl. für die Nächsten einfacher.

            Cheers,
            Oliver

            Kommentar


              #7
              Hallo Oliver,

              Zitat von Sandman60 Beitrag anzeigen
              @Marcus: Macht es evtl. Sinn den decode("utf-8", "ignore") dauerhaft im NW-Plugin einzubauen? Würde dann eben keine Exception mehr werfen sondern dann eben weiter durchlaufen. Brauche es nun nicht mehr, macht es aber evtl. für die Nächsten einfacher.
              ich denke, es schadet nicht. Ich habe es in develop eingebaut.

              Bis bald

              Marcus

              Kommentar


                #8
                Ich kram den alten Thread mal wieder hoch.

                Auch ich hab von eKey den Fingerprint-Reader mitsamt multi REG und eben dem "CV LAN". Der schickt inzwischen fleissig UDP-Telegramme und ich krieg die aber nicht in die Logik...
                ich hab das network-Plugin aus dem develop.

                Ich hab mal das von Niko verwendete Grundgerüst als Ausgangslage verwendet:

                plugin.conf
                Code:
                [nw]
                    class_name = Network
                    class_path = plugins.network
                    # ip = 0.0.0.0
                    # tcp = yes
                    # tcp_acl= 127.0.0.1 | 192.168.0.34
                    port = 56000
                    udp = yes
                    udp_acl= *
                Frage hierzu gleich: ohne den Eintrag "port" passiert lt. Log erstmal gar nichts, soll das so? Aktuell kein Problem, aber wenn ich mal einen anderen UseCase habe, wo UDP/TCP Nachrichten versendet werden sollen, wäre das auf einem anderen Port sauberer?

                items.conf
                Code:
                [I]leer[/I]
                Da brauche ich erstmal nichts, weil ich kein item brauche, sondern nur logic.

                logic.conf
                Code:
                [fingerprint]
                    filename = 'fingerprint.py'
                    # nw = yes
                    nw_udp_listen = 0.0.0.0:56000  # port number
                da bin ich mir nicht ganz sicher, obs das "nw=yes" braucht?

                fingerprint.py
                Code:
                [I]ist soweit fast identisch wie Nikos oben - ist ja der gleiche String, der gesendet wird.[/I]
                Ich erhalte aber gleich direkt im Log einen entsprechenden Eintrag:

                smarthome.log
                Code:
                2016-01-05 22:24:23 INFO     Main         Ignoring input 1#0001#TOM#1#7#1#80207xxx#TUER#1#-. Format not recognized.
                Wie krieg ich den ungefiltert in die logic rein? Einfluss auf das UDP-Paket hab ich natürlich keines?
                Danke für einen Anstupser!

                Thomas.

                Kommentar


                  #9
                  Hi Thomas,

                  rein "out of the brain"... Bei mir hat das ewig nicht funktioniert da mein EKEY ein anderes Trennzeichne verwendet hat und dadurch hat die Payload nicht gepasst bzw. war nicht valide. Erst als ich im Ekey-Tool das verändert habe lief es. Schau Dir mal den Artikel hier an, evtl. ist das ja auch Dein Problem.

                  Bei mir sieht die plugin.conf so aus (für x.y steht natürlich eine valide IP):
                  Code:
                  [nw]
                      class_name = Network
                      class_path = plugins.network
                      udp_acl= 127.0.0.1 | 192.168.x.y
                      port = *
                      udp = yes
                  logic.conf (für xxxx steht natürlich ein valider Port), nw=yes muß sein:
                  Code:
                  [Logic_Ekey]
                      filename = ekey.py
                      nw_udp_listen = xxxx  # port number
                      nw = yes
                  Hoffe die Infos helfen Dir weiter.
                  Cheers,
                  Oliver

                  Kommentar


                    #10
                    Zitat von Sandman60 Beitrag anzeigen
                    Hi Thomas,

                    rein "out of the brain"... Bei mir hat das ewig nicht funktioniert da mein EKEY ein anderes Trennzeichne verwendet hat und dadurch hat die Payload nicht gepasst bzw. war nicht valide. Erst als ich im Ekey-Tool das verändert habe lief es. Schau Dir mal den Artikel hier an, evtl. ist das ja auch Dein Problem.

                    Bei mir sieht die plugin.conf so aus (für x.y steht natürlich eine valide IP):
                    Code:
                    [nw]
                    class_name = Network
                    class_path = plugins.network
                    udp_acl= 127.0.0.1 | 192.168.x.y
                    port = *
                    udp = yes
                    logic.conf (für xxxx steht natürlich ein valider Port), nw=yes muß sein:
                    Code:
                    [Logic_Ekey]
                    filename = ekey.py
                    nw_udp_listen = xxxx # port number
                    nw = yes
                    Hoffe die Infos helfen Dir weiter.
                    Cheers,
                    Oliver
                    Danke für die Hilfe,

                    aber wenn ich "port = *" in der plugin.conf eingebe, passiert gar nix (=kein Eintrag im Log), erst wenn da wieder der Port ohne Wildcard steht, gehts weiter. Aber auch mit aktiviertem "nw=yes" in der logic.conf (hatte ich vorher natürlich auch probriert) erhalte ich nach wie vor den genannten Fehler.

                    In der CV LAN-Konfigurations-Software kann ich den Delimiter zwar ändern, aber das hat zwei Probleme
                    1. den Durchschuss "|" kann ich dort gar nicht eingeben, den nimmt das Programm eh nicht an.
                    2. den notwendigen Aufbau mit "item" oder "logic" als ersten Parameter krieg ich dadurch auch nicht hin.
                      (ich hab mal versucht einfach den Payload von eKey manuell zu übertragen, aber ich müsste "logic|fingerprint|1#0001#TOM#1#7#1#80207xxx#TUER#1#-" versenden, und das rote verschickt der eKey ja nicht! Damit kann ich dann die Logik antriggern und den Payload weiterverarbeiten...

                    Wie hast Du oder Niko es denn dann geschafft, den eKey-Payload "AS IS" in die Logik zu kriegen? Da muss noch ein anderer Trick dahinter stehen, befürchte ich.

                    Gruß,
                    Thomas.

                    Kommentar


                      #11
                      Hi Thomas, wie gesagt ich habe den Delimiter auf ; (Strichpunkt) geändert, sowohl in der Logik als auch im EKEY. Danach lief es einwandfrei. Vor die Payload muß auch nichts gestellt werden. Bei mir sieht die payload allerdings auch wesentlich einfacher aus, k.A. ob die bei deinem Ekey anders ist, aber bei mir sind da bspw. nur Zahlen drinnen, kein ASCII usw. Hast Du es schon mal mit dem Delimiter ; versucht?

                      Kommentar


                        #12
                        BTW: Bist Du auf der Develop und hast die Änderung von oben (decode("utf-8", "ignore")) auch drinnen? Hatte bei mir zumindest mehr in das Log gebracht.

                        Kommentar


                          #13
                          Zitat von Sandman60 Beitrag anzeigen
                          Hi Thomas, wie gesagt ich habe den Delimiter auf ; (Strichpunkt) geändert, sowohl in der Logik als auch im EKEY. Danach lief es einwandfrei. Vor die Payload muß auch nichts gestellt werden. Bei mir sieht die payload allerdings auch wesentlich einfacher aus, k.A. ob die bei deinem Ekey anders ist, aber bei mir sind da bspw. nur Zahlen drinnen, kein ASCII usw. Hast Du es schon mal mit dem Delimiter ; versucht?
                          Der Delimiter ";" hilft mir auch nicht weiter. Aktuell bricht das Plugin ab, weil es eben keine Zuordnung zu "logic", "item" oder "log" findet. Meiner Meinung nach hier

                          plugins.network-Klasse Z. 176ff
                          Code:
                              def parse_input(self, source, dest, data):
                                  if dest in self.generic_listeners:
                          [B][COLOR=#FF0000]            inp = data.split(self.input_seperator, 2)  # max 3 elements[/COLOR][/B]
                                      if len(inp) < 3:
                                          logger.info("Ignoring input {}. Format not recognized.".format(data))
                                          return False
                          Da passt auch kein "1;0001;TOM;1;7;1;80207xxx;TUER;1;-" durch, weil die Klass ja drei Paramenter per "|" getrennt erwartet, und ohne der Payload unerwartet ist.

                          Wenn ich hier weitersehe (ab Zeile 186ff), können auch die anderen Infos nicht weitergegeben werden, sofern kein "logic", "item" oder "log" als erster Parameter für die generischen Listener übertragen werden:
                          Code:
                          [COLOR=#FF0000][B]            if typ == 'item':[/B][/COLOR]
                                          (...)
                          
                          [COLOR=#FF0000][B]            elif typ == 'logic':[/B][/COLOR]
                                          (...)
                          
                          [COLOR=#FF0000][B]            elif typ == 'log':[/B][/COLOR]
                                          (...)
                          
                                      else:
                                         [B] logger.error("Unsupporter key element {}. Data: {}".format(typ, data))[/B]
                                          return False
                          Entweder muss der Payload irgendwie bevor er ins Plugin rauscht bearbeitet werden und die beiden Parameter "logic|fingerprint" vorangestellt werden (der eKey liefert ja keine "logic|fingerprint|" als Präfix). Weil ja wie gesagt, per "logic|fingerprint|eKey-payload" läuft alles wie es soll.
                          ...oder ich hab irgendwas anderes übersehen...

                          PS: ja, ich bin auf develop, ich finde zwar kein "decode("utf-8", "ignore")", aber dafür ein paar "data.decode(errors="ignore")"...? Die im master nicht zu finden sind. Meinst Du das?

                          Danke für Die Hilfe!
                          Thomas.

                          Kommentar


                            #14
                            Hi Thomas,

                            ich habe es noch nie direkt übers Antriggern von Logik probiert, aber mein Vorgehen könnte ein Workaround für Dich sein. Ich habe ein Item vom typ str, das auf die UDP-Pakete hört und die Logik wird dann vom Item getriggert.

                            item:
                            Code:
                            [Main]
                                [[Ekey]]
                                    name = eKey string
                                    type = str
                                    nw_udp_listen = <ip>:<port>
                                    enforce_updates = True
                            logic.conf:
                            Code:
                            [ekey]
                                filename = eKey.py
                                watch_item = Main.Ekey
                            Vielleicht klappt es so...

                            Gruß, Waldemar

                            Kommentar


                              #15
                              Hmmm, ich steh irgendwie auf dem Schlauch... Also, bei mir wird das Plugin durch die LOGIK getriggert, welche in der logic.conf steht (s.o.). Dort "hört" die Logik auf das nw-plugin.
                              Code:
                              [Logic_Ekey]
                                  filename = ekey.py
                                  nw_udp_listen = xxxx  # port number
                                  nw = yes
                              Items hab ich keine konfiguriert, sind m.E. auch nicht notwendig. Hatte ich mal zum testen, waren aber weder notwendig noch hilfreich. Klar habe ich welche konfiguriert, allerdings für spätere Auswertungen wie User usw., diese werden aber im Logikfile ekey.py verwendet, Code analog zu Niko.

                              Was mich immernoch irritiert ist Deine Payload. Bei mir sieht die bspw. so aus (habe die Seriennummer mit 99999999999999 unkenntlich gemacht), wenn bspw. User 1 mit Finger 9 sich erfolgreich angemeldet hat. Ich habe aber, ebenso wie Niko, den UDP-Converter:
                              Code:
                              1;0001;1;99999999999999;1;1
                              Beim Tracen oder manuellen auslösen wird sonst auch nichts übergeben.

                              Bzgl. decode: Ja, das müßte es gewesen sein, lässt sich leider aktuell bei mir nicht mehr nachvollziehen. Hast Du mal SH.PY im Debug-Mode gestartet und geschaut was dann beim Dispatching gemeldet wird? Da sollte ja ein "{}: incoming connection from {} to {}" kommen, dann siehst Du die Payload. Bei mir kam da damals eben gar nix wenn der Delimiter nicht auf ; gestanden war.

                              Kommentar

                              Lädt...
                              X