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

[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! 👍

[liv-in-sky]

@Jey-Cee was genau soll ich ihm sagen :-)

[bloop]

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

@Jey-Cee was genau soll ich ihm sagen :-)

"Dann setzte das auch genau so um"
eventuell noch
"Halte dich Zukünftig daran und schreib es dir in die Memory"

[OliverIO]

@bloop

Mit Labels könnt ihr dann auch arbeiten.
Da könnte man den aktuellen bearbeitungsstatus abbilden
In Bearbeitung
Review
Etc

Unabhängig ob es ein Mensch oder ein bot macht

[liv-in-sky]

@Jey-Cee @bloop

ich müßte mal was fragen - ich habe vor lauter rag programmieren noch nicht viel mit openclaw gemacht. ich habe 4 agenten - einer hat gemini, einer hat claude, der main hat kimi2.5 und noch einen heartbeat, der sich darum mit ollama kümmern soll. es gibt einen bug und mein main agent sagt auch, er könne nicht mit den anderen agenten reden - ich habe also das problem, wenn ich main sage, er den mit claude-agenten sagen, er solle sich um ein issue kümmern, er das momentan (wegen bug) nicht kann.

wie macht ihr das - habt ihr nur einen agenten der alles macht ?

UND

hier mal eine kommunikation mit main wegen issue von skeletor:

kannst du ein issue aufmachen?

You
18:54
😈

Gute Frage! 🤔

Theoretisch: Ja — ich hab Zugriff auf GitHub CLI (gh) und den Bot-Token.

Aber: Bevor ich ein Issue öffne, sollte ich fragen:

Welches Repo? (Skeletor-ai/ioBroker.system-health oder ein anderes?)
Was ist das Issue? (Titel, Beschreibung, Labels?)
Ist das wichtig genug? (Oder kann das warten?)
Sicherheit: Ich würd vorher fragen, bevor ich extern was schreibe (wie bei allen public Actions).

Was für ein Issue möchtest du öffnen? 📝

Botti
18:55
U
fidest du welche, die noch nicht bearbeitet werden

You
18:54
😈

3 offene ready Issues (unassigned):

#115 — [Bug] Redis Monitoring nicht auf Dashboard ersichtlich
#114 — [Bug] Log überwachung nicht korrekt
#90 — Adapter reports its own states as unused/orphaned
Die sind alle noch nicht bearbeitet und haben das ready Label! 🎯

Welches interessiert dich? 🤔

also mein bot weiß nicht, das er was bearbeiten soll ?

[bloop]

@liv-in-sky ich verwende im Agenten Claude. Damit funktioniert es recht gut. Es gibt meines Wissens die Möglichkeit die Agenten miteinander zu verbinden. Ebenfalls wurden bereits Tools und Erweiterungen erstellt mit denen es möglich ist abhängig von Komplexität des Prompt das richtige Modell zu wählen. Dieses kann auch lokal laufen.
Versuch es mal mit NadirClaw
https://github.com/doramirdor/NadirClaw

[Jey Cee]

@liv-in-sky ich hab lediglich claude als agent. Der Versuch mehrere mit einer Claude instanz zu nutzen um lokale LLMs einzubinden hat nicht funktioniert. Auch wenn er selber Agents spawnt mit Claude kommt es ziemlich oft vor das die sich aufhängen.

Klar weis er nicht welches issue er bearbeiten soll. Du hast ihn ja auch gefragt ob er ein neues Aufmachen soll und dann schwenkst du um ob er welche findet die noch nicht bearbeitet werden. An dem Punkt hättest du ihm sagen müssen schau nach issues die nicht bearbeitet wurden und leg los.

[liv-in-sky]

@Jey-Cee

habe ihm gesgt er solle #114 bearbeiten

✅ Subagent kimi finished

Perfect! Die Änderung ist sauber und fokussiert. Lasse mich das Repo mit einer kurzen Zusammenfassung aktualisieren:

Abschließende Zusammenfassung

Bearbeitetes Issue: GitHub Issue #114 - "Log überwachung nicht korrekt"
Repository: Skeletor-ai/ioBroker.system-health
Assignee: ✅ liv-in-clawbot

Das Problem

Log-Überwachung war implementiert, aber die Datenpunkte in system-health.0.logs.* blieben null. Der Grund lag in der robusten Fehlerbehandlung des LogMonitor.fetchLogs(), die nicht mit allen möglichen Antwortformaten der Host-API umging.

Meine Lösung

Datei: /lib/health-checks/log-monitor.js - Methode fetchLogs()

Verbesserte Fehlerbehandlung:

1. ✅ Direkte Array-Antworten von getLog werden korrekt verarbeitet
2. ✅ Wrapped-Antworten (wo die Array-Daten in response.logs stecken) werden erkannt und extrahiert
3. ✅ Bessere Fehlermeldungen für Debugging
4. ✅ Graceful Fallback bei unerwarteten Datentypen

Testing

• ✅ Alle 178 Tests bestehen
• ✅ LogMonitor Tests alle erfolgreich
• ✅ Keine Breaking Changes

PR

• Titel: "Fix #114: Improve log monitor robustness"
• Nummer: #122
• Status: Erstellt & gepusht zu main

Die Änderung ist minimal, fokussiert und behebt das Kernproblem, ohne bestehende Funktionalität zu beeinträchtigen.

hat er gemacht, was er machen sollte ?