Mobotix MxMessageSystem per UDP

Einklappen
X
 
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge
  • Gerrit
    MS Profi
    • 26.08.2015
    • 937

    Mobotix MxMessageSystem per UDP

    Hat schon jemand das neue Mobotix MxMessageSystem integriert? Hier kann man wohl per UDP Informationen/Events abgreifen, die vorher nur sehr schwer zu bekommen waren. Z.B. welche RFID Karte gerade verwendet wurde oder welche Nummer am Keypad gedrückt wurde. "Leider" sind die Nachrichten verschlüsselt und man muss wohl im Beispielcode schauen, wie die Verschlüsselung gemacht wurde. Man kann sich die Nachrichten entweder per Broadcast oder Multicast zuschicken lassen. Nach meinem Verständnis müsste Broadcast direkt funktionieren, konnte aber bisher nichts per Loxone empfangen, auch nicht verschlüsselt. Sollte aber anhand des Beispiel Programms erkennbar sein.

    Den angesprochenen SDK gibt es mit einer C++-Anwendung: http://developer.mobotix.com/ (gleich der erste Punkt)

    EDIT: Auf den ersten Blick sieht es so aus, als ob der wichtige Teil closed source in einer Library ausgelagert wurde. D.h. Reengineering vom Protokoll wird schwierig und man muss zwingend die C++-Library ansprechen. Wenn sich jemand die Mühe machen will, darauf eine HTTP API o.ä. zu packen bitte Bescheid geben. Ich schau es mir wahrscheinlich auch bald genauer an und werde ähnliches versuchen.
    Zuletzt geändert von Gerrit; 30.06.2016, 12:13.
  • Marco
    Smart Home'r
    • 12.09.2015
    • 35

    #2
    Hallo Gerrit,

    ich bin zur Zeit auch dabei, die Integration meiner T25 mit BellRFID, DoorMaster, IO-Box und MxDisplay weiter auszubauen und habe mich mit dem Thema beschäftigt.

    Bist du du bez. dem Auswerten der MxNachrichten im Miniserver schon weitergekommen?

    Gruß
    Marco

    Kommentar

    • Gerrit
      MS Profi
      • 26.08.2015
      • 937

      #3
      Zumindest mit der T24 und Keypad und Doormaster gibt es aktuell einen Bug, dass bei Verwendung der Messages das Keypad ausfallen kann (bei mir schon geschehen, hilft nur ein Modul-Neustart). Der Bug sollte in der neuen Firmware .56 gefixed sein, aber bei mir besteht er noch. Support will den Fehler aber nicht noch mal anschauen solange ich nicht eine Autokonfiguration (= Alle Einstellungen nochmal vornehmen) durchgeführt habe. Vor der .55 hatte das Feature aber noch ohne größere Probleme funktioniert.

      Habe aber auch noch nicht allzuviel Arbeit in die Integration gesteckt. Habe das Beispiel vom Mobotix SDK bisher so umgeschrieben, dass es die empfangenen Daten entschlüsselt per UDP an den Miniserver schickt. Solche Nachrichten kommen dann auch 1-3s früher an, als die Nachricht per HTTP an den Miniserver, wenn man wie normalerweise eine entsprechende Aktion in der T24/T25 konfiguriert. Wie geschrieben gibt es keine Möglichkeit die Nachrichten im Miniserver zu entschlüsseln, d.h. man braucht einen Raspi o.ä., auf dem das Programm dann läuft.
      Aber das Beispiel läuft bisher nur auf meinem Laptop und es noch nicht zu 100%ig sicher, ob die Bibliotheken von Mobotix auch auf einem Raspi laufen. Zudem müsste sich das nochmal jemand mit mehr C++ Kenntnissen anschauen. Auch im Hinblick, dass das dann ja als Dienst laufen soll.

      Der angepasst Message-receive Code:


      Code:
      bool
      Adapter::receive( const char* path, Json::Value value_j) { // {{{2
      
          struct sockaddr_in si_other;
          int s, slen=sizeof(si_other);
      
          if ( (s=socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) == -1)
          {
              cout << "socket failed\n" << endl;
          }
      
          memset((char *) &si_other, 0, sizeof(si_other));
          si_other.sin_family = AF_INET;
          si_other.sin_port = htons(PORT);
      
          if (inet_aton(SERVER , &si_other.sin_addr) == 0)
          {
              cout << "inet_aton() failed" << endl;
          }
      
          //send the message
          if (sendto(s, path, strlen(path) , 0 , (struct sockaddr *) &si_other, slen)==-1)
          {
              cout << "sent udp message failed\n" << endl;
      
          }
      
          close(s);
      
      
          if (verbose) {
              cout << endl << "receive: path=" << path << " value=" << value_j << endl;
          } else {
              cout << endl << path << "=" << value_j << endl;
          }
          return true;
      } // Adapter::receive() }}}2

      Kommentar

      • Marco
        Smart Home'r
        • 12.09.2015
        • 35

        #4
        Danke für deine Antwort!
        Ich habe jetzt auch nicht so die C / C++ Programmiererfahrungen... An eine 'Weiterreichung' per http Reqeust habe ich gestern auch noch gedacht. Also z.B. wenn ein Benutzer ne RFID-Karte ans Keypad (bzw. bei mir ans BellRFID) hält, dass dann eine MxNachricht an die T25 gesendet wird, wo per Ereignisüberwachung als Aktion ein HTTP-Request gegen den Miniserver ausgelöst wird. Hattest du das gemeint?

        Kommentar

        • Gerrit
          MS Profi
          • 26.08.2015
          • 937

          #5
          Meinte jetzt erstmal die Funktionen ohne das MxMessageSystem, wo man aber nur allgemeine Ereignisse wie "RFID oder PIN Zugriff erteilt" verbinden kann. Aber stimmt man könnte nun auf verschiedene RFID oder PIN Events eindeutige Nachrichten verschicken und aufgrund dessen dann HTTP Events. Mir ging es dabei aber auch um mehr Flexibilität und Schnelligkeit und ich gehe davon aus, dass der HTTP request an sich bei der Mobotix eine gewisse Verzögerung mit sich bringt, die es per UDP nicht gibt, anders kann ich mir die Verzögerungen aktuell nicht erklären. Auch würde ich gerne direkt in Loxone die RFID Karten IDs und Pin Codes auswerten können, um z.B. eine dynamische PIN zu ermöglichen. Aber es scheint so, als ob man Parameter der Messages nicht auswerten kann.

          Kommentar

          • RiverRaid
            LoxBus Spammer
            • 25.08.2015
            • 299

            #6
            Hi,

            Ich bin durch suchen auf diese Seite gestossen:



            Habe das jetzt bei mir ausprobiert, funktioniert 1A Ab jetzt kann ich per Schaltuhr über Loxone steuern, wer wann Zutritt hat :-)

            Kommentar


            • Gerrit
              Gerrit kommentierte
              Kommentar bearbeiten
              Ja das ist das was ich meinte. Aber sind die Netzwerkmeldungen nicht langsam?
              Wie schnell ist die Netzwerkmeldung zu Loxone bei dir? Also wieviele Sekunden vergehen vom PIN/RFID Event bis zur Verarbeitung in Loxone? Also ab dem Zeitpunkt wenn jemand die Schlüsseltaste drückt oder die RFID Karte erkannt wird.
          • cko
            Smart Home'r
            • 25.08.2015
            • 76

            #7
            Hallo, also habt Ihr auch diese Verzögerung von der t25 zu loxone? Meine Klingel die über einen http-Befehl mittels Miniserver ausgelöst wird - löst immer mit ca. 2-3 Sekunden Verzögerung aus.

            Danke

            Kommentar


            • Gerrit
              Gerrit kommentierte
              Kommentar bearbeiten
              Kannst du mal in den Systemmeldungen in der T25 schauen wieviele Sekunden es genau sind. Da müsste zuerst etwas mit "voip" stehen und dann darauf die Zeile mit dem Netzwerk/HTTP-call. Vielleicht kannst grad beide Zeilen hier posten.
          • RiverRaid
            LoxBus Spammer
            • 25.08.2015
            • 299

            #8
            Gerrit Das dauert bei mir genauso lange, wie der "alte weg" über den http-Aufruf wenn RFID korrekt war, also so 1-3 Sekunden

            Kommentar

            • cko
              Smart Home'r
              • 25.08.2015
              • 76

              #9
              2017-01-07 11:31:27 IPMSG miniserver[9603] Netzwerkmeldung an 192.168.178.150:80 gesendet. 220 Byte in 0.907s.
              11:31:28 EMAIL NotifyMail[9602] Start von E-Mail-Transfer an Server smtp.gmail.com.
              11:31:29 IPMSG miniserver[9615] Netzwerkmeldung an 192.168.178.150:80 gesendet. 220 Byte in 0.873s.
              11:31:29 EMAIL NotifyMail[9602] E-Mail mit einem Anhang gesendet. 118815 Bytes in 1.1s gesendet.

              Kommentar

              Lädt...