Hallo zusammen,
ich bin schon lange im ioBroker-Umfeld unterwegs, im Forum bisher aber eher stiller Nutzer — meist nur dann hier, wenn ich selbst Hilfe oder Infos gebraucht habe. Dieser Thread ist für mich der Anlass, das zu ändern und mich vorzustellen, denn ich bin genau den Weg gegangen, über den hier diskutiert wird.
Zu mir: Ich arbeite seit 1989 in der IT — als Entwickler, später Administrator, heute als DevOps-Engineer und Teamlead. Privat betreibe ich ioBroker seit Jahren produktiv auf Proxmox, mit rund 50 Adaptern im Einsatz, quer durch alle Bereiche: Energie (evcc, OpenDTU, SMA, Zendure, Smartmeter), Fahrzeuge (Tronity, Easee, VW Connect), Zigbee (deCONZ, zigbee2mqtt), dazu SQL-Logging in eine MariaDB, MQTT, Telegram und die komplette VIS-Landschaft. KI-Unterstützung ist für mich dabei nichts Neues: Seit längerem überarbeite, verbessere und baue ich die JavaScript-Skripte meiner Umgebung mit KI-Hilfe — teils Refactoring bestehender Skripte, teils komplette Neuentwicklungen. Als Contributor habe ich außerdem einen gemergten PR im ioBroker.tronity-Adapter.
Jetzt der Grund meines Posts — mein erster eigener Adapter: ioBroker.sunenergyxt500 (https://github.com/Creekhail/ioBroker.sunenergyxt500) für die SunEnergyXT 500 / 500 PRO Speichersysteme. Der Adapter läuft komplett über die lokale HTTP-API des Geräts — kein Cloud-Account nötig. Er bildet alle Datenpunkte ab (SoC, Leistungswerte, Energiezähler, per-Pack-SoC, Firmware-Infos) und bietet zwei umschaltbare Regelmodi für die Eigenverbrauchsoptimierung: einen adapterseitigen Regler, der mit jedem ioBroker-Messwert als Quelle arbeitet (inkl. Watchdog/Failsafe), oder die geräteeigene Selbstregelung mit unterstützten Zählern. Default ist bewusst ein reiner Monitoring-Modus, der nichts schreibt.
Und jetzt die volle Transparenz — inklusive der Timeline, die ihr im Repo ohnehin nachvollziehen könnt: Das Gerät habe ich am 17. Juni erhalten, zunächst per eigenen JavaScript-Skripten angebunden, und am 28. Juni stand Release 0.1.0 — ein TypeScript-Adapter auf Basis des offiziellen create-adapter-Templates, mit Tests, CI und zweisprachiger Doku. Der Code wurde zum größten Teil von KI geschrieben. Meine Toolchain dabei: JetBrains WebStorm als IDE und Claude Code mit dem aktuellen Modell Claude Fable 5. In dieser Zeit wäre das für mich alleine schlicht nicht machbar gewesen — und ich sage das mit über 35 Jahren Entwicklungserfahrung im Rücken.
Damit das nicht als "KI-Klick-und-fertig" missverstanden wird — meine Vorgehensweise:
Plan vor Code: API-Referenz des Geräts durchgearbeitet, Datenpunkt-Struktur und Architektur vorab ausformuliert — so wie es @Jey-Cee hier im Thread beschrieben hat.
KI führen, nicht laufen lassen: Kleine, klar abgegrenzte Arbeitsschritte statt "bau mir mal einen Adapter".
Jede Änderung reviewen: Ich verstehe den Code, den ich committe. Die KI schreibt schneller als ich — die Verantwortung bleibt bei mir.
Am realen Gerät getestet: Der Adapter läuft produktiv an meinem eigenen Speicher. Was ich nicht testen konnte (PV-Eingänge — mein Gerät läuft rein AC-gekoppelt), steht ehrlich in den Limitations der README.
Zur berechtigten Frage von @Meister-Mopper ("Wer pflegt den Adapter in Zukunft?"): Ich. Der Adapter steuert meinen eigenen Speicher — ich habe selbst das größte Interesse daran, ihn zu pflegen. Und ehrlich gesagt senkt die KI-Unterstützung die Maintenance-Hürde eher, als dass sie sie erhöht.
Den formalen Weg gehe ich übrigens parallel: Die Aufnahme als offizieller Entwickler hier im Forum ist beantragt — aktuell warte ich noch auf die Freischaltung. Über Code-Reviews, Kritik und Hinweise zu den Community-Standards (Adapter-Checker, Review-Prozess, Repo-Aufnahme) freue ich mich ausdrücklich — ich will es richtig machen, nicht nur schnell. Und Feedback von anderen SunEnergyXT-Besitzern (besonders mit angeschlossenen PV-Modulen) wäre Gold wert.
Viele Grüße
Creekhail aka Marcus
