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
Moin Martin,
auf sowas habe ich schon Lange gewartet.
Kannst Du das Pinnen, und aktuell halten, ggf, um weitere Infos erweitern.
Gruß Joachim
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
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
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
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
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 (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
Puhh... genau das hatte ich gehofft nicht machen zu mussen...mich auch noch in den cc1101 einzuarbeiten...
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 ;)
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
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
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>
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.
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...
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.
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 ;)
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.
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?
Ja hat aber auch nicht funktioniert.
Ich habe den Eindruck das die Daten schon richtig ankommen aber die XOR nicht richtig funktioniert.
Wie sehen denn die Daten ohne eingeschaltetes Whitening aus?
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..
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?
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?
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.?
Alles gelöst! Besten Dank für die Hilfe! Meine RFM69 können jetzt Homematic :)
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?
@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 :)
@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)
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
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
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?
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.
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
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?
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.
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?
schau dir mal die rssi an. warum sind die richtungen so unterschiedlich?
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.
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.
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?
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.
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...
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
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.
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
@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
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
Dann haben sich ja zwei getroffen ;D