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]

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

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

Code: [Auswählen]

* Liegt die Frequenz bei genau 868.0 MHz?868.3Mhz

Code: [Auswählen]

* Gibt es eine Preamble?4x Preamble 0xAA

Code: [Auswählen]

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

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]

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]

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 013AC8so 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.