HM protokol

[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

[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

[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.

Das 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

[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:

Code Auswählen Erweitern

* 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.

Code Auswählen Erweitern

* Wie ist die Frequence Deviation?
--> 20Khz

Code Auswählen Erweitern

* Liegt die Frequenz bei genau 868.0 MHz?
868.3Mhz

Code Auswählen Erweitern

* Gibt es eine Preamble?
4x Preamble 0xAA

Code Auswählen Erweitern

* 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]

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:

Code Auswählen Erweitern

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

Code Auswählen Erweitern


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.

[ulli]

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]

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

genau diese. neq... ist die seriennummer.

Code Auswählen Erweitern

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.

[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]

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?

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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"

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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]

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]

Meine Ausgaben:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern


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]

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]

Ich versteh den Ablauf von HomeMatic einfach nicht.
Ich öffne das Fenster und bekomme in FHEM folgendes Kommando

Code Auswählen Erweitern

A0C628641467B2D0000000149C8
Darauf hin schickt FHEM folgendes Kommando, was vermutlich ein ACK ist. Wobei mich wundert warum als QuellID F10000 verwendet wird?

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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]

Ich versteh den Ablauf von HomeMatic einfach nicht.
Ich öffne das Fenster und bekomme in FHEM folgendes Kommando

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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.

Dennoch beunruhigen mich folgende Infos

Code Auswählen Erweitern

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]

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

Code Auswählen Erweitern


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

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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


Das Device zeigt folgendes:

Code Auswählen Erweitern


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]

An 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.

[MarcelK]

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.

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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]

Ist 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.

[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?

[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.

[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.

[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  das "Parrungsbereitschaft" wird eh nach dem ersten Pairing Message Austausch ausgeschaltet.

Gruß Otto

[ulli]

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]

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)

As0A7980025F8E3A467B2D00 [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]

@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....

Code Auswählen Erweitern


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


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