Illustratives Beitragsbild zum ioBroker-Adapter mit KI

Wie ich mit KI einen ioBroker-Adapter gebaut habe – und warum das trotzdem Arbeit war

von

Eigentlich wollte ich nur meinen Bosch-Durchlauferhitzer etwas besser in mein Smart Home einbinden.

Also wirklich nur kurz.

Der Durchlauferhitzer lässt sich über die Bosch-HomeCom-App steuern und es gibt auch eine Integration für Home Assistant. Das funktionierte grundsätzlich sogar ziemlich gut. Ich konnte den Modus einstellen, Temperaturen setzen und jede Menge Statusinformationen auslesen. Nur lief mein Smart Home eben nicht hauptsächlich über Home Assistant, sondern über ioBroker.

Und wenn man fast alles in ioBroker macht, dann fühlt sich jede zusätzliche Brücke irgendwann wie ein kleiner Umweg an. Besonders dann, wenn genau dieser Umweg gelegentlich zickt. Beim direkten Einstellen der Temperatur über den HASS-Adapter gab es bei mir immer wieder Probleme. Nicht dramatisch, aber genug, um den inneren Basteltrieb zu wecken.

Also stand irgendwann die Frage im Raum: Wenn es für Home Assistant bereits eine funktionierende Integration gibt, müsste man daraus doch auch einen ioBroker-Adapter bauen können, oder?

Spoiler: Ja, kann man.

Aber nicht mit einem einzigen magischen Prompt. Und auch nicht ohne Frust, Fehlermeldungen, GitHub-Eigenheiten, Auth-Flow-Gefrickel und diesen einen Moment, in dem man merkt, dass KI zwar Code schreiben kann, aber nicht automatisch versteht, was man wirklich braucht.

Schnellnavigation

Warum überhaupt ein eigener Adapter?

Der konkrete Auslöser war mein Bosch Tronic Excellence Durchlauferhitzer (bezahlter Link). Das Gerät ist HomeCom-fähig, lässt sich also über die Bosch-App steuern und auslesen. Für sich genommen ist das schon praktisch. Aber wie so oft im Smart Home beginnt der eigentliche Spaß erst dann, wenn man die Daten nicht nur in einer Hersteller-App sieht, sondern in die eigene Automatisierung bekommt.

In meinem Fall heißt diese Zentrale meistens ioBroker. Dort laufen meine Datenpunkte zusammen, dort entstehen Automationen, dort habe ich die Kontrolle. Home Assistant nutze ich zwar ebenfalls an manchen Stellen, aber eher ergänzend. Mein Hauptsystem bleibt ioBroker.

Das Problem: Für Bosch HomeCom fand ich zunächst keinen passenden ioBroker-Adapter.

Und damit begann wieder dieses typische Smart-Home-Muster: Man sucht nur kurz nach einer Lösung, findet keine, schaut nach Workarounds, entdeckt eine andere Integration, testet ein bisschen herum und plötzlich steckt man mitten in einem eigenen Projekt.

Wer meine Geschichte über das per Alexa gesteuerte Badezimmer gelesen hat, kennt diese Dynamik vermutlich schon: Fast jedes Smart-Home-Projekt beginnt mit „ach, eben schnell“. Danach wird es meistens interessant.

Die Suche nach einer passenden Grundlage

Der erste Schritt war ziemlich unspektakulär. Die App heißt Bosch HomeCom, also suchte ich nach:

Bosch HomeCom ioBroker

Das Ergebnis: nichts Passendes.

Also der nächste naheliegende Versuch:

Bosch HomeCom Home Assistant

Und da wurde es sofort interessanter. Das erste brauchbare Ergebnis war direkt eine passende Home-Assistant-Integration auf GitHub:

serbanb11/bosch-homecom-hass

Diese Integration habe ich ausprobiert. Sie funktionierte bei mir grundsätzlich gut. Innerhalb von Home Assistant konnte ich den Betriebsmodus einstellen, die Temperatur setzen und diverse Statuswerte auslesen.

Damit war klar: Die grundsätzliche Kommunikation mit Bosch HomeCom ist möglich. Es gibt eine funktionierende Logik für Login, Session und API-Kommunikation. Nur eben nicht in der Umgebung, in der ich sie eigentlich haben wollte.

Mein ursprüngliches Ziel war dabei gar nicht besonders groß. Ich wollte nicht sofort jede mögliche Geräteklasse unterstützen und auch nicht den perfekten Universaladapter bauen. Mir hätte zunächst gereicht, die Temperatur meines Durchlauferhitzers direkt über ioBroker regeln zu können.

Mehr sollte es erst einmal gar nicht sein.

Natürlich blieb es nicht dabei.

Warum ich KI bewusst eingesetzt habe

ioBroker-Adapter basieren auf Node.js beziehungsweise TypeScript. Und das ist nicht gerade mein Lieblingsspielplatz.

Ich programmiere zwar, aber mein Alltag liegt eher in anderen Bereichen. PHP, SQL, klassische Webanwendungen, Datenbanklogik, interne Tools, WordPress, Automatisierungskram. Node.js und TypeScript sind für mich nicht völlig fremd, aber eben auch nicht das Gebiet, in dem ich mal eben entspannt einen ioBroker-Adapter aus dem Ärmel schüttle.

Dazu kam noch ein zweites Problem: Ich hatte keine klare Vorstellung davon, wie genau Bosch HomeCom Anmeldung, Session und API-Kommunikation technisch löst. Bei manchen Diensten kann man relativ einfach Benutzername und Passwort senden, bekommt ein Token zurück und arbeitet dann damit weiter.

Bei Bosch HomeCom läuft das aber über SingleKey. Das ist kein simples „schick mal Login-Daten hin und fang die Antwort ab“.

Also dachte ich mir: Warum nicht KI fragen?

Nicht, weil ich nicht programmieren kann. Sondern weil KI genau bei solchen Aufgaben sehr nützlich sein kann: fremde Codebasen analysieren, Zusammenhänge erkennen, Strukturen übertragen, Fehlermeldungen einordnen und aus einer vorhandenen Integration einen Umsetzungsplan ableiten.

Mein erster Versuch lief über Codex von OpenAI. Das Ergebnis war allerdings eher ernüchternd. Selbst ein Basic-Adapter ließ sich am Ende nicht sauber starten. Vielleicht lag es an meinem Prompting, vielleicht am Werkzeug, vielleicht an beidem. Jedenfalls war das Ergebnis für mich nicht brauchbar.

Mein Bruder hatte mir schon länger empfohlen, für Programmierarbeiten auch mal Claude.ai auszuprobieren. Also gab ich Claude eine Chance.

Und tatsächlich: Nach einigen Tests, Fehlversuchen und mehreren Adapterversionen wurde das Projekt Schritt für Schritt greifbarer.

Der erste Prompt an Claude

Ich wollte nicht direkt mit „bau mir einen Adapter“ starten. Mir ging es zuerst darum, überhaupt zu verstehen, was machbar ist und welche Bausteine gebraucht werden.

Mein erster Prompt an Claude sah deshalb so aus:

Ich möchte einen ioBroker-Adapter für Bosch HomeCom entwickeln.

Bitte analysiere zuerst, wie ein moderner ioBroker-Adapter aufgebaut sein sollte und wie die Referenz
https://github.com/serbanb11/bosch-homecom-hass
Login, Session und API-Kommunikation löst.

Erstelle danach einen konkreten Umsetzungsplan mit Dateien, Klassen, Datenflüssen und offenen Risiken.
Noch keinen Code schreiben.

Das war bewusst als Analyseauftrag formuliert.

Claude lieferte dann direkt eine ziemlich lange Antwort mit Dateien, Klassen, Zuständigkeiten, Datenflüssen und teilweise auch schon Code-Ideen. Um ehrlich zu sein: Ich war erst einmal etwas erschlagen.

Ein moderner ioBroker-Adapter besteht eben nicht nur aus einer Datei, die irgendwo eine API abfragt. Da hängen Struktur, Konfiguration, Authentifizierung, Datenpunkte, States, Build-Prozess, Lifecycle und viele kleine Konventionen dran.

Nachdem ich das Grundprinzip aber verstanden hatte, ging es weiter. Ich erklärte Claude genauer, was ich wollte, und ließ eine erste Alpha-Version erstellen.

Die lief natürlich nicht.

Und damit begann der eigentliche Entwicklungsprozess.

Von der Alpha zum funktionierenden Adapter

Die erste Alpha war noch nicht lauffähig. Das war aber auch nicht überraschend. Ab da begann das klassische Error-Ping-Pong:

Starten. Fehlermeldung lesen. Zurück in die KI geben. Erklärung bekommen. Code anpassen. Wieder starten. Neue Fehlermeldung. Wieder zurück.

Zwischendurch haben wir den Login per cURL getestet, weil schnell klar wurde, dass Bosch HomeCom über SingleKey nicht mit einem simplen Login-Request erledigt ist. Ein wichtiger Schritt war dann die Analyse einer Python-Datei aus der Home-Assistant-Integration. Dort steckte ein Teil der Logik, die wir für den Adapter verstehen und übertragen mussten.

Als dieses Problem zumindest grundsätzlich gelöst war, kam direkt das nächste:

No tokens available. Please complete the authorization flow in the adapter config.
State "bosch-homecom.0.info.connection" has no existing object, this might lead to an error in future versions

Nachdem die benötigten Daten eingetragen waren, tauchte wieder ein anderer Klassiker auf:

startInstance bosch-homecom.0: cannot find start file!

Ab Version 12 war der Adapter dann grundsätzlich lauffähig. Allerdings noch ohne echte Datenausgabe und ohne Steuerungsmöglichkeiten. Stattdessen gab es immer wieder Auth-Probleme wie:

[Auth] Token refresh failed: {"error":"invalid_grant"}

Dazu kamen die üblichen KI-Halluzinationen. Einmal wurde plötzlich wieder auf einen klassischen Benutzername-/Passwort-Login umgebaut, obwohl genau das bei Bosch HomeCom in diesem Fall nicht funktioniert. Solche Momente zeigen ziemlich gut, warum KI-Code niemals einfach blind übernommen werden sollte.

Version 18 war dann der Punkt, an dem es ernst wurde.

Der Adapter konnte erfolgreich eine Verbindung herstellen, Daten abrufen und schließlich im Grunde das leisten, was auch die Home-Assistant-Integration konnte. Der Übergang von „ich probiere das mal aus“ zu „das ist ja wirklich ein funktionierender ioBroker-Adapter“ war dabei erstaunlich fließend.

Und genau das macht KI-Coding für mich interessant. Es ist nicht einfach nur ein Generator für Code. Es ist eher ein sehr schneller Sparringspartner, der aber klare Führung braucht. Man muss testen, nachfragen, korrigieren, verstehen und manchmal sehr deutlich sagen: Nein, wir machen das nicht wieder über Benutzername und Passwort, wir bleiben beim SingleKey-Flow.

Wenn man das akzeptiert, kann so ein Projekt plötzlich machbar werden, obwohl man allein vermutlich deutlich früher gesagt hätte: Ach, lass mal.

Was der Adapter aktuell kann

Der Adapter kann aktuell alles, was auch die Home-Assistant-Integration kann.

Er unterstützt den SingleKey/Auth-Flow, erkennt Geräte, liest Funktionen aus, gibt Statuswerte aus und kann Geräte steuern. Alles wird als Datenpunkt in ioBroker angelegt und kann darüber weiterverwendet werden.

Für mich persönlich war vor allem die Temperatursteuerung wichtig. Die funktioniert inzwischen direkt aus ioBroker heraus. Und weil der Umweg über den HASS-Adapter entfällt, reagiert das Ganze auch deutlich schneller.

Interessant sind aber nicht nur Solltemperaturen und Betriebsmodi. Gerade bei einem Durchlauferhitzer gibt es einige Werte, mit denen man im Smart Home wirklich etwas anfangen kann.

Ein Beispiel ist waterFlow. Damit lässt sich erkennen, ob gerade Wasser fließt. In Kombination mit weiterer Hardware könnte man damit beispielsweise eine Automation bauen, die ein Magnetventil steuert und automatisch Badewasser einlaufen lässt. Spätestens hier wird es natürlich sehr schnell sehr nerdig und man sollte bei Wasser, Ventilen und Automationen wissen, was man tut. Aber genau solche Datenpunkte machen den Reiz aus.

Ebenfalls spannend ist inletTemperature. Dieser Wert zeigt, wie warm oder kalt das Wasser vor dem Erhitzen ist. Da mein Durchlauferhitzer solarthermie-fähig ist, könnte man damit ziemlich gut auswerten, wie viel die Solarthermieanlage in dieser Kombination tatsächlich bringt.

Und dann gibt es noch waterTotalConsumption. Damit lässt sich sehen, wie viel Wasser bisher durch das Gerät gelaufen ist.

Das sind genau die Werte, die aus einer simplen App-Steuerung plötzlich echte Smart-Home-Daten machen.

Natürlich läuft ioBroker irgendwo. Bei mir lief lange ein HP ProDesk 600 G3 SFF (bezahlter Link) mit Proxmox und ioBroker. Solche kleinen Business-Rechner sind für mich heute deutlich interessanter als ein Raspberry Pi, wenn es um eine dauerhafte Smart-Home-Zentrale geht. Mehr Leistung, mehr Reserven, normale SSDs, oft günstig gebraucht zu bekommen und einfach robuster für mehrere Dienste gleichzeitig.

Und wer im Smart Home schalten, messen oder lokal automatisieren will, landet ohnehin schnell bei Geräten wie Shelly (bezahlter Link). Gerade im Zusammenspiel mit ioBroker sind solche lokalen Bausteine für mich deutlich reizvoller als reine Cloud-Spielzeuge.

KI-Code ist kein Freifahrtschein

Ich schreibe bewusst offen, dass dieser Adapter mit KI-Unterstützung entstanden ist.

Nicht als Entschuldigung. Und auch nicht als Marketing-Gag.

Der Adapter wurde mit voller Absicht mithilfe von KI gebaut, weil KI bei diesem Projekt ein sinnvolles Werkzeug war. Sie konnte die vorhandene Home-Assistant-Integration analysieren, Zusammenhänge schneller erkennen, Fehler erklären und aus einer Python-basierten Integration Schritt für Schritt eine ioBroker-Struktur ableiten.

Für mich ist das vergleichbar mit einer Maschine, die Kettenglieder sauber zurechtbiegt. Natürlich kann man sich auch mit einem großen Hammer hinstellen und jedes Glied einzeln bearbeiten. Aber wenn es ein besseres Werkzeug gibt, warum sollte man es nicht nutzen?

Das heißt aber nicht, dass KI-Code automatisch gut ist.

KI-Code ist nicht perfekt. Er kann falsch sein, Sicherheitsprobleme enthalten, falsche Annahmen treffen oder plötzlich eine bereits gelöste Sache wieder kaputtmachen. In meinem Fall war das zum Beispiel der Rückfall auf einen klassischen Login, obwohl SingleKey gebraucht wurde.

Deshalb gilt: KI-Code sollte niemals blind verwendet werden.

Aber man muss auch nicht jede Zeile verteufeln, nur weil eine KI daran beteiligt war. Am Ende zählt, ob der Code nachvollziehbar ist, getestet wird, offen liegt und verbessert werden kann.

Ich bin grundsätzlich ein KI-Verfechter. Nicht im Sinne von „KI macht alles richtig“, sondern im Sinne von: Es gibt keinen guten Grund, ein hilfreiches Werkzeug nicht zu benutzen, nur weil es neu ist oder manchen Leuten Unbehagen bereitet.

Bei Navigationsgeräten ist es ähnlich. Ein Navi ist praktisch. Problematisch wird es erst, wenn man ihm blind vertraut, jedes Verkehrsschild ignoriert und irgendwann ohne Navi nicht mehr von A nach B kommt. Genau so ist es mit KI.

Zu diesem Spannungsfeld passen auch meine Beiträge über die panische Angst vor KI und darüber, wie schnell man sich von ChatGPT das Hirn wegbrutzeln lassen kann. KI kann helfen. KI kann aber auch bequem machen, wenn man aufhört mitzudenken.

Gerade beim Programmieren ist der Unterschied wichtig:

Code schreiben lassen ist eine Sache.

Code verstehen ist eine andere.

Und wenn eine KI den Code schreibt, wird das Verstehen nicht weniger wichtig, sondern wichtiger.

Wer sich grundsätzlich für meine Haltung zu diesem Thema interessiert, findet im Beitrag Künstliche Intelligenz meinen größeren Überblick dazu: nicht als Heilsversprechen, aber auch nicht als Weltuntergangsszenario.

Warum ich das Projekt teile

Ursprünglich war der Adapter nur für mich gedacht.

Ich hatte ein Gerät, ein konkretes Problem und wollte eine direkte Lösung in ioBroker. Inzwischen ist das Projekt aber zu groß geworden, um es einfach nur auf meiner Platte liegen zu lassen.

Der Adapter liegt deshalb öffentlich auf GitHub:

GrayTheZebra/ioBroker.bosch-homecom

Aktuell würde ich den Adapter als Beta bezeichnen. Bei mir läuft er mit meinem Bosch-Durchlauferhitzer, aber genau da liegt auch die Einschränkung: Ich habe nur dieses eine HomeCom-Gerät zum Testen.

Das ist für ein Projekt dieser Art etwas dünn.

Deshalb wäre es spannend, wenn weitere Leute mit ioBroker und Bosch-HomeCom-Geräten den Adapter ausprobieren. Nicht als aggressive „bitte installiert das alle sofort“-Nummer, sondern ganz entspannt: Wenn du so ein Gerät hast und ioBroker nutzt, freue ich mich über Rückmeldung.

Interessant wäre vor allem:

  • Welche Werte zeigt die Bosch-HomeCom-App an, die im Adapter noch fehlen?
  • Lassen sich alle Funktionen steuern?
  • Werden weitere Geräte erkannt?
  • Fehlen Geräte komplett?
  • Gibt es Datenpunkte, die falsch benannt oder unklar sind?
  • Welche Kombinationen aus Gerät, Firmware und HomeCom-Funktion laufen problemlos?

Langfristig wäre eine Kompatibilitätsliste sinnvoll. Und vielleicht wird daraus irgendwann sogar ein offizieller ioBroker-Adapter. Das wäre ein schöner Gedanke, aber ob es wirklich dazu kommt, wird sich zeigen.

Mir geht es zunächst darum, das Projekt sauber zu teilen und Feedback zu bekommen.

Fazit: KI ersetzt nicht das Verstehen

Dieses Projekt hat für mich sehr gut gezeigt, wo KI beim Programmieren heute schon extrem nützlich sein kann.

Ohne KI hätte ich vermutlich nicht mal eben einen ioBroker-Adapter für Bosch HomeCom gebaut. Nicht, weil es unmöglich wäre, sondern weil die Einstiegshürde ziemlich hoch ist: fremde API, SingleKey-Login, Home-Assistant-Integration als Vorlage, ioBroker-Adapterstruktur, Node.js, TypeScript, Build-Prozess, GitHub und am Ende noch reale Tests am Gerät.

Mit KI wurde daraus kein Selbstläufer, aber ein machbares Projekt.

Und genau das ist für mich der eigentliche Punkt.

KI-Coding ermöglicht Projekte, von denen man allein aufgrund der Komplexität sonst vielleicht die Finger lassen würde. Es hilft, fremde Systeme zu verstehen, erste Strukturen aufzubauen, Fehler zu analysieren und eigene Wünsche umzusetzen.

Warum sollte man sich seine Wünsche nicht mit Hilfe von KI erfüllen, wenn es dieses Werkzeug bereits gibt?

Man sollte nur nicht vergessen, dass Werkzeug nicht Verantwortung ersetzt.

Der Adapter ist nicht fertig geworden, weil eine KI einmal magisch Code ausgespuckt hat. Er ist entstanden, weil die KI Code erzeugt hat, ich ihn getestet habe, Fehler zurückgespielt habe, Zusammenhänge verstehen musste, falsche Abzweigungen korrigiert habe und irgendwann aus einer spontanen Idee ein funktionierendes Projekt wurde.

Oder anders gesagt:

Einen ioBroker Adapter mit KI erstellen kann funktionieren.

Aber Arbeit bleibt es trotzdem.

Schreibe einen Kommentar