HM protokol

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

Vorheriges Thema - Nächstes Thema

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