Hallo!
Es gibt ja von ELV nun dieses ganz neue Modul HM-MOD-RPI-PCB für den Raspberry Pi:
elv.de/homematic-funkmodul-f … usatz.html
Weiß jemand, ob das nur ein normales TRX868-Modul mit CC1101 ist, das dann per SPI angeschlossen ist, oder ist das per UART angebunden?
So wie zum Beispiel in der CCU2 auch. Dort ist ja hinter dem TRX868 erst ein kleiner ATMEGA328P der dann per UART an den Hauptprozessor (AT91SAM9G25 -> Linux) angeschlossen ist.
Wie sieht es mit der Unterstützung in Homegear aus?
Hi,
das Modul ist leider nicht über SPI angebunden sondern über UART.
Gruß
Pascal
Ok, weiß man denn schon, ob es das gleiche Protokoll ist, was der HM-CFG-USB und der ALTE LAN-Konfig-Adapter sprechen?
Wenn ja, dann müsste “nur” hmland angepasst werden: git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb
Hallo nanosonde,
Das wäre schön. Ich habe das Ding bereits auf meinem Schreibtisch liegen und werde es mir vermutlich nächste Woche mal ansehen. Diese Woche ist dafür leider zu viel zu tun :’(.
Viele Grüße
Sathya
Hallo zusammen
Gibt es schon news betreffend dem HM-MOD-UART Modul ?
Bin gerade dabei Homgear auf dem PI aufzusetzen um die CCU2 abzulösen.
Viele Grüsse
Silvan
Hallo Silvan,
leider noch nicht…
Viele Grüße
Sathya
Hallo Sathya,
da jetzt bei ELV die Lieferzeit auf wenige Tage gesunken ist, sollte mein HM-MOD-RPI-PCB hoffentlich die Tage endlich in der Post liegen.
Gibt es da zu dem Support in Homegear schon was Neuigkeiten?
Falls du an der Stelle noch keine Zeit hattest, die Unterstützung für dieses Funkmodul einzubauen, kann ich da gerne mal mein Glück versuchen bzw. dich unterstützen. Ich würde da erstmal zusehen, dass ich mir ansehe, was die OCCU so über Serial auf das Modul schickt. Gibt es irgendwo eine “Highlevel” Protokollbeschreibung fürs Pairing und so?
EDIT: Ich hab grad im Wiki einiges gefunden. Dann bau ich mir mal was, um die Serial-Kommunikation mitzuschneiden und werd mal sehen, ob ich was aus dem Wiki bekanntes wiederfinde…
Hallo Stefan,
das wäre richtig klasse! Ich habe im Moment leider recht wenig Zeit für solche Analysen. Poste gerne, was du hast. Vielleicht kann ich dir bei der Analyse helfen. Sobald wir die Grundinformationen zusammen haben, werde ich das Teil implementieren.
Es wird folgendes in der Kommunikation geben:
[ul]
[li] Initialisierung mit Setzen der Uhrzeit und der AES-Schlüssel[/li]
[li] Senden der Peers auf welche geantwortet werden soll[/li]
[li] Das Senden und Empfangen von Paketen an sich[/li]
[li] Setzen von Parametern beim Aktivieren/Deaktivieren von AES[/li]
[li] Setzen von Parametern, wenn ein Wake-up-Paket aussteht.[/li][/ul]
Viele Grüße
Sathya
So, ich hab jetzt hier die ersten Bytes aus der seriellen Leitung. Da ich momentan ttyAMA0 per interceptty an der lxccu abgegriffen habe, fange ich anscheinend nur die Pakete, die von den Geräten an die CCU gesendet werden, ab. Das hat zur Folge, dass ich zum einen die Pakete von der CCU an die Geräte nicht sehe und dass zum anderen die CCU die Pakete der Geräte nicht bekommt.
Ist zwar schade, aber man immerhin bekomme ich überhaupt erstmal was zu sehen 
Anscheinend geht wirklich weitestgehend das Binary-Format, das du im Wiki beschrieben hast, auch über die serielle Leitung. Im meinem aktuellen Setup ist ein HM-CC-RT-DN an der lxccu angelernt. Darüber hinaus habe ich noch drei weitere HM-CC-RT-DN’s und ein HM-TC-IT-WM-W-EU (der Nachfolger vom HM-CC-TC) in Reichweite im Betrieb.
Ich habe 0x70-Pakete vom Wandthermostat dabei, die ich anhand deiner Paket-Beschreibung sauber lesen und kann und deren Werte ich auch über das Display des Thermostats verifizieren kann. Was mich nur irritiert, ist, dass die Länge im Paket-Header scheinbar falsch ist. So zum Beispiel im Folgenden 0x70-Paket:
3b 45 84 70 3c94de 000000 00d3288743fd001501ed050000Laut deiner Paket-Beschreibung sollte das 0x70 eine Länge von 12 haben, hier ist aber eine Länge von 59 angegeben und die tatsächliche Länge scheint 22 zu sein. Ich habe hier auch noch reichlich andere Pakete, bei denen die Länge scheinbar nicht wirklich passt. So ist zum Beispiel teilweise die tatsächliche Anzahl der Bytes zwischen den Paketen identisch aber die Länge im Header weicht voneinander ab oder die Pakete haben laut Header die gleiche Länge aber die tatsächliche Anzahl Bytes ist unterschiedlich. Letztendlich ist die Länge im Header aber immer deutlich größer als die tatsächliche Paketlänge 
Außerdem scheint das Controlbyte teilweise von deinen Beschreibungen des jeweiligen Messagetyps abzuweichen. So haben zum Beispiel die 0x70-Pakete das Controlbyte 0x84 statt die 0x86 aus deiner Beschreibung.
Hast du eine Ahnung, was es mit diesen Abweichungen auf sich hat?
Im Anhang habe ich mal meinen Dump der seriellen Schnittstelle angehängt. (Dump ist ungefiltert, Zeilenumbrüche an den vermuteten Paketanfängen, Paketanfänge aus den vermuteten Source-Adressen 42d81f und 3c94de und fortlaufenden Message Countern abgeleitet)
serial-dump.tgz (2.8 KB)
Hmm… aktuell sieht es nicht so doll aus. Anscheinend schickt LXCCU beim Start des rfd-Daemons eine Bit-Sequenz an den Adapter, der von den Timings her nicht sonderlich nach klassischem Serial aussieht:
LOW für 504 bis 516 µs
HIGH für 4.500.412 bis 4.500.792µs
LOW für 424 bis 452µs
HIGH für 260 bis 272µs
LOW für 256 bis 268µs
HIGH für 998.804 bis 999.608µs
LOW für 420 bis 428µs
HIGH für 256 bis 272µs
LOW für 256 bis 264µs
(Timings aus sechs rfd-Starts ermittelt)
Laut dem Error-Log beim Restart vom rfd scheint das zum einen mit dem “Start der Coprocessor Application” und dem Deaktivieren vom CSMA/CA zusammenzuhängen. Wenn ich raten müßte, ist das erste LOW der Start der “Coprocessor Application” (mit vergessenem Errorhandling) und dem anschließenden Kommando zur Deaktivierung von CSMA/CA mit Retry, da mein Arduino keine passende Bestätigung gesendet hat.
Ich werde morgen mal schauen, ab ich mal einen kompletten erfolgreichen “Handshake” zwischen rfd und dem Funkmodul und dem anschließenden Wechsel auf Serial abgreifen kann.
Zumindest ein wenig Entwarnung: Bei den Ergebnissen von gestern waren ein paar Fehler drin…
Also es wird scheinbar doch ganz normales Serial auch für die Initialisierung verwendet.
Ich habe es nach einigen Schwierigkeiten hinbekommen, zumindest die eine Richtung der seriellen Kommunikation abzugreifen.
Hier der Mitschnitt, was beim Start von LXCCU an das Funkmodul gesendet wird:
FD 00 03 00 00 03 18 0A
FD 00 03 00 01 03 9F 09
FD 00 03 00 02 02 14 0C
FD 00 04 00 03 0A 00 BD 07
FD 00 04 00 04 09 00 37 68
FD 00 03 00 05 21 58 FE
FD 00 08 00 06 0E 56 CD 5A 70 02 5F FC 7C
FD 00 04 01 07 03 00 9F 57
FD 00 06 40 08 3D 1C 6E B5 33
FD 00 09 00 11 06 42 D8 1F 00 00 00 4A AF
FD 00 09 40 21 90 28 F7 04 00 00 7B A4
FD 00 09 40 21 90 28 F7 04 00 00 6A A3
FD 00 09 01 0C 06 42 DC 1F 00 00 00 1A B0 Kannst du da etwas dir bekanntes wiederfinden?
Hier noch ein Dump, für den ich im WebUI die Temperatur des Heizungsthermostats schrittweise von 18°C auf 21°C und zurück auf 18°C gestellt habe:
FD 00 12 01 0D 01 00 00 00 01 B0 11 3D 1C 6E 42 D8 1F 86 04 23 19 3A (19°C)
FD 00 12 01 0E 02 00 00 00 12 B0 11 3D 1C 6E 42 D8 64 04 28 D0 5C (20°C)
FD 00 12 01 0F 02 00 00 01 13 B0 11 3D 1E 6E 42 D8 1F 86 04 2A 92 3E (21°C)
FD 00 12 01 10 02 00 00 01 1C B0 44 4F 8F 4B 61 1F 86 04 28 13 3E (20°C)
FD 00 12 01 11 02 00 00 00 25 B0 11 3D 1C 6E 41 D8 1F 86 04 27 DE 87 (19°C)
FD 00 12 01 11 02 00 00 01 2E B0 11 3D 1C 6E 41 D8 1F 86 04 24 17 C9 (18°C)Laut der XML-Datei habe ich da einen Messagetype 0x11 mit Subtype 0x86 an Channel 0x04 geschickt, die Adresse vom LXCCU scheint 0x3D1C6E (ist übrigens auch in der Initialisierung des Moduls wiederzufinden) und die des Thermostats 0x42D81F zu sein und der Messagecounter geht in diesem Block vermutlich von 0x0D bis 0x12 hoch.
Scheinbar habe ich allerdings beim Mitschnitt mit erheblichen Übertragungsfehlern zu kämpfen. Das wird vermutlich am Breadboard liegen 
Ich vermute, das einzige, was da hilft, ist, dass ich das anstatt über extra Hardware über sersniff o.ä. im Betriebssystem mach. Bei meinen bisherigen Versuchen bin ich da leider immer wieder an unzureichendem Wissen über Terminals und Pseudoterminals gescheitert…
Achja, als Übertragungsparameter für die serielle Verbindung habe ich 115200/8N1 angenommen. Kennst du eine Methode, wie ich das zuverlässig bestimmen kann? Wobei die obigen Ergebnisse ja auch schon nicht so schlecht aussehen.
Wie schätzt du denn basierend auf den bisherigen Protokollmitschnitten die Erfolgsaussichten ein? Ich denke, ich sollte es noch irgendwie hinbekommen, einen fehlerfreien Trace der Kommunikation zwischen LXCCU und HM-MOD-UART hinzubekommen, der auch beide Richtungen abdeckt.
So, ich habe jetzt einen Dump, der keine Übertragungsfehler mehr enthält und konnte da auch schon ein paar Sachen rausziehen.
Die ganze Kommunikation mit dem HM-MOD-UART erfolgt über eine serielle Verbindung mit den Parametern 115200 Baud 8N1.
Ganz zu Anfang erfolgt eine Initialisierung des Funkmoduls. Das besteht u.a. scheinbar aus einem simplen Hello, Abfragen von Firmware-Informationen setzen (bzw. eher deaktivieren) von CSMA/CA, setzen der CCU-Adresse, …
Anschließend werden die Geräte-Adressen, die dem RFD(oder irgendwem darüber) bekannt sind, an das Funkmodul übertragen. Scheinbar übernimmt bereits das Funkmodul das Wegfiltern von “fremden” Paketen. Aus einem mir unbekannten Grund wird dem Modul dabei jede Geräteadresse gleich viermal genannt…
Danach geht das der RFD und das Modul in den normalen Betrieb über schickt die üblichen Befehle und Statusänderungen an die Geräte…
Der allgemeine Aufbau eines Kommandos an das Modul ist folgendermaßen:
"FD 00" <1 Byte Länge> "00 | 01" <1 Byte Zähler> <Payload> <2 Byte Checksumme>[ul]
[li] Die Länge wird ohne Präfix, Länge und Checksumme gezählt[/li]
[li] Im vierten Byte steht “00” vermutlich für “SystemCommand” und “01” für “BidCosRequest”.[/li]
[li] Der Zähler wird global gezählt und nicht pro Zieladdresse.[/li]
[li] Wenn es sich um einen BidCosRequest handelt, hat das erste Byte der Payload nochmal eine qualifizierende Funktion:
[list]
[] 0x02: Die “klassischen” BidCos-Pakete [/li]
[li] 0x06: Hinzufügen einer bekannten Device-Adresse[/li]
[li] 0x04: Responses, sowohl auf 0x02 als auch auf 0x06 und sogar auf SystemCommands…[/li][/ul][/:m][/list:u]
Bei 0x02-BidCos-Requests und bei 0x04-Antworten auf die 0x02-BidCos-Requests folgt anschließend immer die feste Folge “00 00 01 01” gefolgt von Control-Byte, Message-Type, Sender- und Empfänger-Adresse und den Parametern.
Den Abschluss bildet bei allen Messages eine Checksumme mit 2 Byte Länge… Bei der bin ich noch am knobeln, wie die berechnet wird. Wenn ich die rausbekomme, kann ich mal versuchen, direkt mit dem Funkmodul oder dem RFD zu sprechen…
Ich hänge mal einen Dump mit ein paar Anmerkungen an. Falls jemand eine Idee hat, wie man den unbekannten Teilen noch auf die Spur kommen könnte oder falls mir bei der Interpretation irgendwo ein Fehler unterlaufen ist, bin ich über Feedback dankbar.
HM-MOD-UART-Analyse.txt (4.5 KB)
So, die Checksumme hab ich. Es wird ein CRC-16 mit Initial-Wert 0xD77F und dem Polynom 0x8005 von der ganzen Message inkl. Präfix und Länge verwendet.
Ich werde morgen mal sehen, ob ich es hinbekomme, auf dem Raspi über ein kleines selbstgeschriebenes Programm die Temperatur meines Thermostats zu ändern. Dazu müsste ich zwar einiges an hart kodierten und nicht komplett verstandenen Byte-Sequenzen Richtung HM-MOD-UART schieben und ein paar Rückgaben des Moduls weitestgehend unverstanden ignorieren.
Ich werde dann noch versuchen, das Modul mal gezielt mit Nonsens zu beschießen, um die Fehler-Antworten des Moduls identifizieren zu können. Außerdem werde ich noch sehen, ob ich rausbekomme, in welchen Situationen OCCU die Reset-Line verwendet. Da die aber laut Doku auch auf /dev/null gesetzt werden kann, ist das vermutlich nicht ganz so wichtig…
@Sathya: Wenn das klappt, was wäre noch nötig, bevor es mal experimental in Homegear aufgenommen werden könnte?
HM-MOD-UART-Analyse.txt (5.35 KB)
Hallo Stefan,
danke für deine Analyse! Das hat echt geholfen! Soweit hättest du auch gar nicht gehen müssen, die Pakete sind denen des LAN-Gateways sehr ähnlich. Ich habe den HM-MOD-RPI-PCB dann auch gleich mal implementiert 
. Sieht soweit alles gut aus. Auch WoR-Pakete und Firmware-Updates klappen ohne Probleme. Jetzt braucht es Tester! Das Nonsens-Log wäre noch ganz interessant. Ich vermute aber mal, das Modul gibt dann NAKs zurück?
Viele Grüße
Sathya
Mit dem Nonsens-Log hatte ich bisher etwas Probleme - ich habe jetzt mehrfach versucht, über ein kleines Java-Programm das Modul zu initialisieren (00 00 03) um danach loszulegen. Dazu hab ich beim ersten Mal testweise die Reset-Leitung mal kurz auf High gezogen und dann die Initialisierung versucht, da hat das Modul leider nicht mehr drauf geantwortet. Auch ein Start von LXCCU lief nicht mehr, da das Modul auch dem dem rfd scheinbar nicht geantwortet hat (Immerhin: Das Modul hat sich mir gegenüber genauso verhalten wie dem rfd gegenüber). Mehrfache Reboots des Containers und des RasPis haben nichts gebracht. Erst das neue aufspielen des LXCCU-Images hat das Modul wieder zum Reden gebracht
Wenn ich den Container ohne LXCCU starte und mit meinem Testprogramm das Modul initialisiere, hat es den gleichen finalen Effekt.
Wenn ich den Container starte und stoppe und dann mein Programm ranhänge, die serielle Verbindung also schon steht, bekomm ich anständige Ausgaben, also sowohl die Statusmeldungen der Devices als auch Antworten auf meine Messages (interessante Details: Der Counter ist nicht so wichtig - ich kann auch immer 00 schicken, bekomme dann aber ggfs Probleme damit, die Antworten auf meine Messages zuzuordnen. Anderes Detail: Es schadet scheinbar nicht, dem bereits initialisierten Modul eine erneute Initialisierungsaufforderung zu schicken. Man bekommt zwar die sauberen Antworten aber das Modul behält seine vorherige Konfiguration und wird nicht zurückgesetzt.)
Ich vermute aber, dass meine Probleme eher damit zusammenhängen, dass ich mit meinen Verbindungsversuchen immer irgendwas mit dem Serial-Terminal und dem LXC-Container durcheinanderbringe.
Bei dir klappt auch das frische initialisieren des Moduls mit der beschriebenen Sequenz?
Wo ist denn der entsprechende Teil vom LAN-Gateway-Protokoll beschrieben? Mich würden da mal die Teile interessieren, die ich nicht rausbekommen habe.
Als Tester stehe ich sehr gerne zur Verfügung, muss mir dazu aber vermutlich erstmal OpenHAB o.ä. aufsetzen…
Allerdings wirst du sicherlich noch weitere Tester benötigen, da mein Gerätepark mit den vier Heizungs- und einem Wandthermostat sehr überschaubar ist…
Hast du die aktuelle Implementierung in Github in einem Branch?
Leider ist das mit dem Nonsens-Log ein Problem: Ich habe keine Ahnung, welche Messages falsch sind und welche existieren. 
Was ich aber rausbekommen habe, ist dass ungültige Messages (falscher Präfix, falsche Checksumme, viertes Byte ungleich 00 oder 01, …) einfach ignoriert werden und keine Response bekommen. Wenn ich an gültige Messages hinten (noch in die Payload) zusätzliche Bytes anhänge, scheinen die einfach ignoriert zu werden und die Message wird akzeptiert.
ok, das hilft aber doch schon einmal. Die NAKs wären zwar besser als keine Antwort (weil ich auf eine Antwort warte), aber solange wir aus Homegear keinen Blödsinn senden, sollte es keine Probleme geben.
Viele Grüße
Sathya
Ich werde mal schauen, was so kommt, wenn ich reguläre BidCos-Messages mit unsinnigem Inhalt schicke (Temparatur außerhalb des Wertebereichs o.ä.). Da sollte ja eigentlich das entsprechende Device das verarbeiten und da würde ich dann schon ein NACK erwarten. Ich habe jetzt halt erstmal das Problem, ein NACK vom Modul überhaupt zu erkennen. Ich glaube, da gibt es was (viele unterschiedliche Meldungen führen alle zur gleichen Antwort), bin mir aber nicht sicher.
Ich habe heute mal in deinen Code reingeschaut, dabei ist mir aufgefallen, dass du bei der Initialisierung diese Messages, um dem Modul die relevanten Device-Adressen mitzuteilen, nicht schickst. Sind die nicht notwendig oder waren die nur in deinem aktuellen Setup nicht relevant, weil du nach dem Start eh das Pairing gemacht hast oder so?
Meinst du diese hier in der Funktion sendPeer? https://github.com/Homegear/Homegear-HomeMaticBidCoS/blob/master/src/PhysicalInterfaces/Hm-Mod-Rpi-Pcb.cpp#L517
Ja, genau die hatte ich gesucht
Ich bin grade dabei, den Master auf dem Raspi zu kompilieren - du hast ja irgendwo geschrieben, dass es etwas dauert, aber das dauert ja echt ewig! 
Gibt es eigentlich eine Möglichkeit, dass ich meine Geräte sowohl mit Homegear als auch mit LXCCU gleichzeitg gepaired haben kann? Hintergrund ist einfach, dass ich normalerweise mein einigermaßen stabiles LXCCU regulär laufen lassen will und erstmal nur auf die Experimentier–SD-Karte mit homegear und OpenHAB wechseln will, wenn ich aktiv damit arbeite.
Ich vermute, regulär ist es nicht möglich, da die Geräte ja nur mit maximal einer Zentrale koppeln können, aber kann ich z.B. in Homegear einfach die gleiche Device-Adresse für die Zentrale setzen, die rfd auch verwendet? Also die Adresse im <01 cc 00 AD DR ES>-Kommando beeinflussen? Dann sollte es doch eigentlich klappen, beide Zentralen im Wechsel miteinander zu betreiben (sofern ich darauf achte, dass beide Zentralen immer die gleichen gepairten Geräte kennen), oder?
Mir sind gestern übrigens noch drei Kleinigkeiten aufgefallen:
1.) Die Response <00 cc 04 04> scheint wohl irgendwie ein “Unbekanntes System-Kommando” oder “Modul in falschem Modus für dieses System-Kommando” o.ä. zu sein. Zumindest wird scheinbar auf mehrere der Syntax nach System-Kommandos diese gleiche Antwort geschickt (<00 cc 00> bis <00 cc 03> und <… 0A> bis <… 0D> reagieren irgendwie individuell und die übrigen werden alle mir <04 04> beantwortet.
2.) Irgendwie scheint es möglich zu sein zumindest temporär die Firmware-Version, die von <00 cc 02> geliefert wird, zu ändern bzw. zu löschen… Auf jeden Fall hatte die bei mir nach dem wilden Durchprobieren von Kommandos in dem Kommando für die Versionsabfrage einfach gefehlt…
3.) Irgendwie scheint es möglich zu sein, das Modul dazu zu bringen, den Präfix <FD 00> nicht mehr mitzusenden… Besonders irritierende ist, dass es auch mit der anderen SD-Card nicht mehr lief. Nach dem frischen Aufsetzen der SD-Card läuft es aber wieder korrekt…
Du hattest erwähnt, dass das Protokoll für den HM-MOD-UART sehr ähnlich dem Protokoll fürs LAN-Gateway ist - wo ist denn dazu was zu finden? Mich würden da insbesondere diese System-Kommandos interessieren. Im Netz habe ich nur einen Verweis auf das Protokoll von Homematic-Wired gefunden, aber das scheint sich doch deutlich von dem hier zu unterscheiden…