Buderus Web KM 200: Wie sollte eine offene Hausautomationsschnittstelle aussehen?

Buderus Web KM 200: Wie sollte eine offene Hausautomationsschnittstelle unserer Heizgeräte zukünftig aussehen?

In den letzten Jahren ist in der Heizungstechnik eine große Veränderung hin zu energieeffizienten und an die jeweiligen Häuser angepassten, elektronisch geregelten Heizungssystemen zu beobachten. Allein für Lösungen von Buderus ergeben sich durch die Kombination unterschiedlicher Wärmeerzeuger, Module und Regler mehr als 3000 verschiedene Systemkonfigurationen.

Die Erweiterung der Heizungssysteme um eine Interaktionsmöglichkeit mittels der App „EasyControl“ für den Endkunden und der App „EasyControlPro“ für den Installateur ist kundengetrieben und leitet sich z.B. aus Kundenbefragungen ab.

Der sichere Betrieb der Heizungssysteme, der Zugriffsschutz vor Fremden sowie schnelle Hilfe vom beauftragten Installateur waren oft genannte Anforderungen, die wir als verantwortungsbewusstes Unternehmen sehr ernst nehmen und in unserer Produktentwicklung Schritt für Schritt umsetzen.

Die Verschlüsselung der Dateninhalte jedes Gateways mit einem individuell generierten Passwort und dem vom Besitzer selbst definierten persönlichen Passwort stellt mit dem zugrundeliegenden Verschlüsselungsverfahren den Stand der Sicherheitstechnik für eine Verbindung zwischen Endgeräten dar.

Wie aus dem Bereich der vernetzten Personal Computer bekannt, ist eine ständige Verbesserung der Sicherheitsmechanismen notwendig, um ungewollte Zugriffe auf Daten und damit eventuellen Missbrauch zu verhindern. Entsprechend werden wir die von Slash aufgedeckten Lücken schnellstmöglich schließen und weiter kontinuierlich an der Verbesserung unserer Produkte arbeiten.

Der Schutz vor Missbrauch unserer Systeme und des privaten Eigentums unserer Kunden, insbesondere vor dem Hintergrund zunehmender Komplexität der Systeme, war der Grund für unsere Entscheidung zunächst ein geschlossenes System im Markt einzuführen.

Die Rückmeldungen, die wir zwischenzeitlich von unseren Kunden bekommen, zeigen den Bedarf an einer offenen und sicheren Schnittstelle zu unseren Heizungssystemen auf. Daher möchten wir neben den klassischen Wegen der Anforderungsdefinition auch die Hinweise der Netzwerk-Community mit einfließen lassen. Deshalb freuen wir uns auf den Dialog mit der Community, um insbesondere zu erfahren, welche Heizungsressourcen für eine offene Hausautomationsschnittstelle unserer Geräte von Interesse sind.

Euer

IP-Team der Bosch Thermotechnik GmbH

Bevor ich mir Gedanken über meine Vorstellungen zu meiner eingesetzten Technik mache, erstmal ein großes „Daumen hoch“ für diesen Schritt.

Ehrlicherweise hätte ich das nicht für möglich gehalten, nachdem ich die Entwicklunggeschwingigkeit Eurer App „buderus easy control“ erleben mußte.

Respekt

Wenn das wirklich jemand aus dem Buderus/Bosch Umfeld ist, dann muss ich sagen, mutig und super :).

Da keimt ja Hoffnung auf, dass ich in 3-5 Jahren meine GB122 gegen etwas „besseres“ austauschen kann, das dann wenigstens Tag-/Nacht-Umschaltung „von außerhalb der Heizung“ kann.

Hallo,

vielen Dank, dass ihr den offenen Dialog mit der Community sucht. Damit ist ein wichtiger Anfang gemacht :slight_smile:

Das ist korrekt. Korrekt ist aber auch, dass die zur Erzeugung des AES-Schlüssels verwendete Generierungsmethode nebst Salt ohne Sicherheitseinbußen veröffentlich werden kann.

Hier habe ich auch zwei konkrete Verbesserungsvorschläge:

[ul]
[li]Für jede Session oder sogar für jedes Datenpaket ein neues, zufällig generiertes Salt verwenden, welches im Klartext mit jedem Paket übertragen wird. Jedes Salt wird mit einer zugehörigen Rainbow-Tabelle unsicher. Mit festem Salt würde man für die Kompromittierung des Gesamtsystems genau eine Rainbow-Tabelle benötigen, mit zufälligem Salt für jede Session bzw. jedes Datenpaket eine eigene Rainbow-Tabelle (mit mehreren TB Größe).
[/li][li]CBC-Blockchiffre mit zufälligem Initialisierungsvektor für die Verschlüsselung des JSON-Payload.
[/li][li]
[/li][/ul]

Und natürlich der Rückbau des Fallbacks auf PLAIN-Authentifizierung.

Dieses Argument kann ich nicht nachvollziehen. Wie bereits erwähnt, die für den AES-Schlüssel verwendete Generierungsmethode nebst Salt kann ohne Sicherheitseinbußen veröffentlich werden - dass ist vom Design der Crypto so vorgesehen.

Ein Cryptosystem, welches aus Sicherheitsgründen auf Geschlossenheit baut, ist zum einen bereits vom Design her unsicher, und zum anderen im Ergebnis kundenunfreundlich.

Auch die von mir bislang inspizierten Steuerungen der Heizungsanlage über JSON haben keine Sicherheitsproblematik aufgeworfen, sondern ein klar erkennbares Konzept von read-write und read-only.

Daher bitte ich um eine nähere Erläuterung dieses Arguments.

Falls es eine Sorge der Implementierungsreife gab, die man gerne im geschlossenen Kreis erreichen wollte, wäre spätestens jetzt der richtige Zeitpunkt gekommen diesen Kreis zu öffnen.

Zuerst die Gretchenfrage:
Warum fällt der von mir hier veröffentlichte und mittlerweile gelöschte Salt eurer Meinung nach unter das Urheberrecht, und wie steht ihr derzeit zu einer Wiederveröffentlichung? Bitte hierzu meine obige Argumentation bezüglich des Sicherheitsaspekts beachten.

Welche Ressourcen der Heizanlage ich gerne steuern wollte schreibe ich in einem separaten Post.

Bis hierher erst einmal vielen Dank für das Angebot der offenen Kommunikation.

Ich finde es sehr großartig das hier jetzt eine offene Diskussion stattfinden kann und hoffentlich auch fortbestehen wird.
Ich hätte nicht gedacht das sich nach der Löschung des ersten Themas jemand von Bosch zu Wort meldet.
Ich muss hier ein großes Lob für beide Seiten aussprechen denn es ist nicht selbstverständlich das Unternhemen auf diese Weise die Community einbinden.
Und vor allem auch ein Lob an Slash der trotz allem weiter gemacht hat, finde ich wirklich Super.

Wirklich schön, dass Bosch dazu was sagt.

Ich betreibe das WebKM200 und die App von Buderus.
Meine Hoffnung war, darüber die Zirkulationspumpe der Warmwasserversorgung steuern zu können.

Ich suche nach einer Möglichkeit, dieses Pumpe neben dem Zirkulationsprogramm zusätzlich bei Bedarf einzuschalten und hatte immer die Hoffnung, dass diese Form der Bedienung über WebKM200 irgendwann erweitert würde.
Der EMS-Bus bietet dazu doch sicherlich eine Möglichkeit.
Leider kann ich das RC35 meines GB172 nicht in der Wohnung plazieren, sodass eine Bedienung darüber nicht geht.
Ein vom Kessel abgehängtes Steuerungssystem für die Pumpe wäre für mich auch möglich, würde aber noch ein Gerät im Heizungskeller erfordern.

Meine Bitte an Buderus deshalb, die Steuerung der Warmwasserzirkulationspumpe über WebKM200 zu ermöglichen.

Moin zusammen… also vom Umfang der offenen Schnittstelle, wünsche ich mir, alles das zu steuern, was ich auch am Gerät manuell ändern kann. So wie ich das bisher gesehen habe. Also das was die KM200 mit dem speziellen :wink: Zugriff möglich macht. Da habe ich bisher keine Dinge gesehen, die besonders schützenswert gewesen wären. Natürlich können die Daten die Heizungsmonteur benötigt werden, weiterhin verborgen bleiben. Was will man denn…

Comfort/Eco… Day/Night Temperatur einstellbar

Tagesprogramme

Aktueller Modus + Temp

Störungen und Meldungen

Umwälzpumpe steuern

Evtl ganze Heizung an/aus

Man kann jetzt zwar noch ein paar extra Werte auslesen, wie Vor/Rücklauftemp oder Modulation. Aber das ist dann ja schon wieder spezieller.

Also nur das was ich an der Heizung oder am externen Regler einstellen kann.

Jemand anderer Meinung?

Was mich noch interessieren würde, ist eine sinnvolle Verbrauchsbewertung oder zumindest Unterscheidung zwischen Heizen und Warmwasser.

Gemeinsam mit dem Gasverbrauch könnten die tatsächlichen Werte für Heizen und Warmwasser bewertet werden. Die Annahmen sind bei meinem gut gedämmten Haus und 2Langeduschern" eher unwahrscheinlich.

Ich würde gerne auf alle Bereiche zugreifen können. Angefangen von den Standardsachen bis zu der Heizkurve. Wenn ich schon Hausautomation mache, dann richtig. Gerade in der Übergangszeit würde ich der Heizung gerne helfen, denn optimal ist das nicht immer.

Liebe Community,

zuerst möchten wir uns für die Antworten bedanken. Wir sehen zwei Themengruppen für die weitere Diskussion

• Direkte Antwort auf die Fragen und Anregungen von Slash
• Diskussion hinsichtlich der Parameter der öffentlichen Schnittstelle

Slash hat recht mit der Aussage, dass man bei heutigem Stand der Technik die Generierungsmethode bei der gewählten Schlüssellänge nebst Salt ohne nennenswerte Sicherheitseinbußen veröffentlichen kann. Dies gilt jedoch nach unserer Auffassung nur unter Rahmenbedingungen, die wir nicht sicherstellen können.

Aus unserer Sicht müssen hierzu das individuelle Passwort des Gateways und das persönliche Passwort des Kunden geheim bleiben. Dies ist jedoch dann schon nur eingeschränkt gegeben, wenn der Installateur das Gateway installiert und sich das Gateway-Passwort aufschreibt. Gibt der Kunde dann sein persönliches Passwort noch weiter, entsteht hier eine ungewollte Sicherheitslücke.

Mit der Reset-Taste am Gateway kann man das persönliche Passwort zurück setzen. Der Eigentümer kann mit dieser Maßnahme sein Gateway mit einem neuen Passwort versehen und somit die Sicherheit wieder erhöhen. Das Salt erhöht bei Teilinformation der Schlüssel die Sicherheit im Allgemeinen.

Slash hat Maßnahmen zur Verbesserung vorgeschlagen. Entwicklungen mit analogen Vorschlägen wurden bereits begonnen. Der Rückbau des Fallbacks auf PLAIN-Authentifizierung ist erfolgt. Besten Dank für die Hinweise!

Der GB122 hat keine Schnittstelle, die wir mit dem Web KM 200 unterstützen können.

Die unterstützten Systeme von Buderus mit Wärmeerzeuger, Systemregler und Systemmodulen generieren über 6000 unterschiedliche Datenpunkte. Diese sind größtenteils nur lesbar, eine Reihe davon können auch beschrieben werden.
Herr der Daten ist die jeweilige Komponente oder der Systemregler. Die Einstellungen der Programme und deren Funktionen sind aufeinander angepasst und verhalten sich unterschiedlich bei verschiedenartigen Randbedingungen.
Einfache Beispiele sind die Einbindung von solarer Wärme oder die Regelstrategie bei gut oder schlecht gedämmten Häusern. Auch ist die Pumpennachlaufzeit abhängig vom Typ und der Leistung des Wärmeerzeugers.

Die Freigabe von Daten der Tagesprogramme, eingestellter Modi oder Meldungen, die heute auch bei den Apps Verwendung finden, sind ohne Minderung der Sicherheit im Heizungssystem realisierbar. Komforteinschränkungen sind hier durch Fehleinstellungen möglich.
Die Gruppe der gemessenen Werte wie Temperaturen oder Laufzeiten stellt ebenfalls keine Herabsetzung der Sicherheit dar.
Die Möglichkeit der vollständigen Abschaltung der Heizung oder der Umwälzpumpen ermöglicht bei falscher Handhabung eine Schädigung der Heizung bei Frost. Diese Gruppe von Daten würden wir eher nicht oder nur bedingt freigeben.

In Summe denken wir, dass wir die Daten basierend auf Anwendungsfunktionen, wie von Ralf beispielhaft dargestellt im Beitrag „Bestimmung des Energieeinsatzes für Heizen im Vergleich zu Warmwasser“, in einer offenen Schnittstelle bereitstellen können.

Wir freuen uns auf den weiteren Dialog mit Euch,

Euer IP-Team der Bosch Thermotechnik GmbH

Also sorry, wenn ich ne Schnittstelle freigebe, dann dürfte klar sein, dass ich damit Sachen machen kann, die der Laie evtl lassen sollte. Das Risiko legt klar beim Nutzer.

Ich kann heute schon - wie jeder halbwegs technisch Versierte - auf alle Daten direkt am RC35 oder über den ServiceKey zugreifen und diese ändern. Werde ich da ausgesperrt, dann gaukle ich halt der Heizung Zustände (bspw. Temperaturwerte) vor, die ich selbst beeinflusse. Es gibt immer Wege.

Ne Heizungssteuerung ist nun nicht wirklich etwas kompliziertes. :smiley:

Also ich finde, dass eine offene Schnittstelle nun nicht die Möglichkeit bieten sollte, unter gewissen Umständen die Anlage zu zerstören!!!
Natürlich kann jeder fummeln wie er will - dann ist halt die Garantie dahin. Aber wenn der Hersteller uns schon etwas bieten möchte, dann sollte das trotzdem innerhalb der Garantie laufen. Sprich die Sicherheit muss jederzeit gegeben sein.

Wie wäre es, wenn es zwar gewisse Schnittstellen für Dinge gibt, die „gefährlich“ sind, aber die dann bei Nutzung entsprechende Fehlermeldungen zurück geben. Also so eine Art „locking system“. Mir fällt jetzt direkt kein Fall ein (weil für mich die Heizung eher komplex wirkt). Aber mal ein laienhaftes Beispiel…

Setze Warmwassertemp auf 60 Grad -> Fehlermeldung: Nicht möglich - Umlaufpumpe deaktiv
Setze Umlaufpumpe deaktiv -> Fehlermeldung: Nicht möglich - Warmwassertemp > 50 Grad

Wenn Pumpe aktiv wäre… dann könnte es gehen.

Für diese Fälle müsste man dann allerdings nicht nur Parameter schreiben, sondern jederzeit auch lesen können. Dürfte klar sein.

Die Fehlermeldungen müssten dann sicher entsprechend kodiert sein, damit man mehrere blockierende Zustände erkennen kann.

Wenn Ihr das schon öffentlich hier anfragt, wäre es sicherlich auch interessant zu wissen, wann Ihr ungefähr eine Veröffentlichung anpeilt, und wie es um die Verteilung steht.

Genau für den Personenkreis reicht die Einstellung durch den Heizungsfachmann und dann läßt der Hausbesitzer besser komplett die Finger davon.Ich hab schon viele Heizungen gesehen, die völlig widersinnig eingestellt waren.

Nicht vergessen. Eine offene Schnittstelle soll ja nur die Möglichkeit für Programmierer bieten.
Bosch wird in Ihrer App keine Zerstörungsmöglichkeit bieten und andere Apphersteller besser auch nicht.
Dennoch sollte es dem Programmierer freigegeben sein, genau darüber zu entscheiden und das entsprechend zu vertreten.
Bspw. wurde hier schon einmal die automatisierte Anpassung der Heizkennlinie angesprochen. Sehr interessant für Erfahrene aber garantiert nix für Laien.

Hier geht es m.E. nicht darum, was Lieschen Müller anstellen könnte, wenn Sie wollte. Das kann ich auch außerhalb der Schnittstelle mit diversen Aktionen.

Und wer trägt dann bei einem defekt die Gewährleistung? Sicher nicht der App Hersteller, nur weil er das Endgerät falsch bedient (über die offene Schnittstelle) hat.

Versteh mich nicht falsch, denn ich will auch gerne so viele Einstellmöglichkeiten haben wie möglich sind. Aber hier muss Bosch bzw. die ganzen Heizungshersteller ja auch entsprechende Sicherheiten haben.

Ich hab mein Statement gegeben. Ich halte gar nix von „kastrierten“ Schnittstellen.

Bosch kann ja die Nutzung der Schnittstelle generell unter den Ausschluß jeglicher Garantieleistung stellen. Wenn ich sehe, dass Heizungen 30 Jahre alt werden, ist das sowieso nur Makulatur.
Wenn Deine Heizung aufgrund einer Fehleinstellung heute kaputt geht, wird Bosch Dir diese nicht ersetzen. Egal ob mit offener Schnittstelle oder ohne. Entweder wendest Du Dich an den Heizungsmonteur, der das verbockt hat oder wenn Du es selbst warst, darfst Du es unter Lehrgeld verbuchen. So schaut die Realität aus. Alles andere ist ne Fake-Diskussion.

Außerdem was willste denn an einer Heizung groß zerstören. Die Sicherheitsschaltungen bei Übertemperatur funktionieren autark. Ok, Frost kann bei extrem schlechten Voraussetzungen ein Thema sein. Na und, das kann man ja durch ne Warnmeldung der Steuerung selbst abfangen.

Also über was reden wir hier denn?

Nachtrag: In jedem Bios hast Du auch Einstellungen, die garantiert den Rechner und Bauteile zerstören können. Frei zugänglich. Must nur draufklicken.

Nachtrag 2: Ich hab mir mal die Garantiebedingungen durchgelesen. Schon jetzt alles auf nachweisliche Material- und Fertigungsfehler eingeschränkt.

BTW: Gewährleistung geht nur gegen den Verkäufer. Das ist definitiv nicht der Hersteller.

Hallo,

erst einmal vielen Dank für die Antwort. Der Dialog funktioniert :slight_smile:

Ja, sehe ich auch so.

Worin besteht denn diese Sicherheitslücke wenn die Daten weitergegeben werden UND der Salt bekannt ist? Es ist doch gleichgültig ob diese Daten mit der Buderus-App (wie z.B. der Installateur für Fernwartung mit der EasyControlPro) oder über eine andere Implementierung des Kommunikationsprotokolls ge- oder missbraucht werden. Der Funktionsumfang ist exakt der selbe, denn das Protokoll gibt ja nicht mehr her als die App auch implementiert hat.

Egal ob mit oder ohne bekannten Salt, das Risiko ist gleich. Oder wo ist mein Denkfehler?

Das tut ein Salt ja per se, auch wenn es öffentlich ist. Daher speichert man es z.B. in einer Passwortdatenbank auch zusammen mit dem Passwort-Hash ab.

Leider kann ich daher die Argumentation immer noch nicht verstehen und bitte um Erhellung.

Folgende Argumentation könnte ich nachvollziehen:
Wir möchten nicht, dass unsere Cloud-Server-Infrastruktur mit Traffic von Drittanbieter-Apps belastet wird. Wir wollten diese Infrastruktur über die In-App-Käufe der EasyControlPro gegenfinanzieren, von Drittanbietern bekommen wir keinen finanziellen Ausgleich dafür.

Also ein Geschäftsmodell, gestützt auf ein geheimes Salt. Das wäre nachvollziehbar, ich würde es allerdings als ein schlecht designtes, kundenunfreundliches und risikoreiches Modell qualifizieren.

Aber angenommen dies träfe zusätzlich auch noch zu, dann hätte ich einen weiteren Vorschlag:

Lasst die HTTP-Kommunikation zwischen KM200 und App im lokalen Netzwerk unverschlüsselt, mit offen dokumentierter HTTP-Digest-Authentification (http://tools.ietf.org/html/rfc2617) laufen. Über XMPP ins Internet soll die Kommunikation nach wie vor verschlüsselt erfolgen, hier kann man die bestehende Implementierung beibehalten. So hat der lokale Anwender alle Freiheiten, ohne Kenntnisse über diesen Salt haben zu müssen.

Das wäre recht einfach zu implementieren, auf App- wie auf Gateway-Seite. Das Prinzip der Steuerung (HTTP-JSON) wird beibehalten, es ist - in Hinsicht auf die angesprochene Implementierung einer offenen Schnittstelle - auch problemlos im Funktions- und Parameterumfang erweiterbar.

Deal?

Gerne. Ich habe kein Interesse jemandem Schaden zuzufügen, im Gegenteil.

Nun zur zweiten Themengruppe.

Ich denke mir ab dieser Stelle einfach mal, dass mein obiger Vorschlag bereits umgesetzt wäre :smiley:

Ich fände hier eine System-Map an einer definierten REST-URL sinnvoll, in der alle Adressen dieser Datenpunkte maschinenlesbar aufgeführt sind. Prinzipiell ist es für den Heimautomateur immer von Vorteil Parameter überwachen und - im Falle von IP Symcon - auch aufzuzeichnen zu können, um z.B. unterschiedlichsten Effekte (Geräusche, morgens kaltes Wasser, …) autark auf den Grund gehen zu können.

Ich denke die örtliche Verfügbarkeit dieser kritischen Datenpunkte spielt eine wichtige Rolle im Sicherheitskonzept. Gehen wir von meinem oben skizzierten Vorschlag aus, so hätte ich hierzu folgende Idee:

[ul]
[li]Die Steuerung im lokalen Netzwerk erlaubtmindestens die Einstellungen, die jemand mit physischen Zugang zur Heizung oder zur Systemfernbedienung (wie z.B. einer RC300) vornehmen kann.
[/li][li]Die Steuerung über Internet via XMMP bleibt konservativ und wird nicht über den derzeitigen Umfang hinaus erweitert.
[/li][/ul]

Eine über das Internet erreichbare Heizung kann immer potenziell zur Sabotage missbraucht werden, falls irgendwo eine unbekannte Sicherheitslücke existiert. Vor diesem Aspekt ist die vom IP-Team grundsätzlich konservative Herangehensweise zu begrüßen. Allerdings sollte der Hausherr im eigenen Heimnetz schon alle Möglichkeiten erhalten.

Ein Modell der Sicherheitsabstufung im lokalen Netzwerk wäre z.B.

  • Lesen von Datenpunkten der Benutzerbedienebene ist ohne Authentifizierung möglich
  • Schreiben von Datenpunkten der Benutzerbedienebene ist nur mit Authentifizierung über Passwort 1 möglich
  • Lesen und Schreiben von Datenpunkten der Expertenbedienebene ist nur mit Authentifizierung über Passwort 2 möglich

Servus

  • ich hab zwar keine Buderus, verfolge die Diskussion aber mit Interesse.
    Meinem Wolf Kessel hab ich übrigens die ganze eigene „Intelligenz“ per Seitenschneider abgewöhnt und steuere 100% per IPS.

Grundsätzlich finde ich den Ansatz von Boui richtig.
Wenn ich schon an meiner Heizung rumprogramiere dann ist es extrem unbefriedigend von irgendeinem wohlmeinenden Obermacker bevormundet zu werden.
Natürlich ist das ein Risiko, aber wenn man nicht bereit ist es zu tragen dann sollte man auch besser die Finger davon lassen. Das ist ja schließlich kein Spielzeug.

Ich kann mir aber vorstellen das der Hersteller aufgrund von rechtlichen Gründen gezwungen ist potentiell unsichere Eingriffe zu unterbinden.
Ich kann mir weiters auch vorstellen das sich ein Hersteller vor übereifrigen Rechtsanwälten schützen will und sich von daher gar nicht in eine evtl. Grauzone begeben kann. Selbst wenn er es aus Kundenfreundlichkeit tun möchte.

Eine Lösung könnte die Verwendung von mehreren Freigabestufen sein:
1 Stufe: nur sichere Funktionen sind generell freigeschaltet
2 Stufe: Zugriff auf unsicher Funktionen nur per Freischaltkey und schriftlicher haftungsfreistellung des Herstellers.
Der Administrationsaufwand dafür dürfte ggfl. sogar kostenpflichtig sein.

Im übrigen ein großes Kompliment an das Buderus Team für die Teilnahme an dieser Diskussion.
Ich hätte nie gedacht das sich ein derart großer Hersteller dazu offiziell herablässt.

schöne grüße
bb

Herablassend ist das gerade nicht, sondern vorbildlich :wink:

Und als notorischer Bastler weiß ich auch, dass man ohne offene Schnittstelle bisweilen mehr Schaden durch „Reverse Engineering“ verursacht als wenn es da was halbwegs offenes gibt.

Das mit den Freigabeebenen klingt nach der richtigen Richtung. Man kann ja so eine Schnittstellenebene auch z.B. physikalisch per Plombe (oder etwas funktionsgleiches) freigebbar machen - so von Wegen „Warranty Void if Seal is Broken“ und dahinter ist dann halt der Jumper.

Für mich würde eine einfache read-only Möglichkeit ausreichen.
SNMP wäre super.

Read-only wäre ja jetzt zurück in die Vergangenheit. Wie kann man so etwas schreiben, wenn man Hausautomation betreibt? Sorry, da muss ich echt schlucken.