Autor Thema: HM protokol  (Gelesen 36909 mal)

Offline MarcelK

  • Full Member
  • ***
  • Beiträge: 338
Antw:HM protokol
« Antwort #15 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.

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 ;)

Offline ulli

  • Full Member
  • ***
  • Beiträge: 429
Antw:HM protokol
« Antwort #16 am: 30 Januar 2016, 18:08:08 »
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.
FHEM auf Beaglebone Black mit Debian.
1x Jeenode (433MHz): IR send/receive; Baumarkt Funksteckdosen HX2262 send/receive; LEDs
1x Jeenode (868MHz): FS20 send/receive; 2x Heizungsthermostate ETH200 comfort; 2x LaCrosse Temperatursensoren (send)/receive; Piezo Summer für akustische Rückmeldung

Offline MarcelK

  • Full Member
  • ***
  • Beiträge: 338
Antw:HM protokol
« Antwort #17 am: 30 Januar 2016, 19:33:58 »
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?

Offline ulli

  • Full Member
  • ***
  • Beiträge: 429
Antw:HM protokol
« Antwort #18 am: 30 Januar 2016, 19:50:24 »
Ja hat aber auch nicht funktioniert.
Ich habe den Eindruck das die Daten schon richtig ankommen aber die XOR  nicht richtig funktioniert.
FHEM auf Beaglebone Black mit Debian.
1x Jeenode (433MHz): IR send/receive; Baumarkt Funksteckdosen HX2262 send/receive; LEDs
1x Jeenode (868MHz): FS20 send/receive; 2x Heizungsthermostate ETH200 comfort; 2x LaCrosse Temperatursensoren (send)/receive; Piezo Summer für akustische Rückmeldung

Offline MarcelK

  • Full Member
  • ***
  • Beiträge: 338
Antw:HM protokol
« Antwort #19 am: 30 Januar 2016, 20:47:22 »
Wie sehen denn die Daten ohne eingeschaltetes Whitening aus?

Offline ulli

  • Full Member
  • ***
  • Beiträge: 429
Antw:HM protokol
« Antwort #20 am: 30 Januar 2016, 21:21:56 »
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..
FHEM auf Beaglebone Black mit Debian.
1x Jeenode (433MHz): IR send/receive; Baumarkt Funksteckdosen HX2262 send/receive; LEDs
1x Jeenode (868MHz): FS20 send/receive; 2x Heizungsthermostate ETH200 comfort; 2x LaCrosse Temperatursensoren (send)/receive; Piezo Summer für akustische Rückmeldung

Offline ulli

  • Full Member
  • ***
  • Beiträge: 429
Antw:HM protokol
« Antwort #21 am: 30 Januar 2016, 22:01:01 »
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?
FHEM auf Beaglebone Black mit Debian.
1x Jeenode (433MHz): IR send/receive; Baumarkt Funksteckdosen HX2262 send/receive; LEDs
1x Jeenode (868MHz): FS20 send/receive; 2x Heizungsthermostate ETH200 comfort; 2x LaCrosse Temperatursensoren (send)/receive; Piezo Summer für akustische Rückmeldung

Offline MarcelK

  • Full Member
  • ***
  • Beiträge: 338
Antw:HM protokol
« Antwort #22 am: 30 Januar 2016, 22:19:46 »
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?

Offline ulli

  • Full Member
  • ***
  • Beiträge: 429
Antw:HM protokol
« Antwort #23 am: 31 Januar 2016, 14:41:35 »
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.?
« Letzte Änderung: 31 Januar 2016, 14:46:36 von ulli »
FHEM auf Beaglebone Black mit Debian.
1x Jeenode (433MHz): IR send/receive; Baumarkt Funksteckdosen HX2262 send/receive; LEDs
1x Jeenode (868MHz): FS20 send/receive; 2x Heizungsthermostate ETH200 comfort; 2x LaCrosse Temperatursensoren (send)/receive; Piezo Summer für akustische Rückmeldung

Offline ulli

  • Full Member
  • ***
  • Beiträge: 429
Antw:HM protokol
« Antwort #24 am: 31 Januar 2016, 16:27:33 »
Alles gelöst! Besten Dank für die Hilfe! Meine RFM69 können jetzt Homematic :)
FHEM auf Beaglebone Black mit Debian.
1x Jeenode (433MHz): IR send/receive; Baumarkt Funksteckdosen HX2262 send/receive; LEDs
1x Jeenode (868MHz): FS20 send/receive; 2x Heizungsthermostate ETH200 comfort; 2x LaCrosse Temperatursensoren (send)/receive; Piezo Summer für akustische Rückmeldung

Offline MarcelK

  • Full Member
  • ***
  • Beiträge: 338
Antw:HM protokol
« Antwort #25 am: 31 Januar 2016, 22:47:06 »
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?

Offline oli82

  • Full Member
  • ***
  • Beiträge: 437
Antw:HM protokol
« Antwort #26 am: 01 Februar 2016, 08:29:18 »
@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 :)

Offline ulli

  • Full Member
  • ***
  • Beiträge: 429
Antw:HM protokol
« Antwort #27 am: 02 Februar 2016, 20:25:09 »

@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)
FHEM auf Beaglebone Black mit Debian.
1x Jeenode (433MHz): IR send/receive; Baumarkt Funksteckdosen HX2262 send/receive; LEDs
1x Jeenode (868MHz): FS20 send/receive; 2x Heizungsthermostate ETH200 comfort; 2x LaCrosse Temperatursensoren (send)/receive; Piezo Summer für akustische Rückmeldung

Offline ulli

  • Full Member
  • ***
  • Beiträge: 429
Antw:HM protokol
« Antwort #28 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
A0C628641467B2D0000000149C8Darauf 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
« Letzte Änderung: 03 Februar 2016, 22:34:43 von ulli »
FHEM auf Beaglebone Black mit Debian.
1x Jeenode (433MHz): IR send/receive; Baumarkt Funksteckdosen HX2262 send/receive; LEDs
1x Jeenode (868MHz): FS20 send/receive; 2x Heizungsthermostate ETH200 comfort; 2x LaCrosse Temperatursensoren (send)/receive; Piezo Summer für akustische Rückmeldung

Offline MarcelK

  • Full Member
  • ***
  • Beiträge: 338
Antw:HM protokol
« Antwort #29 am: 04 Februar 2016, 20:08:02 »
Ich versteh den Ablauf von HomeMatic einfach nicht.
Ich öffne das Fenster und bekomme in FHEM folgendes Kommando
A0C628641467B2D0000000149C8Darauf 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.

Zitat
As0962A112F10000467B2D
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.

Zitat
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
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