HM protokol

Begonnen von martinp876, 30 Oktober 2013, 11:20:37

Vorheriges Thema - Nächstes Thema

martinp876

Hi,

mit Version 4135 habe ich etwas im Ablauf "wiederholen und löschen bei Protokoll-fehlern" aufgeräumt.
Das ganze soll nach der Beschreibung im Anhang funktionieren und entsprechend einstellbar sein.

Ein paar Baustellen sind noch offen -so z.B. minimalistischen handling von burst devices....

Fragen und Anregungen?

Gruss Martin

Joachim

Moin Martin,

auf sowas habe ich schon Lange gewartet.
Kannst Du das Pinnen, und aktuell halten, ggf, um weitere Infos erweitern.

Gruß Joachim
FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232

Samsi

Hallo Martin,

beim Ablauf mit Befehlen an burst devices ist mir heute etwas aufgefallen. Und zwar mit dem HM-CC-RT-DN.

Ich habe den auf burstRx = on und burstAccess = Auto gestellt, damit befehle (set desired temp)  sofort ausgeführt werden. Hat aber nicht funktioniert.  Ich bekam nur Fehler bei den Commands und Missing Acks.

Und das lag daran, das ich die beiden Regler zusammen mit 2 Plots in einem Raum hatte. Ich bin Drauf gekommen, das die Plots doch etwas Zeit auf der FB benötigen. Beim setzen der desired Temp wird aber gleich die Seite neu geladen und die Plots neu berechnet. Das dauert bei de FB ca. 5 Sekunden.

Ich vermute mal der Befehl wird an das Thermostat gesendet und dann kommen die Plots dazwischen und deshalb wird es nicht zeitnah beendet wenn das Device aufwacht und warten muss bis die Plots fertig sind, bevor es eine Antwort bekommt.

Aber bei den Tages Plots bekomme ich aber noch kein Disconnect vom HMLAN, das bekomme ich erst bei Wochen-Plots.


Grüße




FHEM 5.5 / BBB Debian Wheezy

Homematic CFG-LAN

HM-Sec-MDIR / HM-Sec-SD / HM-Sec-WDS / HM-LC-Sw2-FM / HM-Sec-SC / HM-LC-Sw1PBU-FM / HM-SCI-3-FM / HM-Sec-Key / HM-RC-Key3-B / HM-LC-Dim1TPBU-FM /  HM-CC-RT-DN / HM-PBI-4-FM / HM-RC-Key4-2 / HM-ES-PMSw1-Pl / HM-LC-Sw4-WM

martinp876

Hallo Samsi,

das Problem ist also eines von Plot. Das sollte - wenn es so lange dauert - in einen extra threat ausgelagert werden.
Gegen Verzögerungen anderer Funktionen kann ich erst einmal nichts machen. Evtl musst du das Konzept deiner Anzeige ändern - sorry.

Es ist sicher ein interessantes Thema - und wenn ich einmal dazu komme würde ich gerne daran basteln - aber wie gesagt - ein Problem von Plot. Ist auch verständlich - Plot liest lange Files, muss viel Filtern.... das kostet Performance. Es arbeitet erstaunlich gut.

Das set-kommando sollte eigentlich dann auf das nächste Wakeup warten und dann ausgeführt werden - korrekt?

Gruss Martin

Samsi

Hallo Martin,

ist schon Klar, das es ein Problem des Plots ist. Ich wollte Dir eigentlich nur mitteilen, was bei manchen Leuten auch die Ursache für Missing Acks sein könnten. Ich habe natürlich nachdem mir das aufgefallen ist, alle Plots in einen eigenen Raum verfrachtet und dann lief es.


ZitatDas set-kommando sollte eigentlich dann auf das nächste Wakeup warten und dann ausgeführt werden - korrekt?
In meinem Fall nicht, weil ich burstRX = on und burstAccess = auto gesetzt habe, also das er das Kommando gleich ausführt. Aufgrund  des reloads gibt das Pending Command aber einen Fehler weil der Plot ja auch sofort erstellt wird und mit der Ausführung des Kommandos kollidiert. Das Kommando war dann verloren, jedenfalls ware kein Pending CMD mehr da.

Nachdem die Plots dann in einem anderen Raum waren, wurde das Set-Command erwartungsgemäß sofort ausgeführt.

Wie gesagt nur ein Hinweis an Dich was auch zu Missing Acks führt. Vielleicht sollte ich das noch mal im Bereich 'Plots' posten?

Grüße


FHEM 5.5 / BBB Debian Wheezy

Homematic CFG-LAN

HM-Sec-MDIR / HM-Sec-SD / HM-Sec-WDS / HM-LC-Sw2-FM / HM-Sec-SC / HM-LC-Sw1PBU-FM / HM-SCI-3-FM / HM-Sec-Key / HM-RC-Key3-B / HM-LC-Dim1TPBU-FM /  HM-CC-RT-DN / HM-PBI-4-FM / HM-RC-Key4-2 / HM-ES-PMSw1-Pl / HM-LC-Sw4-WM

ulli

Hallo zusammen,

ich plane das Homematic Protokoll auf das RFM69 Modul zu portieren.

Dazu bräuchte ich einige Eckdaten, die ich leider nirgends herausgefunden habe:
* Wie ist die Datenrate? Ich habe unterschiedliche Aussagen auf der FHEM Homepage gefunden:
     1) BidCos(R) in the "AskSin" mode (20kHz datarate, FM). HomeMatic(R) Wireless devices use this protocol.
     2) HomeMatic: Für die Kommunikation mit HomeMatic Geräten @10 kHz Datenrate.
* Es ist Frequenz moduliert.
* Wie ist die Frequence Deviation?
* Liegt die Frequenz bei genau 868.0 MHz?
* Gibt es eine Preamble?
* Welches/Wieviele SyncWord`s werden verwendet? (Habe irgendwo ein 0x03 gesehen, ist das korrekt und vollständig?)

Ziel ist es dann eine Nachricht nach der Syntax vom CUL zu erzeugen (A.....) und über das CUL_HM Modul die Kommunikation inkl. AES realisiert zu bekommen.

Ich wäre sehr dankbar für eure Unterstützung.
Beste Grüße,
  Ulli

MarcelK

Kann Dir spontan die Fragen nicht beantworten weil's mich bisher nicht interessiert hat. Aber ich würde einfach das CC1101 Datasheet http://www.ti.com/lit/ds/swrs061i/swrs061i.pdf nehmen und schauen wie z.B. die AskSin Library oder evtl die CUL Firmware den Chip initialisiert. Das dürfte die zuverlässigste Quelle für alle Antworten sein.

Gruß Marcel

ulli

Puhh... genau das hatte ich gehofft nicht machen zu mussen...mich auch noch in den cc1101 einzuarbeiten...

MarcelK

Naja, einarbeiten... ich weiß exakt gar nix über den Chip, aber das sind ja nur ein paar Register und es hat mich jetzt keine 10 Minuten gekostet um den Inhalt der Register in den AskSin Sourcen zu finden und im Sheet nachzuschauen was das jeweils bedeutet. Da sieht man dann so Sachen wie Symbolrate 9992.6Hz, Modulation 2-FSK ist, 4 Preamble Bytes, Deviation 19kHz (falls nicht verrechnet)... usw. Der Rest Deiner Fragen steht da sicher auch ;)

ulli

Super Danke für die Hilfsbereitschaft!

Ich habe nun folgende Konfiguration, welche mir stabile Nachrichten über das RFM69 Modul liefert:

* Wie ist die Datenrate? Ich habe unterschiedliche Aussagen auf der FHEM Homepage gefunden:
     1) BidCos(R) in the "AskSin" mode (20kHz datarate, FM). HomeMatic(R) Wireless devices use this protocol.
     2) HomeMatic: Für die Kommunikation mit HomeMatic Geräten @10 kHz Datenrate.

--> 10Khz
* Es ist Frequenz moduliert.
* Wie ist die Frequence Deviation?
--> 20Khz
* Liegt die Frequenz bei genau 868.0 MHz?
868.3Mhz
* Gibt es eine Preamble?
4x Preamble 0xAA
* Welches/Wieviele SyncWord`s werden verwendet? (Habe irgendwo ein 0x03 gesehen, ist das korrekt und vollständig?)
4x SyncWords 0xE9 0xCA 0xE9 0xCA

MarcelK

Hey cool, freut mich dass es geklappt hat! Kannst kurz noch verraten wieso Du das jetzt gemacht hast? RFM69 rumliegen gehabt oder was ist der Hintergrund?

Besten Gruß, Marcel

ulli

#11
Hintergrund ist folgender: Ich habe für meinen BeagleBone Black ein Cape mit 3xRFM69 entwickelt. Damit habe ich eine Art Gateway womit ich unterschiedliche Protokolle aktivieren kann (HX2262, ETH, LaCrosse, FS20). Jetzt habe ich mir Fensterkontakte besorgt die leider von HomeMatic sind, da alle anderen auf dem Markt nicht gepasst haben. Daher möchte ich jetzt auf einem der Vorhandenen RFM69 das Homematic Protokoll integrieren um dann über das CUL_HM Modul hofffentlich alle Funktionen wie bei einem CUL bei mir zum laufen bekomme.

So ganz läuft es bei mir aber noch nicht....Ich habe zusätzlich die DataWhiteing Funktion im RFM69 aktivieren müssen. Vorher waren die Daten gar nicht interpretierbar. Jetzt könnte es in die richtige Richtung gehen. Ich sehe nun folgende Nachrichten wenn ich das Fenster auf/zu mache:
l:12 c:108 ft:8D6F q:DF952E z:47BD51 p:E436998AE2E4541272C78D
l:12 c:109 ft:8D6F q:DF952E z:47BD51 p:E437519E355D83E4A8758D
l:12 c:106 ft:8D7F q:DF852E z:87BDD1 p:E4207921F66C6C12DECF8D
l:12 c:107 ft:8D7F q:DF852E z:87BDD1 p:E421B135B1D0DA9BADA8D
l:12 c:104 ft:8D7F q:DF852E z:87BDD1 p:E42279BD263D7BD29E28D
.....
A l:12 c:118 ft:BD1F q:5FF53E z:B7BDA1 p:742C45
A l:12 c:119 ft:BD1F q:5FF53E z:B7BDA1 p:742D8D
A l:12 c:116 ft:BD1F q:5FF53E z:B7BDA1 p:742E45
A l:12 c:117 ft:BD1F q:5FF53E z:B7BDA1 p:742F8D
A l:12 c:114 ft:FDEF q:5F53E z:B7BDA1 p:74185
A l:12 c:115 ft:FDEF q:5F53E z:B7BDA1 p:7419CD
A l:12 c:112 ft:FDEF q:5F53E z:B7BDA1 p:741A5



l:Länge[DEC] c: counter[DEC] ft: byte2&3[HEX] q:Quelle[HEX] z:Ziel[HEX] p:Payload[HEX] (soweit ich verstehe)

Kann man denn die Device-ID (also die Quelle) irgendwo auf dem Fensterkontakt ablesen? Dann könnte ich darüber wenigstens checken ob diese passt..

Komisch ist nun das der Counter manchmal einfach springt, obwohl ich nur Fenster auf/zu mache. Im selben Moment ändert sich die Zieladresse und der Payload. Versteht das wer?

Konfiguration ist: Batterie in den HM-Sec_SCo eingelegt und einfach Fenster auf/zu. Ich habe nichts gepaart oder ähnliches....
Nach dem DataWhiteing durch den RFM69 habe ich noch die XOr Funktion aus dem CUL

data[0] = data[0] & 0x7f; //PacketLength
        *len = data[0];
last_enc = data[1];
data[1] = (~data[1]) ^ 0x89;
for (l = 2; l < *len; l++) {
this_enc = data[l];
data[l] = (last_enc + 0xdc) ^ data[l];
last_enc = this_enc;
}
        data[l] = data[l] ^ data[2];


Komme irgendwie gerade nicht weiter....ich vermute stark das es am Data Whitening liegt?

<b>Update:
Habe im Datenblatt des CC1101 gesehen das DataWhitening per default bei einem Reset an ist.....d.h. RFM69 muss ebenfalls dafür konfiguriert sein</b>

frank

ft: kann nicht stimmen. diese msgtypen gibt es nicht. payload sieht auch seltsam aus.
such doch mal im forum nach gesnifften msg von fensterkontakten.

stimmen denn die hex adressen? die adresse des fk müste in einem qr-code aufkleber zu finden sein. wenn der nicht gepaired ist, solte die msg an broadcast gehen 0x000000.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

ulli

#13
hmm.. Ist die Datenlänge von 12 korrekt?

Ich habe gerade noch einmal versucht die frequenz deviation vom CUL zu berechnen.
Das ist doch die Config 0x15 und der Wert 0x34 der dies definiert.
Wenn ich mit einem
* Deviation_e von 3
* fxosc von 26500000
* fdev von 4
rechne komme ich auf -8 hz.... was hast du anders gerechnet?

ERGÄNZUNG:
Ich habe mal alle QR Codes vom Fensterkontakt abgescannt.
Auf der Controllerplatine H467B2D und NEQ0065811
Auf der Funkplatine C0048399D

Welcher ist davon die DeviceAdress? Von der Länge würde nur 467B2D passen...

frank

ZitatWelcher ist davon die DeviceAdress? Von der Länge würde nur 467B2D passen...
genau diese. neq... ist die seriennummer.

2016.01.30 14:19:47.272 0: HMLAN_Parse: hmusb1 R:E1DE620   stat:0000 t:0A21BD1A d:FF r:FFD0     m:73 A441 1DE620 1ACE1F 013AC8
so sieht eine message meines hm-sec-sc aus. wenn du das längen-byte mitzählst, sind es 13 byte. 0xC8 => 200 ist open. 0x00 wäre closed. das vorletzte byte ist ein counter.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

MarcelK

Also das hier sind Messages von einem gepairten HM-Sec- SCO:

2016.01.30 17:12:47.614 0: HMLAN_Parse: HMLAN1 R:Essssss   stat:0000 t:00EBA125 d:FF r:FFC3     m:B5 A641 ssssss rrrrrr 0149C8  ->open
2016.01.30 17:12:50.621 0: HMLAN_Parse: HMLAN1 R:Essssss   stat:0000 t:00EBACE5 d:FF r:FFC1     m:B6 A641 ssssss rrrrrr 014A00  ->closed

ssssss wäre die HMID vom Sensor, rrrrrr wäre in Deinem Fall vermutlich 0.

Und ich bin wirklich kein Experte im Protokoll, aber wäre mir echt neu wenn da irgendwo ein XOR verwendet würde.

Bezüglich Deviation, in AskSin wird das Register auf 0x34 gesetzt, also Deviation_E = 3, Deviation_M = 4 (ich vermute das meintest Du mit fdev = 4?). Ich bin von fxosc 26000000 ausgegangen, dann wären nach meiner Rechnung fdev = 26000000/131072*(8+4)*2^3 = 19043. Wie Du auf -8 kommst kann ich nicht ganz nachvollziehen ;)

ulli

Zitat von: MarcelK am 30 Januar 2016, 17:32:25
Also das hier sind Messages von einem gepairten HM-Sec- SCO:

2016.01.30 17:12:47.614 0: HMLAN_Parse: HMLAN1 R:Essssss   stat:0000 t:00EBA125 d:FF r:FFC3     m:B5 A641 ssssss rrrrrr 0149C8  ->open
2016.01.30 17:12:50.621 0: HMLAN_Parse: HMLAN1 R:Essssss   stat:0000 t:00EBACE5 d:FF r:FFC1     m:B6 A641 ssssss rrrrrr 014A00  ->closed

ssssss wäre die HMID vom Sensor, rrrrrr wäre in Deinem Fall vermutlich 0.
Hast du einen Auszug aus der CUL Message, wie sie über die USB Schnittstelle kommt? müsste "A...." sein?

Und ich bin wirklich kein Experte im Protokoll, aber wäre mir echt neu wenn da irgendwo ein XOR verwendet würde.
Ich bin gerade total ratlos.
Ich habe in der CUL Source im cc1100.c file gefunden das "0x08: PKTCTRL0" auf 0x32 konfiguriert wird. Damit wäre DataWhitening aus.
In der rf_asksin.c wird das "0x08: PKTCTRL0" gar nicht gesetzt
--> damit müsste keine Whitening Funktion verwendet werden.
In der Empfangsroutine "rf_asksin.c" des CUL´s steht: (Was vermutlich einem DataWhitening/XOR gleich gesetzt ist?)
    last_enc = msg[1];
    msg[1] = (~msg[1]) ^ 0x89;
   
    for (l = 2; l < msg[0]; l++) {
         this_enc = msg[l];
         msg[l] = (last_enc + 0xdc) ^ msg[l];
         last_enc = this_enc;
    }
   
    msg[l] = msg[l] ^ msg[2];


Bezüglich Deviation, in AskSin wird das Register auf 0x34 gesetzt, also Deviation_E = 3, Deviation_M = 4 (ich vermute das meintest Du mit fdev = 4?). Ich bin von fxosc 26000000 ausgegangen, dann wären nach meiner Rechnung fdev = 26000000/131072*(8+4)*2^3 = 19043. Wie Du auf -8 kommst kann ich nicht ganz nachvollziehen ;)
Sorry du hast total recht.

MarcelK

Sorry, besitze keinen CUL. Aber hab nochmal kurz nachgesehen. Das Chip-Eigene Data-Whitening muss disabled sein und der XOR Code ist richtig, damit macht HM dann sein eigenes Whitening so wie's aussieht. Hast die Kombination mal versucht?

ulli

Ja hat aber auch nicht funktioniert.
Ich habe den Eindruck das die Daten schon richtig ankommen aber die XOR  nicht richtig funktioniert.

MarcelK

Wie sehen denn die Daten ohne eingeschaltetes Whitening aus?

ulli

Ich bekomme folgende Daten wenn ich das "Fenster schließe/öffne"

l:12 c:4 ft:FB86 q:F933DB z:6F5E88 p:9129F2
l:12 c:5 ft:FB86 q:F933DB z:6F5E88 p:91283A
l:12 c:2 ft:FB46 q:79132B z:8FCE98 p:D18FF2
l:12 c:3 ft:FB46 q:79132B z:8FCE98 p:D18E3A
l:12 c:0 ft:FB46 q:79132B z:8FCE98 p:D18DF2
l:12 c:1 ft:FB46 q:79132B z:8FCE98 p:D18C3A
l:12 c:62 ft:CB86 q:6913DB z:1F5E98 p:A13C2
l:12 c:63 ft:CB86 q:6913DB z:1F5E98 p:A12A
l:12 c:60 ft:CB86 q:6913DB z:1F5E98 p:A11C2


Aus einem anderen Forum habe ich schon heraus gefunden, dass ich die Länge mit einem "^0xFF" korrigieren muss.
Aber der Rest passt noch garnicht..

ulli

Hab es geschafft.
Der CC1101 scheint immer ein Whitening zu machen, was ein Unterschied zum RFM69 ist.
Das Whitening ist besonders da es sich um eine PN9 pseudo-random sequence handelt, die vor der XOR Funktion durchlaufen muss.

Die Ergebnisse sind jetzt wie folgt:

B l:12 c:45 ft:1F41 q:467B2D z:000 p:12C99
B l:12 c:46 ft:1F41 q:467B2D z:000 p:12D51
B l:12 c:47 ft:1F41 q:467B2D z:000 p:12E99
B l:12 c:48 ft:F41 q:467B2D z:000 p:12F41
B l:12 c:50 ft:F41 q:467B2D z:000 p:13141
B l:12 c:51 ft:F41 q:467B2D z:000 p:13289
B l:12 c:52 ft:3F41 q:467B2D z:000 p:13371


Die sind korrekt oder?

MarcelK

Zitat von: ulli am 30 Januar 2016, 22:01:01
Die sind korrekt oder?
Ich kann mit der Notation nicht viel anfangen. Die Payload sieht immer noch nicht richtig aus, sieht für mich mehr wie ein Timestamp aus. Hast Du keine Roh-Daten?

ulli

#23
Meine Ausgaben:

B l:12 c:47 f:1F t:41 q:467B2D z:000 p:12E99
B l:12 c:48 f:0F t:41 q:467B2D z:000 p:12F41


Franks Ausgaben:
2016.01.30 14:19:47.272 0: HMLAN_Parse: hmusb1 R:E1DE620   stat:0000 t:0A21BD1A d:FF r:FFD0     m:73 A441 1DE620 1ACE1F 013AC8

Marcels Ausgaben:
2016.01.30 17:12:47.614 0: HMLAN_Parse: HMLAN1 R:Essssss   stat:0000 t:00EBA125 d:FF r:FFC3     m:B5 A641 ssssss rrrrrr 0149C8  ->open

Soweit zu meinem Kenntnisstand:
L: Länge 12, korrekt
c: Counter , korrekt, da es sauber hoch zählt
f: Flag, manchmal 1F manchmal 0F, Ist das plausibel? Ihr habt A4 oder A6...
t: Type, 0x41, korrekt da Ihr das auch habt
q: Quelle 467B2D, korrekt da das gleich dem QR Code ist
z: Ziel 000000, korrekt da es ein broadcast für nicht gepaarte devices ist
p: Payload, versteh ich nicht, wie interpretiert man die 3 bytes??

Payload:

B l:12 c:7 f:1F t:41 q:467B2D z:000 p:177A59
B l:12 c:8 f:F t:41 q:467B2D z:000 p:18B231
B l:12 c:9 f:F t:41 q:467B2D z:000 p:197AFD
B l:12 c:10 f:F t:41 q:467B2D z:000 p:1AB2AD
B l:12 c:11 f:F t:41 q:467B2D z:000 p:1B7A61

Hier sieht es so aus als wäre das 1.byte der Zähler, das 2.byte mit 7A oder B2 der Status (offen/zu) und das letzte byte....keine Ahnung, CRC evtl.?

ulli

Alles gelöst! Besten Dank für die Hilfe! Meine RFM69 können jetzt Homematic :)

MarcelK

Zitat von: ulli am 31 Januar 2016, 16:27:33
Alles gelöst! Besten Dank für die Hilfe! Meine RFM69 können jetzt Homematic :)
Gratuliere! Musstest jetzt noch was ändern oder war's nur die Interpretation der Daten?

oli82

@uli
Glückwunsch.
Deine Implementierung wäre für andere bestimmt auch sehr interessant.
Man müsste nun nicht mehr die CC1100 aus China kaufen, sonder konnte direkt die RFM69 für Projekte nutzen.
Die Einbindung in die Asksin library wäre natürlich auch klasse. Dann müsste man nur noch für das passende RF Device kompilieren :)

ulli


@Marcel: Nein ich hatte noch einen Fehler im Code...hatte ich zu Testzwecken drinnen. Jetzt bekomme ich entsprechend zu deinen Payloards passende :)

@Oli: Ich habe eine grundlegend unterschiedliche Implementierung. Da steckt einiges an Umbau drinnen...das wird keinem wirklich helfen.

Falls wer aber ähnliches vor hat helfe ich gerne...der Schlüssel war eben die vom CC1101 spezifische PN9 Data-Whitening Funktion.

--------------------------------------------
Nachdem das Empfangen funktioniert, arbeite ich jetzt an der Sendefunktion. Ich habe entsprechend die funktionen von der Reihenfolge umgedreht. Nur weiß ich jetzt nicht wie ich diese Testen kann.
Gibt es ein Kommando das ich an den Fensterkontakt senden kann und auch eine Antwort bekomme? (mit aktivierten AES am Fensterkontakt, ohne AES Berücksichtigung auf der RFM69 Seite...ich traue mich nämlich noch nicht das AES zu aktivieren)

ulli

#28
Ich versteh den Ablauf von HomeMatic einfach nicht.
Ich öffne das Fenster und bekomme in FHEM folgendes Kommando
A0C628641467B2D0000000149C8
Darauf hin schickt FHEM folgendes Kommando, was vermutlich ein ACK ist. Wobei mich wundert warum als QuellID F10000 verwendet wird?
As0962A112F10000467B2D

Da ich in FHEM kein Missing ACK im Reading State bekomme kann ich doch davon ausgehen, dass der Nachrichtenaustausch beidseitig funktioniert oder? Kann ich das irgendwie am Fensterkontakt erkennen ob ein ACK angekommen ist vom FHEM?

Dennoch beunruhigen mich folgende Infos
lastMsg   No:62 - t:41 s:467B2D d:000000 0149C8
protCmdPend 3 CMDs pending
protResnd 2 last_at:2016-02-03 22:13:03
protSnd 2 last_at:2016-02-03 22:13:00
protState CMDs_pending


Die Anzahl in protResnd und protSnd erhöht sich bei jedem mal Fenster schließen/öffnen

MarcelK

Zitat von: ulli am 03 Februar 2016, 22:18:50
Ich versteh den Ablauf von HomeMatic einfach nicht.
Ich öffne das Fenster und bekomme in FHEM folgendes Kommando
A0C628641467B2D0000000149C8
Darauf hin schickt FHEM folgendes Kommando, was vermutlich ein ACK ist. Wobei mich wundert warum als QuellID F10000 verwendet wird?
Die Message ist ein Broadcast, ich würde jetzt mal vermuten dass darauf kein ACK gesendet wird. Du musst den Sensor erst pairen bevor FHEM wirklich mit ihm interagieren kann.

ZitatAs0962A112F10000467B2D
Laut 10_CUL_HM.pm heißt A112 "HAVE_DATA" und meint "Hey, hab Daten für Dich, darf ich die senden"? Darauf müsste der Sensor mit einem ACK kommen.

ZitatDennoch beunruhigen mich folgende Infos
lastMsg   No:62 - t:41 s:467B2D d:000000 0149C8
protCmdPend 3 CMDs pending
protResnd 2 last_at:2016-02-03 22:13:03
protSnd 2 last_at:2016-02-03 22:13:00
protState CMDs_pending


Die Anzahl in protResnd und protSnd erhöht sich bei jedem mal Fenster schließen/öffnen
Ja, das sind genau die Dinger die FHEM loswerden will aber nicht kann. Aber solange der Sensor FHEM nicht als Zentrale eingetragen hat lässt er sich vermutlich eh nichts sagen.

Gruß Marcel

ulli

#30
hmm der Tip ist gut :)
Habe mich an "http://fhemwiki.de/wiki/HomeMatic_Devices_pairen" gehalten, aber leider ohne Erfolg.
Ich bekomme folgendes bei einem pairing Versuch


2016.02.06 22:44:52 5: RadioGateway dispatch A1A318400467B2D0000001000C74E45513030363538313180810101
2016.02.06 22:44:52 2: CUL_HM Unknown device HM_467B2D is now defined
2016.02.06 22:44:52 2: autocreate: define HM_467B2D CUL_HM 467B2D
2016.02.06 22:44:52 3: Device HM_467B2D added to ActionDetector with 000:50 time
2016.02.06 22:44:52 3: CUL_HM pair: HM_467B2D threeStateSensor, model HM-SEC-SCo serialNr
2016.02.06 22:44:53 4: RadioGateway: SW: <A1032A0015F8E3A467B2D00050000000000>
2016.02.06 22:44:57 3: Device HM_467B2D added to ActionDetector with 000:50 time


Dann habe ich wie im Wiki beschrieben noch ein set getConfig gemacht und dann noch einmal den Pairing Button am FK gedrückt

2016.02.06 22:45:04 3: CUL_HM set HM_467B2D getConfig
2016.02.06 22:46:24 5: RadioGateway dispatch A1A328400467B2D0000001000C74E45513030363538313180810101
2016.02.06 22:46:24 3: Device HM_467B2D added to ActionDetector with 000:50 time
2016.02.06 22:46:25 4: RadioGateway: SW: <A1033A0015F8E3A467B2D00050000000000>


Wenn ich jetzt das Fenster öffne bekomme ich folgende Meldung:

2016.02.06 22:46:45 5: RadioGateway dispatch A0C338641467B2D000000011EC8
2016.02.06 22:46:45 4: RadioGateway: SW: <A0934A1125F8E3A467B2D>


Das Device zeigt folgendes:

Internals:
   CFGFN
   DEF        467B2D
   IODev      RadioGateway
   LASTInputDev RadioGateway
   MSGCNT     3
   NAME       HM_467B2D
   NR         28
   NTFY_ORDER 50-HM_467B2D
   RadioGateway868_1_MSGCNT 3
   RadioGateway868_1_RAWMSG A0C338641467B2D000000011EC8
   RadioGateway868_1_TIME 2016-02-06 22:46:45
   STATE      open
   TYPE       CUL_HM
   lastMsg    No:33 - t:41 s:467B2D d:000000 011EC8
   protCmdPend 6 CMDs pending
   protLastRcv 2016-02-06 22:46:45
   protResnd  3 last_at:2016-02-06 22:46:46
   protSnd    3 last_at:2016-02-06 22:46:45
   protState  CMDs_pending
   Readings:
     2016-02-06 22:46:25   Activity        alive
     2016-02-06 22:46:25   D-firmware      1.0
     2016-02-06 22:46:25   D-serialNr      NEQ0065811
     2016-02-06 22:44:53   R-pairCentral   set_0x5F8E3A
     2016-02-06 22:46:45   battery         ok
     2016-02-06 22:46:45   contact         open (to broadcast)
     2016-02-06 22:46:45   state           open
     2016-02-06 22:46:45   trigDst_broadcast noConfig
     2016-02-06 22:46:45   trigger_cnt     30
   cmdStack:
     ++A0015F8E3A467B2D00050000000000
     ++A0015F8E3A467B2D000802010A5F0B8E0C3A
     ++A0015F8E3A467B2D0006
     ++A0015F8E3A467B2D00040000000000
     ++A0015F8E3A467B2D01040000000001
     ++A0015F8E3A467B2D0103
   Helper:
     HM_CMDNR   51
     cSnd       015F8E3A467B2D00050000000000,015F8E3A467B2D00050000000000
     getCfgList all
     getCfgListNo ,4
     mId        00C7
     rxType     28
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +467B2D,02,00,00
       nextSend   1454795093.04747
       prefIO
       rxt        2
       vccu
       p:
         467B2D
         00
         00
         00
     Mrssi:
       mNo
     Prt:
       bErr       0
       sProc      2
       wuReSent   4
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Shadowreg:
       RegL_00.    02:01 0A:5F 0B:8E 0C:3A
Attributes:
   IODev      RadioGateway
   actCycle   000:50
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SCo
   room       System
   serialNr   NEQ0065811
   subType    threeStateSensor


Scheinbar funktioniert das Pairing überhaupt nicht. Muss ich vorher einen neuen AES Schlüssel setzen oder an was denkst du liegt das?

Zusatzfrage:
An was hängt das wenn CMDs pending sind. Warum schickt er die nicht raus? Auf was wartet er denn?

frank

ZitatAn was hängt das wenn CMDs pending sind. Warum schickt er die nicht raus? Auf was wartet er denn?
das device muss aufwachen.
da der sco lazyconfig kann, entweder fensterstatus ändern oder configtaster drücken.
mit set clear msgEvents kann man die queue löschen.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

MarcelK

Zitat von: ulli am 06 Februar 2016, 22:52:41
An was hängt das wenn CMDs pending sind. Warum schickt er die nicht raus? Auf was wartet er denn?
Wie Frank schon richtig anmerkte, das Device soll ja Jahre mit einer Batterie überleben, das heißt es schläft praktisch immer und ist nie auf Empfang. Außer eben kurz nachdem es selbst etwas gesendet hat, das ist genau die Lücke wo FHEM mit "HAVE_DATA" kurz sagen will dass es bitte nicht sofort wieder einschlafen soll.

Die Pairing Request Anforderung vom Sensor wurde in FHEM richtig empfangen, das sieht man u.A. am "Firmware" bzw "serialNr" Eintrag, die richtig gesetzt wurden. Ich vermute aber dass Du noch ein Problem mit dem Senden hast:

2016-02-06 22:44:53   R-pairCentral   set_0x5F8E3A

Heißt er hat versucht den Request zu senden, das wurde bisher aber nicht bestätigt. Wenn das Pairing erfolgreich gewesen wäre dann würde das "set_" nicht mehr da stehen.

Gruß Marcel

ulli

Danke, ich komme zum Glück immer ein Stück weiter :) Danke euch!
Wichtig zu wissen ist das der CC1101 scheinbar doch CRC aktiviert hat und das natürlich beim TX an den FK essentiell ist.

Ich habe nun folgende Infos aus einem "list" nachdem ich den Pairing-Button gedrück habe.

Internals:
   CFGFN
   DEF        467B2D
   IODev      RadioGateway868_1
   LASTInputDev RadioGateway868_1
   MSGCNT     4
   NAME       HM_467B2D
   NR         27
   NTFY_ORDER 50-HM_467B2D
   RadioGateway868_1_MSGCNT 4
   RadioGateway868_1_RAWMSG A1A0E8400467B2D0000001000C74E45513030363538313180810101
   RadioGateway868_1_TIME 2016-02-09 18:08:36
   STATE      open
   TYPE       CUL_HM
   lastMsg    No:0E - t:00 s:467B2D d:000000 1000C74E45513030363538313180810101
   protCmdPend 4 CMDs pending
   protLastRcv 2016-02-09 18:08:36
   protResnd  3 last_at:2016-02-09 18:08:39
   protSnd    5 last_at:2016-02-09 18:08:36
   protState  CMDs_pending
   Readings:
     2016-02-09 18:08:36   Activity        alive
     2016-02-09 18:08:36   D-firmware      1.0
     2016-02-09 18:08:36   D-serialNr      NEQ0065811
     2016-02-09 18:07:40   R-pairCentral   set_0x5F8E3A
     2016-02-09 18:07:40   aesKeyNbr       00
     2016-02-09 18:08:28   battery         ok
     2016-02-09 18:08:28   contact         open (to broadcast)
     2016-02-09 18:08:28   state           open
     2016-02-09 18:08:28   trigDst_broadcast noConfig
     2016-02-09 18:08:28   trigger_cnt     19
   cmdStack:
     ++A0015F8E3A467B2D000802010A5F0B8E0C3A
     ++A0015F8E3A467B2D0006
     ++A0015F8E3A467B2D00040000000000
     ++A0015F8E3A467B2D01040000000001
     ++A0015F8E3A467B2D0103
   Helper:
     HM_CMDNR   15
     cSnd       015F8E3A467B2D000802010A5F0B8E0C3A,015F8E3A467B2D000802010A5F0B8E0C3A
     getCfgList all
     getCfgListNo ,4
     mId        00C7
     rxType     28
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +467B2D,02,00,00
       nextSend   1455037716.89817
       prefIO
       rxt        2
       vccu
       p:
         467B2D
         00
         00
         00
     Mrssi:
       mNo
     Prt:
       bErr       0
       sProc      2
       wuReSent   4
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Shadowreg:
       RegL_00.    02:01 0A:5F 0B:8E 0C:3A
Attributes:
   IODev      RadioGateway868_1
   actCycle   000:50
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SCo
   room       System
   serialNr   NEQ0065811
   subType    threeStateSensor


Komischerweise habe ich nach einem "getconfig" und einem wiederholten Drücken auf den Paring Butten am FK immer noch CMDs im pending.
Aber es ist nun ein Datenaustausch erkennbar über die Logs und ein paar Readings(siehe oben)sind dazu gekommen:

2016.02.09 18:07:40 4: RadioGateway: <A1A0B8400467B2D0000001000C74E45513030363538313180810101>
2016.02.09 18:07:40 2: CUL_HM Unknown device HM_467B2D is now defined
2016.02.09 18:07:40 2: autocreate: define HM_467B2D CUL_HM 467B2D
2016.02.09 18:07:40 3: Device HM_467B2D added to ActionDetector with 000:50 time
2016.02.09 18:07:40 3: CUL_HM pair: HM_467B2D threeStateSensor, model HM-SEC-SCo serialNr
2016.02.09 18:07:40 4: RadioGateway: SW: <A100CA0015F8E3A467B2D00050000000000>
2016.02.09 18:07:40 4: RadioGateway: <A10CA002467B2D5F8E3A0494584C91105B00>
2016.02.09 18:07:40 4: RadioGateway: SW: <A0A0C80025F8E3A467B2D00>
2016.02.09 18:07:40 4: RadioGateway: SW: <A130DA0015F8E3A467B2D000802010A5F0B8E0C3A>
2016.02.09 18:07:45 3: Device HM_467B2D added to ActionDetector with 000:50 time
2016.02.09 18:08:24 3: CUL_HM set HM_467B2D getConfig
2016.02.09 18:08:28 4: RadioGateway: <A0C0D8641467B2D0000000113C8>
2016.02.09 18:08:28 4: RadioGateway: SW: <A090EA1125F8E3A467B2D>
2016.02.09 18:08:36 4: RadioGateway: <A1A0E8400467B2D0000001000C74E45513030363538313180810101>
2016.02.09 18:08:36 3: Device HM_467B2D added to ActionDetector with 000:50 time
2016.02.09 18:08:36 4: RadioGateway: SW: <A130FA0015F8E3A467B2D000802010A5F0B8E0C3A>


Ist das so korrekt? Obwohl das Reading R-pairCentral immer noch ein "set_" hat und Commands noch pending sind?

frank

ZitatIst das so korrekt? Obwohl das Reading R-pairCentral immer noch ein "set_" hat und Commands noch pending sind?
das knöpchen drücken wiederholen, bis alles abgearbeitet ist => cmds_done.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

ulli

Ich brauche dringend noch einmal eure Hilfe. Ich bekomme den FK immer noch nicht gepaired.
Ich vermute es liegt daran das die letzten beiden Nachrichten scheinbar nicht ankommen.
Die Kommunikation sieht wie folgt aus:

A1A788400467B2D0000001000C74E45513030363538313180810101 [RSSI:-92]
--> Pairing Anfrage vom FK
As1079A0015F8E3A467B2D00050000000000 [RSSI:-53]
--> Start Config von FHEM
A1179A002467B2D5F8E3A040D227BE021A900 [RSSI:-103]
--> Antwort von FK
As0A7980025F8E3A467B2D00 [RSSI:-53]
--> Ich denke ACK von FHEM
As137AA0015F8E3A467B2D000802010A5F0B8E0C3A [RSSI:-53]
--> Nochmal eine Nachricht von FHEM

Komischerweise bekomme ich nur zweimal eine Antwort vom FK, ist das Normal?
Ich habe auch schon die Delay Zeit zwischen den Kommandos von 0ms auf 1ms gerastet....immer mit gleichem Verhalten.
Ich dachte es kommen immer Abwechseln Nachrichten von FK<->FHEM?

Und zu aller Irritation bleibt dann immer 1 CMD pending....

Habt Ihr einen Tip warum das Pairing abbricht?


frank

schau dir mal die rssi an. warum sind die richtungen so unterschiedlich?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

ulli

Das liegt daran das ich durch ein drittGerät das ganze aufgezeichnet habe welches weiter weg stand.
Mein RfM69 hat auch eine höhere Sendeleistung wie es vermutlich der FK hat.

frank

die rssi vom fk sind grotten schlecht, da könnte also etwas fehlen.
der fk möchte jedenfalls eine aes authentifizierung (A002), was fhem wohl auch macht. den genauen ablauf müsstest du im forum finden => suche nach mgernoth/aes.
wichtig wären timestamps wegen timing. wenn du eh schon monitorst, solltest du auf diesem cul? die fw mit timestamps installieren, siehe angepinnter thread. vielleicht ist fhem zu spät und der fk schläft schon wieder.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

ulli

Hmm AES ist ein guter Punkt. Ich dachte ich kann pairen ohne AES. (Ist der key nicht erst setzbar wenn die zwei Devices gepaired sind?)

Kann ich über einen CUL bei einem FK ohne pairing oder im pairing Prozess selbst das AES vorerst deaktivieren?

frank

fk werden seit einiger zeit mit aktiviertem aes ausgeliefert. defaultschlüssel. sollte ein cul mit fhem können. eine entsprechende antwort kommt ja wohl auch.
ob ein ungepairtes device befehle entgegennimmt wiess ich nicht, schätze aber nein. zum aes ausschalten wird aber sowieso aes benötigt.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

ulli

Was heißt das jetzt?
Muss ich einen neuen AES setzten bevor ich erfolgreich Pairen kann?

Ich versuche aktuell folgendes:
1) Werkseinstellungen des FK
2) hmID des CUL setzten, Pairing Zeit auf 600
3) Pairing Knopf am FK drücken.
--> Nicht alle Befehle werden ausgeführt/vom FK bestätigt. Daher kein erfolgreiches Pairing...

Otto123

Hallo Ulli

Du musst nicht AES setzen zum pairen, das geht auch ohne zumindest mit meinem HMLAN (der CUL sollte es mittlerweile können)

Aber die Sensoren brauchen manchmal Zeit, wenn nicht alles rüberkommt musst Du nach etwas Zeit nochmal den Anlernknopf drücken. Manchmal auch dreimal.

Die Zeit fürs Pairing ist egal, es sei denn Du bist ganz langsam  8) das "Parrungsbereitschaft" wird eh nach dem ersten Pairing Message Austausch ausgeschaltet.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

ulli

#43
Ich habe schon so oft auf den Pairing Knopf gedrückt das er vermutlich bald über der Auslegungsgrenze betätigt wurde :)

Komischerweise läuft nur das Pairing nicht durch (also die letzten beiden Kommands)
Wenn ich nach einem "set clear MsgEvents" ein getConfig ausführe und dann den Pairing Butten drücke ist die gesamte Config sauber da.

ich Vermute das letzte unbeantwortete Kommando von FHEM an den FK ist evtl. falsch:
"As0A7980025F8E3A467B2D00"
Weil ab diesem bekomme ich keine Antwort mehr vom FK. Obwohl aber die LED nach dem absetzen des Kommandos:
"As1079A0015F8E3A467B2D00050000000000"
eine grüne LED anzeigt.

Scheinbar akzeptiert der FK das Kommando "As0A7980025F8E3A467B2D00" nicht oder erwartet nicht das noch etwas nach dem "As1079A0015F8E3A467B2D00050000000000" kommt?

Ich bin auch mal in die Tiefen des Protocols eingestiegen und musste feststellen das das CUL_HM doch vermutlich was durcheinander bringt?
(QUelle: https://homegear.eu/index.php/BidCoS_Packet_-_0x01_0x08)
Scheinbar müsste nach dem Config_Start welche nach der Pairing Anfrage vom FK von CUL_HM versendet wird ein anderes Kommando mit "A001" folgen.
Auch der FK antwortet nicht mit einem ACK ("8002") auf das Config_Start Kommando von FHEM.

Jetzt check ich garnichts mehr.

MarcelK

Zitat von: ulli am 10 Februar 2016, 22:54:02
A1179A002467B2D5F8E3A040D227BE021A900 [RSSI:-103]
--> Antwort von FK
"Antwort von FK" ist hier ein bisschen zu lapidar. Die Antwort ist nämlich ein Request für ein AES signiertes ACK. "0D227BE021A9" ist die Challenge, "00" ist die Key-Nummer (also der HM Default Key)

ZitatAs0A7980025F8E3A467B2D00 [RSSI:-53]
Worauf Du hier einen nicht signierten ACK zurücksendest. Kein Wunder mag Dich der Sensor nicht ;)

In CUL_HM wird, wenn das Interface vom Typ "CUL" ist, das AES Handling vom Code übernommen, ansonsten nicht. Das dürfte an dieser Stelle Dein Problem sein.

Gruß Marcel

ulli

#45
@Marcel: Du bist der Beste!
Genau das war das Problem. Ich habe kurzer Hand im CUL_HM alle Type Abfragen die auf "CUL" gematcht waren ausgetauscht.
Jetzt ist der Fensterkontakt auf den ersten Pairing Button Druck erfolgreich gepaired worden und alle Infos scheinen wir als korrrekt. Keine CMDs pending....

Internals:
   CFGFN
   DEF        467B2D
   IODev      RadioGateway868_1
   LASTInputDev RadioGateway868_1
   MSGCNT     11
   NAME       HM_467B2D
   NR         53
   NTFY_ORDER 50-HM_467B2D
   RadioGateway868_1_MSGCNT 11
   RadioGateway868_1_RAWMSG A0E09A010467B2D5F8E3A0100000000
   RadioGateway868_1_TIME 2016-02-14 11:01:03
   STATE      ???
   TYPE       CUL_HM
   lastMsg    No:09 - t:10 s:467B2D d:5F8E3A 0100000000
   protLastRcv 2016-02-14 11:01:03
   protSnd    12 last_at:2016-02-14 11:01:03
   protState  CMDs_done
   Readings:
     2016-02-14 11:01:02   Activity        alive
     2016-02-14 10:59:55   CommandAccepted yes
     2016-02-14 11:01:02   D-firmware      1.0
     2016-02-14 11:01:02   D-serialNr      NEQ0065811
     2016-02-14 11:01:02   PairedTo        0x5F8E3A
     2016-02-14 11:01:02   R-cyclicInfoMsg on
     2016-02-14 11:01:02   R-eventDlyTime  0 s
     2016-02-14 11:01:02   R-pairCentral   0x5F8E3A
     2016-02-14 11:01:02   R-sabotageMsg   on
     2016-02-14 11:01:02   R-sign          on
     2016-02-14 11:01:02   RegL_00.          02:01 09:01 0A:5F 0B:8E 0C:3A 10:01 14:06 00:00
     2016-02-14 11:01:02   RegL_01.          08:01 20:9C 21:00 30:06 00:00
     2016-02-14 10:59:55   aesCommToDev    ok
     2016-02-14 10:59:54   aesKeyNbr       00
   Helper:
     HM_CMDNR   9
     cSnd       015F8E3A467B2D01040000000001,015F8E3A467B2D0103
     mId        00C7
     peerIDsRaw ,00000000
     rxType     28
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +467B2D,00,00,00
       nextSend   1455444063.36238
       prefIO
       rxt        2
       vccu
       p:
         467B2D
         00
         00
         00
     Mrssi:
       mNo
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         RadioGateway868_1
       flg        A
       ts         1455444063.16876
       ack:
         HASH(0x932e6f8)
         0980025F8E3A467B2D00
     Shadowreg:
Attributes:
   IODev      RadioGateway868_1
   actCycle   000:50
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SCo
   peerIDs    00000000,
   room       System
   serialNr   NEQ0065811
   subType    threeStateSensor


Besten Dank an alle die mir in den letzten Wochen immer wieder Tips gegeben haben. Das hat mir sehr geholfen!!
8) ;D

Ich habe mal alles zusammengefasst für die Nachwelt :)
http://forum.fhem.de/index.php/topic,49300.0.html

MarcelK

Hallo Ulli,

cool, freut mich sehr! 8) Ich wollte mich irgendwann eh mal besser in das Protokoll einarbeiten, insofern hat mir der kleine Exkurs auch selbst was gebracht :)

Besten Gruß, Marcel

ulli

Dann haben sich ja zwei getroffen  ;D