Alarmanlagen-Forum - Alarmforum - Fachforum für Sicherheitstechnik

Hallo,

ich möchte eine Auswertung der Contact ID Message in einem externen Programm durchführen.
Dazu habe ich einen ServerSocket in Java erstellt.
Dann in der Lupus die Reporting url ip://2222@192.168.7.20:8080/CID eingetragen.

Am ServerSocket erhalte ich nun die Meldung.
[2222 183456010011615]

Soweit so gut.
Allerdings steht jetzt im Systemereingnisprotokoll die Meldung
url='ip://2222@192.168.7.20:8080/CID', ret=-403, reason='ACK-Zeitüberschreitung', event=456, text='Area 1 User 1 user: Home Modus'

Man muss also vom ServerSocket irgendwie die Meldung "quittieren".

Welche Daten muss ich da zurücksenden?

Viele Grüße.

Ein Neuling.

Hier schreibt man folgendes:
http://www.justsmarthomes.com/viewtopic.php?t=784

--------------Zitat-------------------------
To acknowledge this message the monitoring server must send back an identical copy of this message.
-------------- Zitat Ende ------------------

Aber schau mal hier:
http://www.alarmforum.de/Thread-Contact-...-Webserver

Da wird genau dein Anliegen im Detail besprochen. Vielleicht ist da was für dich dabei.
Ist zwar die X1 aber die Übertragung ist ja dieselbe.

Hier auch noch was:
https://stackoverflow.com/questions/2421...ver-tcp-ip

-------------- Zitat--------------
What I found out about Contact ID over IP (by trying) is:

It uses TCP
It expects an ACK symbol as response (at least mine does)

The most basic script for just collecting events then would be:

while true ; do nc -l 1337 < ack.txt >> contact_id.log ; done

ack.txt here contains an ack-character
------------ Zitat Ende ---------------------

Such mal in Google nach Contact ID over IP.
Da kommen die Treffer oben her.

Gruß Christian

Danke für deine Antwort.
Die genannten Beiträge hatte ich auch schon alle gelesen.
Leider funktioniert keiner von denen. Weder irgendein Buchstabe noch eine Kopie der Meldung noch ein ACK.
Ich suche weiter.

Ah ok dann hast du das schon durch.

Nun ich könnte mir vorstellen, das der besagte Buchstabe einfach die Prüfziffer ist.
Ich habe hier ja auch ein Konstrukt wo ich CID-Message auswerte allerdings ist das Analog und die
Anrufsteuerung macht hier ein Asterisk auf einem Raspberry.

Hier mal die Prüfsummenberechung der CID-Message in PHP.
Basierend darauf das die CID-Message 15 +1 ist.
Probier mal ob du da was mit anfangen kannst.
Ich schau auch nebenher mal ob ich da was für dich finde.
Interessiert mich auch ein wenig.

# http://www.microchip.com/forums/m99720.aspx

<php
$cid = "2323183402037016";

$cidLen = 15; // Länge ohne Prüfziffer
$cid = substr($cid, 0, $cidLen);
$cidSum = 0;

for ($t = 0; $t < $cidLen; ++$t)
{
$value = hexdec($cid{$t});
$add = $value == 0 ? 10 : $value;
$cidSum += (int)$add;
}

$probe = $cidSum / 15;
$check = (int) $probe * 15;
$subtract = $check == $cidSum ? $check : ((int) $probe + 1) * 15;
$crc = $subtract - $cidSum;
$crc = $crc == 0 ? 'F' : dechex($crc);

echo "<br>CID-CRC:" . $crc;
?>

Gruß Christian

Edit:
- Korrektur auf Hexadezimalsystem

Handelt es sich um eine xt1 oder xt2 (plus)
Lt Aussage vom Lupus Support kommen nur wenige mit dem proprietären CID Protokoll der xt1 zurecht. Ab der xt2 läuft alles im internationalen Standart.

(23-07-2017 18:16)funkistnichtalles schrieb: [ -> ]Handelt es sich um eine xt1 oder xt2 (plus)
Lt Aussage vom Lupus Support kommen nur wenige mit dem proprietären CID Protokoll der xt1 zurecht. Ab der xt2 läuft alles im internationalen Standart.

Ist eine XT2 Plus.

(23-07-2017 17:58)smith007 schrieb: [ -> ]Ah ok dann hast du das schon durch.

Nun ich könnte mir vorstellen, das der besagte Buchstabe einfach die Prüfziffer ist.
Ich habe hier ja auch ein Konstrukt wo ich CID-Message auswerte allerdings ist das Analog und die
Anrufsteuerung macht hier ein Asterisk auf einem Raspberry.

Hier mal die Prüfsummenberechung der CID-Message in PHP.
Basierend darauf das die CID-Message 15 +1 ist.
Probier mal ob du da was mit anfangen kannst.
Ich schau auch nebenher mal ob ich da was für dich finde.
Interessiert mich auch ein wenig.

# http://www.microchip.com/forums/m99720.aspx

<php
$cid = "2323183402037016";

$cidLen = 15; // Länge ohne Prüfziffer
$cid = substr($cid, 0, $cidLen);
$cidSum = 0;

for ($t = 0; $t < $cidLen; ++$t)
{
$add = (int) $cid{$t} == 0 ? 10 : (int) $cid{$t};
$cidSum += (int)$add;
}

$probe = $cidSum / 15;
$check = (int) $probe * 15;
$subtract = $check == $cidSum ? $check : ((int) $probe + 1) * 15;
$crc = $subtract - $cidSum;
$crc = $crc == 0 ? 15 : substr($crc, -1);

echo "<br>CID-CRC:" . $crc;
?>

Gruß Christian

Danke Christian.
Ist aber leider auch nicht möglich.
Die Lupus gibt in der Beschreibung 18 Stellen an:
Aufbau Contact ID Syntax:
Nachricht
ACCT MT QXYZ GG C1 C2 C3

So erhalte ich die Nachricht auch: [2222 183456010011615]

Als Beispiel wird in der Lupus Beschreibung dann später eine 15-stellige Nachricht angegeben:
Das Konto 1234 meldet einen Perimeter-Alarm in Zone 15 der Area 1:
<1234 18 1131 01 015 8>

Die Beschreibung widerspricht sich selbst. Ich habe bei Lupus angefragt und warte auf Antwort.

Hast du noch ein paar Beispiel CID-Nachrichten?
Wenn man bei der CID 2222 183456010011615
Nur das Berücksichtigt (17 +1): 2222 1834560100116 1 (1 = CRC) (die 5 mal weggelassen)
Dann passt es. Mag jetzt Zufall sein daher wären ein Paar andere Beispiele hilfreich.

Da die CRC auch 15 sein kann, dachte ich erst, dass hier das der Fall ist.
Aber das haut bei der gegebenen Beispiel-CID nicht hin.

Ich hab mal in der Anleitung zur XT2 Plus nachgelesen.
Du hast recht das ist da im Gegensatz was du bekommst nicht identisch.
Das Angabe C1C2C3 sind 3 Ziffern. Die Bedeutung ist nur Abhängig von dem was in GG steht.
Daraus ergibt sich dann das bei ACCT MT QXYZ GG C1 C2 C3 = 15 Zeichen die Nachricht bilden sollten ohne CRC.

2222 18 3456 01 0 0 1 Rest= 1615
ACCT MT QXYZ GG C1 C2 C3

Bei Ademco selber wird mit Modulo 15 gerechnet.
Hier muss beim Zusammenzählen allerdings die Prüfziffer miteinberechnet werden.
Ist das Ergebnis gleich 0 ist die Nachricht OK.

Ersetzte:
- $crc = $subtract - $cidSum;
+ $crc = $cidSum % 15; // 0 = OK,

Das habe ich mal angewandt auf 18 Stellen und erhalte das erwartete Ergebnis 0.

Bei 19 Klappt es nicht. Scheint als wenn die 5 am Ende da so nicht hingehört.

Gruß Christian

Hallo Christian,

anbei noch ein paar Nachrichten.

Home Modus 1: [2222 183456010011615]
Arm: [2222 18340101001D50B]
Einbruchalarm: [2222 18113001002BB09]
Disarm: [2222 18140101001C309]

Hier sind übrigens auch hexadezimale Zeichen enthalten.

Vielen Dank für deine Mühe.

Hi Keloba,

keine Ursache, solche Dinge sind immer eine willkommene Herausforderung für mich. ;-))
Ja das mit dem Hexadezimal ist richtig. Bei CID wird das verwendet.
Habe ich in meiner CRC Berechnung aber vergessen einzubeziehen. (Ergänze ich aber gleich).

Ich habe jetzt ein wenig mit dem Modulo Zahlen gespielt und auch Tests mit der CID Zeichenanzahl gemacht (15-19).
Ich bin hier aber nach dem gegebene Verfahren der normal bei CID üblich ist zu keinem brauchbaren Ergebnis gekommen.
Entweder hat Lupus da ein eigenes CRC-Verfahren oder die übermittelte CID-Nachricht, wenn auch länger als normal, besitzt am Ende keine Prüfziffer.

In dem Fall kannst du obiges Verfahren nutzen um dir die Prüfziffer berechnen zu lassen und diese mal als Acknowledge übermitteln.
Hier musst du dann als $cidLen = 19 einstellen.

Bin aber weiter am Ball.
Hab da so eine Vemutung was die letzten 4 Ziffern sein könnten.

Gruß Christian

Nachtrag:
Also CRC32/CRC16 und CRC8 ist es leider auch nicht.

Normal wird bei CID selten hex verwendet obwohl es gültig ist.
Wenn man die üblichen Melde-Codes ansieht findet man da kein Hex.
Von daher sieht es danach aus als wenn die letzten 4 Ziffern der CID-Nachricht eine andere Bedeutung haben.
Ob es jetzt eine Prüfziffer ist vermuten wir ja nur. Du kannst ja mal die letzten 4 Zeichen als Ackn zurücksenden und schauen was passiert.

So haben wir ja jetzt 2 Möglichkeiten.
- Prüfziffer berechnen mit 15 stelliger CID
- zurücksenden der letzten 4 Ziffern

Probier mal und schau was passiert.

Hallo Christian,was ich noch nicht ganz verstehe.
Wenn als Ack die Prüfziffer zurückgeschickt werden soll, ist es doch immer die letzte Stelle der empfangenen Zeichenfolge.
Bei [2222 183456010011615] wäre es die 5. Wieso jetzt die Prüfziffer nochmal berechnen. die ist ja schon da.
Hab versucht, wie in diesem Fall die 5 zurückzuschicken, oder die [2222 183456010011615] oder die [2222183456010011615] oder die 2222 183456010011615 oder die 2222183456010011615\n.
Haut alles nicht hin.

Habe auch schon SIA (https://www.securityindustry.org/SiteAss...eview.pdf) angeschaut. Dort steht, wie man ein Ack versendet. Leider ist aber die Erzeugung der CRC nicht aufgeführt. Also auch Sackgasse.

Hoffentlich bekomme ich von Lupus ein Feedback.

Nun wie ich schon sagte wir vermuten hier ja nur, dass die letzte Ziffer die Prüfsumme ist.
Wenn sie es ist hättest du ja Recht.

Das mit dem Neuberechnen war ja auch nur eine weiterer Versuch von Möglichkeiten.
Wir tappen da ja noch im Dunkeln und da sollte man jede Möglichkeit wenigstens einmal probiert haben.

Das habe ich eben gefunden:
https://www.symcon.de/forum/threads/2968...esen/page3

Geht auch um eine XT2Plus.
Der ursprüngliche Sinn war es die XT2 auszulesen aber hinter her auf Seite 2 wird es interessant.
Da bezieht man sich zwar auf die Secvest aber das Prinzip sollte dasselbe sein.

Interessant fand ich, dass der Kollege auch ein Problem hat mit dem Ackn.
Da erwähnt er eine Neuberechnung der CRC und zwar CRC-16_ARC.

Hier beschreibt er den detaillierten Weg der Kommunikation.
https://www.symcon.de/forum/threads/3374...-IP-Symcon

Was ich bisher herausgelesen habe ist es wohl nicht unbedingt so, dass es ausreicht das Datagramm
einfach zurückzusenden.
Ich les mich da grade mal durch und schau ob wir da was Brauchbares finden.

Gruß Christian

Nachtrag:

Also CRC16 ARC ist es hier nicht.
Mit reveng habe ich auch kein Polynom finden können bei den 4 Beispielen.

Wenn ich das richtig sehe benutzt er da auch SIA.
Was für eine Meldung bekommst du denn da?
Weil das Ganze in dem Thread geht wohl um SIA, da der Aufbau dort anders ist als bei CID.
Vielleicht kommen wir da weiter.

Hab da noch was bei GitHub gefunden:
https://github.com/devius-lupus/mylupus

Der Kollege hat da was in JS gebastelt.
Auch einen CID receiver aber der scheint mir nur die Ausgaben anzuzeigen.
Schau dir mal den cid_handler.js an.
Da er folgendes stehen: socket.write("Welcome " + socket.name + "\n");
Als Bemerkung allerdings Todo.

Da du dein Projekt in Java hast sollte es mit etwas Anpassung auch gehen.
Schau mal ob du damit was anfangen kannst.

So, jetzt habe ich von Lupus Bescheid bekommen.
Eigentlich soll man nur ein ACK also 0x6 oder dezimal 6 senden. Das hatte ich auch schon ausprobiert.
Funktioniert nicht mit java. setTcpNoDelay hatte ich auch probiert.
Aber momentan nimmt der das eine byte nicht an.
Wollte dir nur kurz Meldung geben.

Übrigens:
Die Prüfziffernberechnung nach fletcher bezieht sich auf die letzten 4 bytes.
Also bei [2222 18140101001C309] ergibt der untere code 0xC309.
/**
* Fletcher Checksum.(LUPUS version, 16-bit)
*/
static unsigned int fletcher_sum(char* data, int len) {
unsigned int sum1 = 0x0, sum2 = 0x0;
while (len) {
unsigned int tlen = (len > 256) ? 256 : len;
len -= tlen;
do {
sum1 += *data++;
sum1 = (sum1 & 0xff);
sum2 += sum1;
sum2 = (sum2 & 0xff);
} while (--tlen);
}
return sum2 << 8 | sum1;

Das funktioniert auch so.

---

So. Hab es jetzt hinbekommen.
Einfach nur ein binäre 6 sende und im Protokoll steht dann auch:
Erfolgreich Reporter url='ip://2222@192.168.7.20:8080/CID', ret=0, reason='', event=401, text='Area 1 User 1 user: Unscharf (Remote)'

Vielen Dank Christian.

Super. Danke dir für die Info.
Da hätten wir lange rätseln können. ;-)

Ist auf jeden Fall eine sehr hilfreiche Information für andere mit dem Problem.
Auch für mich da ich hier auch noch ein Prüfsummenproblem habe.
Vielleicht ist Fletcher ja das was ich immer gesucht habe.

Nuja es gibt ja auch zig Prüfsummen-Algorithmen.
Ein Lob an den vorbildlichen Lupus-Support.

Na dann wünsche ich dir noch viel Erfolg mit deinem Projekt.
Und wenn mal was ist dann einfach Fragen. ;-)

Gruß Christian

Falls auch mal jemand sowas in java machen möchte, hier mal eine Testklasse.

(25-07-2017 21:24)keloba schrieb: [ -> ]Falls auch mal jemand sowas in java machen möchte, hier mal eine Testklasse.

Code:

package de.cid;

import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.net.ServerSocket;
import java.net.Socket;
import java.util.regex.Matcher;
import java.util.regex.Pattern;

public class CIDTestServer {

    // Start des Testservers auf Port 8090
    public static void main(String[] args) throws IOException {
        CIDServer server = new CIDServer();
        server.start(8090);
    }

    public void start(int port) throws IOException {
        ServerSocket server = new ServerSocket(port);
        while (true) {
            try {
                Socket client = server.accept();
                CIDClient cidClient = new CIDClient(client);
                Thread th = new Thread(cidClient);
                th.start();
            } catch (IOException e) {
                e.printStackTrace();
            } finally {
            }
        }
    }
    
    class CIDClient implements Runnable {
        Socket client;
        OutputStream out;
        InputStream in;
        CID cid;

        public CIDClient(Socket client) throws IOException {
            this.client = client;
            this.client.setTcpNoDelay(true);
            out = client.getOutputStream();
            in=client.getInputStream();
        }

        @Override
        public void run() {
            try {
                StringBuilder sb=new StringBuilder();
                while (client.isConnected()) {
                    int c=in.read();
                    if (c==-1)
                        break;
                    sb.append((char)c);
                    if ((char)c==']') {
                        // ACK als Bestätigung zurück schreiben
                        out.write(6);
                        cid=new CID(sb.toString());                        
                        System.out.println("CID: "+sb.toString());
                        sb=new StringBuilder();
                    }        
                }
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }    
    
    class CID {
        Pattern pattern = Pattern.compile("(\\[(\\d{4})(\\s)([1][8])([123])([0-9a-fA-F]{3})([012]{2})(\\d{3}).*\\])");
        private String acct;
        private String mt;
        private String q;
        private String xyz;
        private String gg;
        private String c1;
        
        public CID(String msg) {
            parse(msg);
        }
        
        public void parse(String msg) {
            Matcher matcher = pattern.matcher(msg);
            if (matcher.matches() && matcher.groupCount()==8) {
                // ACCT MT QXYZ GG C1 C2 C3
                acct=matcher.group(2);
                mt=matcher.group(4);
                q=matcher.group(5);
                xyz=matcher.group(6);
                gg=matcher.group(7);
                c1=matcher.group(8);
            }        
        }
    }
    
}

Klasse!!! Danke für den Tipp mit out.write(6). Damit wird das ACK bei der Lupusec XT2 Plus endlich akzeptiert.
Ich hatte vorher versucht das ACK als im Stream als \u0006 über PrintWriter zu schreiben. Das hatte nicht funktioniert.

Na super, Schmupu.
Wie verarbeitest du die Daten weiter bzw. welches Projekt hast du dahinter stehen?
Ich entwickle gerade ein Addon für openhab2.