wichtiges UPDATE für controller 7.2.2 im stable

[skvarel]

@MatthiasUlrich .. das mit den Regeln habe ich sehr gut mit einer 'copilot-instructions.md' in den Griff bekommen. Nutze ich bei allen Adaptern, mit spezifischen Anweisungen.

EDIT:
Ich habe mittlerweile 5 Adapter von Copilot mit Claude Sonnet 4.6 schreiben lasse. Teilweise bereits im Stable, der Rest im Latest.

[MatthiasUlrich]

@skvarel

Keine Frage, dass das auch mit anderen Agents geht. Ich hab ja auch schon Kleinkram mit anderen Agents gemacht. Aber das arbeiten mit Cursor war wirklich anders.

Ich finde es ist auf jeden Fall mal einen kostenlosen test wert.

[skvarel]

@MatthiasUlrich .. ich habe mich die letzten Tage mit Cursor Desktop beschäftig und werde nachher den PRO Plan abschließen. Copilot ist als Hobbie nicht mehr bezahlbar.

Es hat mich etwas Zeit und Nerven gekostet, bis Cursor Desktop so aussah, das ich von VS Code weggehen kann! Das schwierigste war, die Scripte unten links anklickbar zu bekommen und die Navigation auf der ganz linken Seite.

Meine aktuelle Cursor Ansicht:

[crunchip]

@skvarel sagte:

bis Cursor Desktop so aussah, das ich von VS Code weggehen kann

Wurde das nicht automatisch übernommen?

[skvarel]

@crunchip sagte:

Wurde das nicht automatisch übernommen?

Bei mir leider nicht

[OliverIO]

@skvarel

Sieht doch auch aus wie vscode.
Cursor / antigravity sind alles vscode Abkömmlinge.

[skvarel]

@OliverIO .. jetzt sieht es exakt so aus, wie mein vs code, ja. Nach dem ersten Start von Cursor Destop sah es sehr ungewohnt aus. Die Scripte wurden (unten links) nicht angezeigt und die linke Navigation gab es so auch nicht.

Ich bin da sehr festgefahren, was Optiken bei Programmen angeht. Ich nutze vs code jetzt rund 10 Jahren. Jetzt habe ich Cursor Desktop auf genau die identische Ansicht (Farben, Layout/Anordnungen) bekommen. Jetzt steht dem Wechsel nihcts mehr im Weg.

Nur noch die 'Rules' anlegen. Weil Cursor die 'copilot-instructions.md' von Haus aus ignoriert, muss ich eigene Cursor Rules anlegen und ihn direkt auf die 'copilot-instructions.md' hinweisen.

---
description: ioBroker.tidy adapter conventions (see copilot-instructions)
alwaysApply: true
---

# ioBroker.tidy

Follow project conventions in `.github/copilot-instructions.md` for adapter work (code style, ESLint, tests, admin UI, CI/CD, releases).

......

[MatthiasUlrich]

@skvarel ich habe mich vorher auch ne weile damit beschäftigt. Dann habe ich es erst mal mit einem bestehendem Adapter probiert der für mein Gerät nicht mehr funktionierte. Den hat Cursor (in einem Fork) sofort lauffähig gemacht. Nicht perfekt im code aber er lief zuverlässig für mich. Dann hab ich mich an den anker-solix Adapter gemacht und was soll ich sagen ein paar Tage später warte ich nun auf das Review zur Aufnahme ins Latest Repository. Ich finde es fast etwas erschreckend wie krass gut das funktioniert.

[skvarel]

@MatthiasUlrich .. ich werde in Cursor eh nur Claude Sonnet (oder Opus) nutzen. Damit habe ich die besten Erfahrungen gemacht.

[Creekhail]

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:

1. 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.
2. KI führen, nicht laufen lassen: Kleine, klar abgegrenzte Arbeitsschritte statt "bau mir mal einen Adapter".
3. Jede Änderung reviewen: Ich verstehe den Code, den ich committe. Die KI schreibt schneller als ich — die Verantwortung bleibt bei mir.
4. 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