Neuer Bus bei einigen Brötje Heizungen: R-Bus

[Frederik H. (freetz)]

Hallo zusammen,

nachdem Brötje und andere Heizungshersteller lange Zeit auf den von 
Siemens bzw. Landis&Gyr entwickelten BSB- bzw. LPB-Bus gesetzt haben 
(siehe auch hier im Forum: Beitrag "Brötje ISR Plus Kommunikation / LPB" 
), scheint es bei Brötje nun zumindest bei den "einfacheren" Thermen 
einen neuen Bus zu geben, der "R-Bus" genannt wird. Es scheint, dass 
darüber bisher nur wenige Spezifikationen bekannt sind, und das, was die 
Anleitungen für die Fachkraft hergeben, ist eher dünn und nennt nur die 
elektrischen Parameter (Busspeisung 24V, zweiadriges Kabel, 
verpolungssicher).

Da ich Interesse hatte, zu schauen, ob sich dieses Bus-System in unser 
BSB-LAN-Projekt (https://www.github.com/fredlcore/bsb-lan ) irgendwie 
einbinden lässt, habe ich mir mal die Brötje IDA, ein WLAN-fähiges 
Raumgerät, das auf R-Bus-Basis läuft, kommen lassen, und es etwas 
untersucht. Leider scheint es von Grund auf inkompatibel mit BSB bzw. 
LPB zu sein, weshalb dafür auch eigene Gateways nötig sind (GW16 für 
OpenTherm-Heizungen, GW17 für Heizungen mit BSB-Anschluss). Vielleicht 
helfen aber diese Erkenntnisse anderen, die sich an der Entschlüsselung 
dieses Protokolls versuchen wollen:

Der Bus scheint über die Veränderung der Stromstärke Daten zu 
übertragen, denn trotz sehr häufiger und regelmäßiger Datenübertragung 
(die IDA fragt alle paar Sekunden die Heizung ab, was ich wiederum 
hinter dem BSB-Gateway mit meinem Interface sehen konnte), bleibt die 
Spannung auf "unruhigen" 22V (siehe Bild). Das wäre eine Parallele mit 
OpenTherm, das zumindest in eine Richtung auch über die Veränderung der 
Stromstärke Daten überträgt. Nur mit einiger Vergrößerung erkennt man in 
regelmäigen Abständen Schwankungen um etwa ein Volt, die aber ziemlich 
unsaubere Flanken haben und für eine Datenübertragung wohl nicht in 
Betracht kommen.

Da OpenTherm ja zwischen Raumgerät und Kessel über Spannungsveränderung 
und vom Kessel zum Raumgerät über Stromstärkenveränderung kommuniziert, 
müsste ja eigentlich eine Spannungsveränderung zu sehen sein, wenn ich 
etwas an der IDA verstelle, was nachweislich bei meiner Heizung 
angekommen ist. Da OpenTherm aber hinsichtlich der Spannung zwischen 7V 
(low) und 15-18V (high) arbeitet, liegt der R-Bus-Pegel aber sowieso 
jenseits dessen. Die Frage ist, ob die kleinen Spannungseinbrüche auf 
eine Veränderung der Stromstärke schließen lassen würden, was ein Indiz 
dafür wäre, dass R-Bus möglicherweise in beide Richtungen über eine 
Veränderung der Stromstärke arbeitet.

In dieser Anleitung der Brötje WLS/WLC 
(http://polo.broetje.de/pdf/7705977_wlc-wls_ng1_installer_-_de.pdf.pdf) 
steht auf S. 52, dass Anschluss X8 sowohl R-Bus, als auch On/Off als 
auch OpenTherm unterstützt (über einen Brötje OT RGI?). Von daher könnte 
es so sein, dass R-Bus ein auf OpenTherm aufbauendes Protokoll ist, und 
OpenTherm ja wiederum das On/Off-"Protokoll" inkludiert (Kurzschluss auf 
der Leitung bedeutet bei On/Off-Raumgeräten eine Wärmeanforderung, bei 
offenem Kontakt entsprechend keine).

Leider scheint der R-Bus aber nicht wirklich mit OpenTherm kompatibel zu 
sein, denn beim Anschluss an eine OpenTherm-Arduino-Schaltung 
(http://ihormelnyk.com/arduino_opentherm_controller ), rauchte diese 
kurz nach dem Anschluss buchstäblich ab :(.
Ohne weitere Informationen (und bei meinen begrenzten 
Elektronik-Kenntnissen) bin ich da dann in einer Sackgasse gelandet.

Im nächsten Schritt habe ich dann geschaut, wie die IDA und die 
dazugehörige App miteinander kommunizieren.
Halbwegs beruhigend ist, dass die Daten über SSL verschlüsselt versendet 
werden. Und so wie es scheint, pollt die IDA regelmäßig (ca. alle 5-10 
Sekunden) den Server und wird dabei vermutlich schauen, ob es eine neue 
Einstellungsänderung von der App gibt, bzw. übermittelt Änderungen wie 
Außentemperatur etc. an die App. Die IDA antwortet auf dem Port 42445, 
aber das kann sein, dass das nur temporär ist und jedes Mal neu 
ausgehandelt wird.

Dann habe ich mal nachgeschaut, wohin die Daten gehen: Da ist seitens 
der IDA erstmal eine IP-Adresse die nach 
91-103-172-8.no-dns-yet.acs-ito.co.uk auflöst. Hinter der 91.103.172.8 
verbirgt sich dann die Domain "remoteapp.bdrthermea.com" auflöst. Und 
diese Firma wirbt dann unter "www.bdrthermeagroup.com" damit, dass sie 
"a world leading manufacturer and distributor of smart climate and 
sanitary hot water solutions" sind. Wikipedia sagt, dass denen auch 
Brötje gehört, was vermuten lässt, dass die anderen Marken dieser Gruppe 
(Baxi, Remeha, SenerTec, Oertli) vermutlich auch diese Infrastruktur 
nutzen. Die App verbindet sich mit der IP 91.103.172.11 - immerhin 
hoffentlich ein physikalisch anderer Server. Dafür wird hier im 
Sekundentakt abgerufen - klar, die Anzeige in der App soll ja möglichst 
aktuell sein.

Zwar hat die Firmengruppe ihren Sitz in den Niederlanden, und das steht 
so auch in der Datenschutzerklärung der App drin, aber die Server, an 
die die Daten geschickt werden, steht in England. Genauer gesagt bei 
einer Firma, die sich "Atos IT Outsourcing Services Ltd" nennt. 
Eigentlich müsste dies in der Datenschutzerklärung aufgeführt werden, 
wenn Auftragsverarbeitungsunternehmen eingesetzt werden. Und wie das da 
datenschutzrechtlich aussieht, wenn der Brexit vollzogen ist, weiß wohl 
keiner so genau. Ich fände es vermutlich auch noch irgendwie erträglich, 
wenn da nur die Temperatur-Daten fließen würden - aber man kann sich in 
der App nur unter Angabe des Namens, Geburtsdatums und der Adresse 
anmelden. Ob die dann nur bei Brötje liegen oder auch nach England 
gehen, wage ich zu bezweifeln...

Immerhin scheint die IDA relativ gut abgesichert zu sein - lässt sich 
nicht anPINGen, ein Portscan findet auch keine offenen Türen, und durch 
das Polling kommen eingehende Daten nur von der per SSL verifizierten 
Quelle in England. Um hier also die IDA zu hacken, müsste man im 
heimischen Netzwerk die Ziel-IP umbiegen und gleichzeitig darauf hoffen, 
dass die IDA den Zielservern nicht anhand des SSL-Zertifikats überprüft, 
sondern fröhtlich drauflos sendet.

Zuguterletzt hänge ich noch ein Foto eines geöffneten R-Bus/BSB-Gateways 
(GW17) an, für den Fall, dass das noch Aufschlüsse ermöglicht.

Schlussendlich ist dieser Bus sicher kein Ersatz für BSB oder LPB, die 
mehrere Raumgeräte und auch mehrere Erzeuger ansteuern können. Man sieht 
den Heizungen, die diesen Bus verwenden, auch schon an, dass sie dem 
Nutzer weniger Möglichkeiten bieten (LCD-Anzeige statt Text, dazu auch 
stark begrenzte Einstellungsmöglichkeiten an der Therme, noch nicht mal 
die Änderung der Heizukurve am Gerät selber möglich, wenn man kein 
Service-Techniker ist). Für Nutzer, die sich das Gerät in die 
Etagenwohnung hängen und per App darauf zugreifen wollen, aber 
vielleicht ausreichend. Insofern wäre eine Entschlüsselung der 
Übertragung sicher eine gute Sache - nur werde ich mangels passender 
Gerätschaft da nicht mehr viel beitragen können und mich wieder auf die 
Weiterentwicklung von BSB-LAN konzentrieren...

Gruß,


F.

[Joerg N. (oneill)]

Ich will zwar keine Leichen ausgraben, aber die Google-Suche nach 
Informationen zum Remeha  Brötje  BDR-Thermea R-Bus führt ziemlich 
schnell hierher.

Jemand hat erste Erfolge beim Reverse-Engineering des Protokolls erzielt 
und die Ergebnisse bei github veröffentlicht.

https://github.com/pepijndevos/R-Bus

Hoffe das hilft vielleicht einigen, die hier stranden und vielleicht 
auch dem TE

[Frederik H. (freetz)]

Prima, danke für den Hinweis, für mich ist damit klar, dass das System 
komplett inkompatibel mit BSB-LAN ist, sowohl hard- als auch 
softwareseitig, so dass ich das jetzt in Frieden ruhen lassen kann. Aber 
für alle R-Bus-Regler ist das natürlich eine sehr gute Nachricht!