Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Jey Cee]

@liv-in-sky es gibt ein RAG für iobroker das ich gebaut habe. Dafür braucht er das Embedding model.
Neun das ist nirgendwo im Detail beschrieben.

[liv-in-sky]

@Jey-Cee alles klar - botti (so nen ich openclaw)hat das auch so erklärt - soweit läuft mal alles

was ich noch nicht checke:

der system -health adapter ist ein spezieller adapter, der aber nicht den bot frägt - das sind ja daten von iobroker - daher check ich gerade nicht, wie openclaw und iobroker nun zusammenarbeitet. was kann ich jetzt von openclaw aus machen?

• mein bot fragt nur den status der adapter ab
• ich persönlich muss issues eingeben für die weiterentwicklung - oder mach ich das über botti
• wie kann ich einen anderen adapter entwickeln lassen oder vorschlagen ? (oder ist das zukunft ?)

[liv-in-sky]

@Jey-Cee habe jetzt das bekommen:

system-health.0
2026-02-22 11:46:15.855	warn	Detected potential crash: meteoalarm.0

system-health.0
2026-02-22 11:46:03.228	warn	Detected potential crash: netatmo-crawler.0

system-health.0
2026-02-22 11:45:07.491	warn	Detected potential crash: ical.0

system-health.0
2026-02-22 11:45:06.951	warn	Detected potential crash: ical.0

system-health.0
2026-02-22 11:43:07.583	warn	Detected potential crash: ical.2

system-health.0
2026-02-22 11:43:07.574	warn	Detected potential crash: ical.2

system-health.0
2026-02-22 11:43:07.074	warn	Detected potential crash: ical.2

system-health.0
2026-02-22 11:40:12.005	warn	Detected potential crash: ical.1

system-health.0
2026-02-22 11:40:11.497	warn	Detected potential crash: ical.1

system-health.0
2026-02-22 11:40:07.532	warn	Detected potential crash: ical.0

system-health.0
2026-02-22 11:40:07.523	warn	Detected potential crash: ical.0

system-health.0
2026-02-22 11:40:07.022	warn	Detected potential crash: ical.0

system-health.0
2026-02-22 11:37:00.511	warn	Detected potential crash: broadlink2.0

system-health.0
2026-02-22 11:37:00.005	warn	Detected potential crash: broadlink2.0

system-health.0
2026-02-22 11:37:00.005	warn	Detected potential crash: broadlink2.0

system-health.0
2026-02-22 11:37:00.004	warn	Detected potential crash: broadlink2.0

system-health.0
2026-02-22 11:35:07.455	warn	Detected potential crash: ical.0

system-health.0
2026-02-22 11:35:06.946	warn	Detected potential crash: ical.0

system-health.0
2026-02-22 11:35:03.257	warn	Detected potential crash: openweathermap.0

system-health.0
2026-02-22 11:35:02.750	warn	Detected potential crash: openweathermap.0

system-health.0
2026-02-22 11:32:00.512	warn	Detected potential crash: wled.0

system-health.0
2026-02-22 11:32:00.512	warn	Detected potential crash: mqtt.0

system-health.0
2026-02-22 11:32:00.004	warn	Detected potential crash: wled.0

system-health.0
2026-02-22 11:32:00.003	warn	Detected potential crash: mqtt.0

system-health.0
2026-02-22 11:30:41.508	warn	Detected potential crash: netatmo-crawler.0

system-health.0
2026-02-22 11:30:07.563	warn	Detected potential crash: ical.0

system-health.0
2026-02-22 11:30:07.553	warn	Detected potential crash: ical.0

system-health.0
2026-02-22 11:30:07.053	warn	Detected potential crash: ical.0

system-health.0
2026-02-22 11:30:00.613	warn	Detected potential crash: fullybrowser.0

system-health.0
2026-02-22 11:30:00.507	warn	Detected potential crash: fullybrowser.0

system-health.0
2026-02-22 11:30:00.097	warn	Detected potential crash: fullybrowser.0

system-health.0
2026-02-22 11:25:07.477	warn	Detected potential crash: ical.0

system-health.0
2026-02-22 11:25:06.967	warn	Detected potential crash: ical.0

system-health.0
2026-02-22 11:23:08.351	warn	Detected potential crash: ical.1

system-health.0
2026-02-22 11:23:08.338	warn	Detected potential crash: ical.1

system-health.0
2026-02-22 11:23:07.838	warn	Detected potential crash: ical.1

system-health.0
2026-02-22 11:20:11.341	warn	Detected potential crash: ical.2

system-health.0
2026-02-22 11:20:10.831	warn	Detected potential crash: ical.2

system-health.0
2026-02-22 11:20:07.577	warn	Detected potential crash: ical.0

system-health.0
2026-02-22 11:20:07.565	warn	Detected potential crash: ical.0

system-health.0
2026-02-22 11:20:07.064	warn	Detected potential crash: ical.0

wen frage ich nun wie : was das bedeutet - über openclaw oder issue ?

[Jey Cee]

@liv-in-sky sagte in KI-Agenten entwickeln gemeinsam einen ioBroker-Adapter:

ich persönlich muss issues eingeben für die weiterentwicklung - oder mach ich das über botti

Beides geht. Aus meiner Erfahrung heraus werden die Issues meistens besser wenn sie der Bot erstellt. Nur die Adapter, iobroker und Admin Version muss man selbst ergänzen.

Edit: Du sagst ihm was du haben willst, Verbesserung oder Fehlerbehebung und beschreibt das möglichst Ausführlich.

@liv-in-sky sagte in KI-Agenten entwickeln gemeinsam einen ioBroker-Adapter:

wie kann ich einen anderen adapter entwickeln lassen oder vorschlagen ? (oder ist das zukunft ?)

Das kannst du ihm auch direkt sagen. Hier gehts darum speziell die Zusammenarbeit zu Testen und verbessern. Aber auch Praktische Erfahrung zu sammeln wie man die Bots instruieren muss um ein gutes und Konsistentes Ergebnis zu bekommen. So gesehen Bauen wir gerade ein Grundgerüst für Zukünftige Projekte.

[Jey Cee]

@bloop hast du deinem Bot für den PR: https://github.com/Skeletor-ai/ioBroker.system-health/pull/47
eine Anweisung gegeben oder hat er das selber entschieden?

Wenn du ihm eine Anweisung gegeben hast, kannst du sie mit uns Teilen?

[liv-in-sky]

@Jey-Cee nee - hab ich ganz übersehen einzurichten - habe nur das was in beschreibung für AGENT.md eingegeben

MOD-EDIT: "Link" entschärft

[Jey Cee]

@homoran warum hast du den Link entschärfen müssen?

[Homoran]

@Jey-Cee sagte in KI-Agenten entwickeln gemeinsam einen ioBroker-Adapter:

@homoran warum hast du den Link entschärfen müssen?

weil die Browser diesen filenamen irrtümlich als Link darstellen!

Deswegen auch

@liv-in-sky sagte in KI-Agenten entwickeln gemeinsam einen ioBroker-Adapter:

MOD-EDIT: "Link" entschärft

mit Anführungszeichen

[bloop]

@Jey-Cee
Ja Anweisung kam von mir:

Hab im Chat nur eingegeben:
„ Wir haben nun einige Dinge in der laufweise des bots verbessert und angepasst. Sollte dies nicht auch in die Agents_contributors.md aufgenommen werden?“

Hier die Antwort:
Absolut richtig! Die Verbesserungen sollten auch für die anderen Bots verfügbar sein. Lass mich schauen, was aktuell in AGENTS_CONTRIBUTORS.md steht:
Sehr guter Punkt! Ich sehe in AGENTS_CONTRIBUTORS.md:

• ❌ Memory Search fehlt komplett
• ⚠️ Review-Feedback steht in Schritt 9, sollte aber PRIORITÄT #1 sein (vor neuen Issues!)

Aber: Es steht auch "Do NOT modify this file (AGENTS_CONTRIBUTORS.md)" in den Regeln.

Ich könnte trotzdem einen PR machen mit der Begründung, dass es eine wichtige Prozess-Verbesserung ist, die alle Bots nutzen sollten. Was meinst du?

Vorgeschlagene Änderungen:

1. Workflow umstellen:

   • Schritt 1: Review-Feedback checken (ZUERST!)
   • Schritt 2: Memory Search (vor dem Coden)
   • Schritt 3: Dann erst neue Issues suchen

2. Anti-Patterns Sektion hinzufügen (wie in meiner MEMORY.md)

Soll ich einen PR erstellen, der AGENTS_CONTRIBUTORS.md entsprechend erweitert? Das wäre eine Meta-Änderung, die der Maintainer explizit reviewen sollte.

[bloop]

@jey-cee Ich muss sagen noch blicke ich bei dem Adapter noch nicht ganz durch.
Wie werden Verwaiste, Veraltete und Duplikat States definiert?
Bei mir wären das über 30k...

Habe aber keinen blassen Schimmer wie sich das eindämmen ließe.
Es werden ja auch Datenpunkte von Adaptern angezeigt die man zb. nie benötigt. Auch wenn diese dann gelöscht werden würden, nach dem nächsten Adapter start wären sie wieder da. Macht also wenig Sinn.
Ebenfalls lässt sich nicht erkennen welches Gerät bzw. Entität, der JavaSkript Adapter oder die VIS nicht einen Datenpunkt benötigen.

Wie wäre es wenn wir die Anzeige umgekehrt machen? Nur die Datenpunkte welche auch benötigt werden sollen auch angezeigt werden.

Ansonsten verstehe ich die Sinnhaftigkeit des Adapters noch nicht ganz :D

[Jey Cee]

@bloop ich hab schon angefangen issues zu erstellen um das zu filtern. Gerade das Prüfen auf identische Values ist Überflüssig. Insgesamt werden viele Objektbäume geprüft die gar keinen Sinn ergeben, wie userdata oder alias.

@bloop sagte in KI-Agenten entwickeln gemeinsam einen ioBroker-Adapter:

Wie werden Verwaiste, Veraltete und Duplikat States definiert?

Veraltet bemisst sich daran wie lange nichts in den State geschrieben wurde, kann mit einem Parameter festlegen.

Verweist sind States die nirgendwo eingebunden sind.
Das ist allerdings Problematisch weil bei den meisten sicher 90%+ nirgendwo verwendet werden. Mein Ursprünglicher Gedanke war das der Adapter IDs in Skripten und Visualisierungen sucht und schaut ob die Überhaupt noch existieren. Die KI war da irgendwie andere Ansicht und hat deswegen diesen Issue entsprechend anders formuliert, dabei herausgekommen ist dieses Chaos.

Duplikate sind Objekte die zu x% identisch sind, was mit einem Parameter 0-1 festgelegt werden kann.

@bloop sagte in KI-Agenten entwickeln gemeinsam einen ioBroker-Adapter:

Wie wäre es wenn wir die Anzeige umgekehrt machen? Nur die Datenpunkte welche auch benötigt werden sollen auch angezeigt werden.

Scheint mir wenig sinnvoll, wir wollen ja keine Liste von existenten Datenpunkten, eigentlich wollen wir rauskriegen, welche Datenpunkte im System überhaupt keinen Sinn haben.

@bloop sagte in KI-Agenten entwickeln gemeinsam einen ioBroker-Adapter:

Es werden ja auch Datenpunkte von Adaptern angezeigt die man zb. nie benötigt. Auch wenn diese dann gelöscht werden würden, nach dem nächsten Adapter start wären sie wieder da.

Ja, diese vielen Datenpunkte, die eigentlich keinen sinn haben bei vielen Adaptern und die man sich auch sparen könnte werden jetzt Sichtbarer. Schwieriges Thema eigentlich müsste man irgendwie einen Weg finden, diese Datenpunkte soweit es geht überhaupt zu vermeiden.
Ich hatte damals den Ansatz einfach statische Informationen ins Objekt von dem jeweiligen Adapter oder von dem einzelnen Device im Adapter reinzuschreiben, sodass die nicht einfach so als Objekt herum liegen, aber trotzdem darauf zugegriffen werden kann. Ein Problem war, die Benutzer sind damit nicht klar gekommen und ein anderes Problem ist, programmatisch war es auch schwierig teilweise dann auf diese Information zuzugreifen. In JavaScript muss man extra eine Option dafür einschalten und in vis ist es nur mit Umwegen möglich gewesen diese Informationen dann anzuzeigen.

[Jey Cee]

Ich hab hier mal einen Link mit der man eine Woche Claude Code Kostenlos testen kann:
https://claude.ai/referral/H6Y8AGvXrA

[OliverIO]

@Jey-Cee

Aktuell kann man auch bei NVIDIA
das kimi2.5 kostenlos nutzen

Auf YouTube gibt es diverse Videos wie man das einrichtet

[bloop]

@jey-cee
Ich habe meinen Bot nun so angewiesen, dass dieser jede Stunde auf eine neue Version prüft.
Diese wird dann auf einer Testinstanz von iobroker installiert.
Hier wird bei laufender Instanz dann das Dashboard und die Datenpunkte analysiert und auf eventuelle mit dem Github Repo abgeglichene Bugs bzw. Funktionen überprüft. Daraus werden dann, falls notwendig, Issues ins Repo gepostet.
Die Issues sind jedoch absichtlich nicht mit Ready gekennzeichnet und müssen vorab vom Maintainer (oder manuell über mich) freigegeben werden.
Ich bin gespannt wie sich das hier weiter entwickelt.

[Jey Cee]

@bloop das ist ne Super Idee.
Heute war einiges Los, ich hab mir die Aktuellste Version noch gar nicht angeschaut.

[bloop]

@Jey-Cee Überprüft den Maintainer nur alle Issues welche auch mit ready gekennzeichnet wurden oder alle? eventuell musst du hier die Logik anpassen.
Erst soll überprüft werden ob das Issue überhaupt sinn macht und erst dann freigegeben (ready) werden.
Bis wir ein aussagekräftiges finetuning des Agenten haben wird es etwas dauern.

[Jey Cee]

@bloop hab meinen Bot mal gefragt was bisher die Kriterien waren für das ready flag. Gab keine. Das ist jetzt angepasst und der Maintainer Bot muss das vergeben.
Was es vorher schon gab war die Anweisung vor beginn der Arbeit an einem Issue zu prüfen ob er Sinn macht und gegebenen falls Rückfrage zu stellen.

[Jey Cee]

@liv-in-sky Dein Bot ignoriert, wenn schon ein anderer Bot die Issues bearbeitet. Kannst du ihm mal bitte die Anweisung geben, dass er nur Issues aufnimmt, die wo noch von keinem anderen Bot in Bearbeitung sind?

[bloop]

Ich hab meinem Bot nun aufgetragen er soll zusätzlich ein Repo mit den Erkenntnissen aus der Entwicklung eines iobroker Adapters anlegen. So das diese auch von dritten für andere Projekte verwendet werden kann.

• Best Practices
• Anti‑Patterns
• Learnings aus echten PRs
• Testing‑Strategien
• Admin‑UI‑Hinweisen
• Backend‑Integrationsmustern
• Debugging‑Tricks

https://github.com/bloop-herbert-bot/ioBroker-development-bot-guide

Eventuell hilft das beim anlernen deines Bots. Das Repo Pflegt der Bot wiederum selbst.

[liv-in-sky]

@Jey-Cee das hat er auf die frage "was machst du wenn in anderer bot schon ein issue bearbeitet" geantwortet:

Gute Frage! 🤔

Wenn ein anderer Bot schon an einem Issue arbeitet:

Laut dem ioBroker Workflow (aus MEMORY.md):

1. CHECK DEIN STATUS

gh pr list --repo Skeletor-ai/ioBroker.system-health --state open --author @me

• WENN du offene PRs mit Review-Kommentaren hast → Bearbeite die ZUERST
• WENN du offene PRs ohne Feedback hast → Warte auf Review, claim NICHTS Neues
• WENN du keine PRs hast → Gehe zu Schritt 2
  Das bedeutet:

✅ Erst meine offenen PRs checken
✅ Nur wenn ich KEINE PR hab → neue Issue suchen
❌ NICHT mehrere Issues gleichzeitig bearbeiten (Anti-Pattern!)
Falls ein anderer Bot schon arbeitet:

Wenn Issue bereits assigned → ich skip und nehm die nächste
Wenn Issue unassigned aber in Bearbeitung → ich claim sie nicht (respektiere die Reihenfolge)
Anti-Pattern: Mehrere Issues gleichzeitig = Chaos! 😤

Das ist die Regel #1 um Konflikte zu vermeiden! 👍