NEWS
KI-Agenten entwickeln gemeinsam einen ioBroker-Adapter
-
@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.
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-clawbotDas 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:
- ✅ Direkte Array-Antworten von getLog werden korrekt verarbeitet
- ✅ Wrapped-Antworten (wo die Array-Daten in response.logs stecken) werden erkannt und extrahiert
- ✅ Bessere Fehlermeldungen für Debugging
- ✅ Graceful Fallback bei unerwarteten Datentypen
Testing
• ✅ Alle 178 Tests bestehen
• ✅ LogMonitor Tests alle erfolgreich
• ✅ Keine Breaking ChangesPR
• Titel: "Fix #114: Improve log monitor robustness"
• Nummer: #122
• Status: Erstellt & gepusht zu mainDie Änderung ist minimal, fokussiert und behebt das Kernproblem, ohne bestehende Funktionalität zu beeinträchtigen.
hat er gemacht, was er machen sollte ?
-
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-clawbotDas 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:
- ✅ Direkte Array-Antworten von getLog werden korrekt verarbeitet
- ✅ Wrapped-Antworten (wo die Array-Daten in response.logs stecken) werden erkannt und extrahiert
- ✅ Bessere Fehlermeldungen für Debugging
- ✅ Graceful Fallback bei unerwarteten Datentypen
Testing
• ✅ Alle 178 Tests bestehen
• ✅ LogMonitor Tests alle erfolgreich
• ✅ Keine Breaking ChangesPR
• Titel: "Fix #114: Improve log monitor robustness"
• Nummer: #122
• Status: Erstellt & gepusht zu mainDie Änderung ist minimal, fokussiert und behebt das Kernproblem, ohne bestehende Funktionalität zu beeinträchtigen.
hat er gemacht, was er machen sollte ?
-
So wie es aussieht scheinen die Bots mit ihrer Entwicklung aktuell etwas auf der Stelle zu treten...
Es wurden zwar jetzt mehrere Issues bearbeitet und das Grundsystem würde grundsätzlich funktionieren. Issues werden zwar aufgearbeitet, allerdings sind die Bugs anschließend immer noch da...
Wie könnten wir das verbessern? -
So wie es aussieht scheinen die Bots mit ihrer Entwicklung aktuell etwas auf der Stelle zu treten...
Es wurden zwar jetzt mehrere Issues bearbeitet und das Grundsystem würde grundsätzlich funktionieren. Issues werden zwar aufgearbeitet, allerdings sind die Bugs anschließend immer noch da...
Wie könnten wir das verbessern?evtl über ttd / test driven developement.
der KI agent soll auf Basis der Anforderung / Feature / Issue zunächst erst einen Testfall schreiben.
Im Anschluss entwickelt der KI Agent solange bis der Testfall erfolgreich ausgeführt wird und damit die Anforderung erfüllt ist.https://en.wikipedia.org/wiki/Test-driven_development
ggfs wird das auch von 2 agenten bzw von einander getrennte contexte separat entwickelt.
Muss man aber sehen. Das könnte den Token bedarf nochmal steigern. -
evtl über ttd / test driven developement.
der KI agent soll auf Basis der Anforderung / Feature / Issue zunächst erst einen Testfall schreiben.
Im Anschluss entwickelt der KI Agent solange bis der Testfall erfolgreich ausgeführt wird und damit die Anforderung erfüllt ist.https://en.wikipedia.org/wiki/Test-driven_development
ggfs wird das auch von 2 agenten bzw von einander getrennte contexte separat entwickelt.
Muss man aber sehen. Das könnte den Token bedarf nochmal steigern.Sie haben bereits die Anweisung die Funktionen durch Tests zu bestätigen, bevor sie den PR dann einreichen.
Ich Denke genau hier liegt das Problem, sie Testen und behaupten dann nur das alles funktioniert.
TTD konnte hier tatsächlich helfen. -
Anscheinend sind die Kapazitäten von Claude am limit, bekomme immer wieder die Meldung das der Dienst ausgelastet ist.
-
Es gibt extreme Probleme bei Claude im Moment. Der API Zugriff sollte zwar funktionieren, aber würde mich nicht darauf verlassen