Monatsrückblick Oktober 2026 ist online!

[bloop]

Beitrag wurde mit KI erstellt und von Menschen korrigiert. Statistik und Zahlen sind aus KI Berichten.

Vor etwa einem halben Jahr hat @jey-cee sein iobroker-rag erstellt. Ich nutze den Ansatz seitdem regelmäßig in ioBroker sowie in VSCode und Claude zur Unterstützung bei der Adapter Entwicklung. In der Zwischenzeit habe ich das Projekt zu einer eigenen Implementierung weiterentwickelt.

ioBroker RAG

Zur Frage „Bringt RAG wirklich etwas?“

Ich „möchte“ zukünftig alles lokal verarbeiten: keine Frage, kein Skript und kein Log verlässt mein Netz. Dazu gehört, dass auch das ein Modell lokal läuft (mit Ollama auf einer RTX 4090). Lokale Modelle wissen über ioBroker deutlich weniger als die großen Cloud-Modelle, vor allem bei Skript-API, Rollen, io-package.json oder jsonConfig.
Genau diese Lücke soll das RAG schließen: Das Modell bekommt zu jeder Frage die passenden Stellen aus der offiziellen Doku und dem Quellcode.

• sources.json ist eine Allowlist. Nur die dort gelisteten öffentlichen Repos werden indexiert
• Indexierung läuft auf dem eigenen Rechner. Der Index wird nicht verteilt, jeder baut ihn selbst. Ergebnis sind derzeit rund 62.000 Dokument-Chunks.
• Bereitstellung als RAG-Server (REST + MCP).

Aufwand

	Wert
Index-Aufbau, Embeddings über Ollama auf RTX 4090	ca. 20 min
RAM / Disk für den Server	ca. 6Gb
Python	3.12
Antwortzeit Suche (mit Reranker)	ca. 3 s
Antwortzeit Suche (ohne Reranker)	ca. 0,2 s

Der Rebuild läuft bei mir wöchentlich per systemd-Timer nachts durch, damit die Doku aktuell bleibt.

Messung 1: Wie gut findet die Suche?

Gegen den laufenden Server habe ich zwei Fragesets ausgewertet. „Treffer@1“ heißt: Die erwartete Quelle steht auf Platz 1, „Treffer@5“: unter den ersten fünf. MRR ist die mittlere reziproke Rangposition (1,0 = immer Platz 1).

Set	Fragen	Treffer@1	Treffer@5	MRR	Median Antwortzeit
Doku-Fragen, mit Reranker	30	21	27	0,78	3,1 s
Doku-Fragen, ohne Reranker	30	14	27	0,63	0,2 s
Praxis-/Forumsfragen, mit Reranker	65	26	53	0,55	3,1 s

Erkenntnisse:

• Der Reranker verdoppelt fast die Top-1-Quote, kostet aber rund 3 Sekunden. Top-5 sortiert nur um.
• Bei typischen Forumsfragen gehen 12 von 65 komplett daneben.

Messung 2: Antworten mit und ohne RAG (lokales Modell)

Das ist der eigentlich interessante Teil. Setup:

• Antwortendes Modell: gemma4:26b-a4b-it-qat über Ollama auf der RTX 4090, einmal ohne und einmal mit den Top-5-Treffern aus dem RAG im Prompt.

• Bewertung: qwen3.8:27b als blinder Richter, bekam Frage, Antwort und die Doku-Referenz, ohne zu wissen, welche Variante er bewertet.
  Skala
  0 = falsch/erfunden,
  1 = teilweise richtig,
  2 = korrekt und vollständig.

• 12 Fragen, gemischt Deutsch/Englisch, aus Skript-Praxis und Adapter-Entwicklung.

#	Frage	ohne RAG	mit RAG
1	State in einem Skript mit ack setzen	1	2
2	subscribe auf State-Änderungen im JavaScript-Skript	0	2
3	Skript täglich zum Sonnenuntergang ausführen	1	2
4	Alle States eines Raums über $()-Selektor und enum	0	2
5	Eigenen Datenpunkt unter 0_userdata anlegen	0	2
6	Verzögertes setState und wieder abbrechen	0	2
7	Nachricht aus Skript an einen anderen Adapter senden	1	2
8	Bedeutung der Rolle level.temperature, welche Rollen gibt es	0	2
9	Pflichtfelder in io-package.json	0	2
10	Admin-Konfigseite mit jsonConfig definieren	0	2
11	Adapter im Latest-Repository veröffentlichen	0	2
12	Adapter mit VS Code debuggen	1	2
Zusammenfassung	ohne RAG	mit RAG
---	---	---
Punkte gesamt (max. 24)	4	24
korrekt (2)	0 von 12	12 von 12
falsch / erfunden (0)	8 von 12	0 von 12
Antwortzeit Median	21,2 s	9,5 s

Ohne RAG hat gemma4 keine einzige Frage vollständig richtig beantwortet, bei 8 von 12 hat es Funktionen oder Felder erfunden. Mit RAG waren alle 12 korrekt. Dass die Antworten mit RAG sogar schneller kamen, liegt daran, dass das Modell ohne Kontext deutlich länger „herumerzählt“.

Einschränkung, damit niemand das überinterpretiert: 12 Fragen sind keine große Studie, und die Fragen liegen alle im Bereich der offiziellen Doku. Bei den oben erwähnten Forumsthemen hilft das RAG weniger, weil die Quellen fehlen. Für meinen Alltag (Skripte, Adapter-Entwicklung, Objekt-Strukturen) ist der Unterschied aber genau so groß wie die Tabelle zeigt: Ohne RAG sind lokale Modelle für ioBroker-Fragen praktisch unbrauchbar, mit RAG sind sie auf Doku-Niveau.

Das anbinden an ein großes Cloud Modell bringt ebenfalls seine Vorteile.

Mich würde interessieren:

• Nutzt jemand noch ein lokales RAG für ioBroker?
• Gibt es Interesse an weiteren Quellen (z. B. Adapter-READMEs aus dem Latest-Repo)?
• Gibt es jemanden der mich bei dem Projekt unterstützen möchte?

[Bluefox]

@bloop Danke für die Vorstellung und vor allem für die Messungen. Dass gemma4 ohne Kontext bei 8 von 12 Fragen Funktionen erfindet, deckt sich mit dem, was ich bei kleinen lokalen Modellen sehe.

Hast du schon iobroker.ai-server + assistant + pi-agent ausprobiert? ai-server startet Ollama im Docker oder nutzt einen bestehenden Ollama-Server und stellt eine OpenAI-kompatible API bereit. Mit deiner 4090 wäre das Backend "External Ollama server" das richtige, NVIDIA im Docker-Container wird noch nicht unterstützt. Der assistant kann ein lokales LLM und pi-agent als Provider nutzen. Mich würde interessieren, ob dein RAG dort als zusätzliche Quelle über MCP Sinn ergibt und wie die Antworten damit im Vergleich aussehen.

Zu deiner Frage nach weiteren Quellen: Ja, die Adapter-READMEs halte ich für den wichtigsten nächsten Schritt. Die meisten Forumsfragen betreffen einen bestimmten Adapter und nicht die Skript-API oder io-package.json. Wahrscheinlich kommen deine 12 Fehlgriffe von 65 genau daher. Bei den Adaptern aus dem Latest-Repo sind die Lizenzen sehr unterschiedlich, das sollte in sources.json sauber mitlaufen. Interessant wären auch docs/ und die Changelogs, wo es sie gibt.

Zwei Fragen dazu:

• Wie lange braucht ein Rebuild, wenn du alle Adapter aus dem Latest-Repo aufnimmst? Ein inkrementelles Update (nur Repos mit neuem Commit) wäre dann vermutlich sinnvoller als ein wöchentlicher Komplett-Rebuild.
• Hast du einmal gemessen, wie groß der Unterschied bei einem großen Cloud-Modell mit und ohne RAG ist? Das wäre für viele hier interessanter, weil die meisten keine 4090 haben.

[bloop]

@Bluefox Die Punkte hab ich nun umgesetzt, Version 0.4.0: https://github.com/bloop-herbert-bot/ioBrokerRAG

• Adapter-Doku aus dem Latest-Repo: + Lizenz-Policy
• Inkrementeller Rebuild:

Adapter im Latest	indexiert	review (lokal)	nicht indexiert
839	819	24	20 (15 Lizenz, 5 bereits Kern)

Index und Build
(4 Kerne, 6 GB RAM, Embeddings über Ollama auf einer GPU)

	vorher (Kern)	nachher (Kern + Adapter)
Repositories	15	834
Chunks	61.903	67.660 (davon 28.494 aus Adapter-Repos)
Index auf Platte	551 MB	302 MB
Checkouts	2,3 GB	3,5 GB
Klonen + Chunken	–	29 min
Embedding	~20 min	27 min (42 Vektoren/s)
Vollbuild gesamt	–	59 min
RAM-Spitze	–	3,8 GB

Der Index wurde sogar kleiner, weil die englischen Adapter-READMEs vorher doppelt drin waren.

Die Tests folgen in den nächsten Tagen…

Wo bzw. in welchen Adapter würde deiner Meinung nach eine Anbindung Sinn machen?
Bisher hab ich die RAG hauptsächlich für die Adapterentwicklung mitlaufen lassen.
Die ganzen KI Anwendungen in ioBroker kommen für mich zu spät, hab ich auch ehrlicherweise nicht in aktiver Verwendung.

[Bluefox]

@bloop Das ging schnell, danke. 819 von 839 Adaptern bei einem Vollbuild unter einer Stunde ist gut. Mit dem inkrementellen Update ist das dann ja nur noch ein paar Minuten pro Nacht.

Eine Frage zu den Zahlen: Es sind mehr Chunks (67.660 statt 61.903), der Index ist aber von 551 auf 302 MB geschrumpft. Liegt das nur an den doppelten READMEs, oder hast du auch das Speicherformat bzw. das Embedding-Modell geändert?

Zur Anbindung: Am meisten bringt es meiner Meinung nach dort, wo Code entsteht, also im KI-Chat des javascript-Adapters. Dort hast du genau deinen Messfall: Skript-API, $()-Selektor, schedule, sendTo, Rollen. Gerade mit einem lokalen Modell erfindet der Chat dort sonst Funktionen. Wenn man vor der Anfrage die Top-5 aus deinem RAG in den Kontext gibt, wäre das wahrscheinlich die größte Verbesserung für die meisten Nutzer.

An zweiter Stelle kommt der KI-Assistent im Admin, bei Fragen wie "wie konfiguriere ich Adapter X" oder "was bedeutet dieser Logeintrag". Dafür sind jetzt die Adapter-READMEs wichtig.

Für die Adapterentwicklung bleibt dein bisheriger Weg (MCP in VS Code bzw. Claude) wohl der richtige. Dafür muss nichts in ioBroker passieren.

Was mir noch fehlt, um das einzuschätzen: Ist die REST-Schnittstelle stabil und dokumentiert (Request, Response, Felder wie Quelle und Lizenz)? Dann könnte man im javascript-Adapter eine optionale RAG-URL vorsehen. Wer keinen RAG-Server betreibt, merkt davon nichts.

Auf die Tests mit Cloud-Modell bin ich gespannt.

[wendy2702]

Hallo,

Vorab: hier schreibt ein Mensch, keine KI und es wurde auch nichts mit KI kontrolliert oder ähnliches. Wer Rechtschreibfehler findet darf sie behalten.

Es ist schön das z.B. dieses Projekt vorgestellt wurde aber habt ihr mal versucht das als Außenstehender zu verstehen?

Ich behaupte von mir selber nicht gerade völlig verblödet zu sein was den Einsatz von Software/HW usw. Angeht aber das was hier beschrieben wird und auch der Link zum Projekt in GitHub wird wahrscheinlich jeden Iobroker Newbie hoffnungslos überfordern und wahrscheinlich auch abschrecken.

Früher wurden hier Anleitungen von Menschen für Menschen geschrieben bzw. Veröffentlicht heute nur noch von KI für KI habe ich den Eindruck.

Auch die mit Sicherheit gut gemeinte Anleitung in GitHub stellt wahrscheinlich etliche User vor ein Problem:

Nur mal als Beispiel: welches Repository soll kopiert werden und auch die anderen Anweisungen muss man sich zusätzlich wahrscheinlich altmodisch ergoogeln.

Dieser Thread ist nur ein Beispiel von mittlerweile vielen und ich muss sagen das ich Aufgrund der Entwicklung und steigender Unverständlichkeit / Komplexität der Beiträge schon User kenne die ihr Iobroker Projekt eingestellt haben.

Jetzt darf gerne auf mich eingeprügelt und downgevotet werden aber vielleicht stehe ich ja auch nicht ganz alleine da bei den nicht mehr ganz soviel verbliebenen Iobroker Installationen.

Somit allen Iobrokern ein schönes Wochenende

[bloop]

@wendy2702
Herzlichen Dank für deine ehrliche Einschätzung!
Der Thread ist in erster Linie zur Vorstellung des Projekts und der bereits existierenden Möglichkeiten gedacht. Meine Initiative war nicht eine bereits vollständige Anleitung für Einsteiger zu liefern. Dem entsprechend wird das Repo auch nicht geführt.
Ich probiere und experimentiere aktuell noch sehr viel.

Sollte sich ein wahrer Nutzen herausstellen, wird dieses selbstverständlich auch so aufbereitet das jedermann sehr einfach damit arbeiten kann.

Ich werde mich zukünftig mehr bemühen, wieder Beiträge verständlicher zu formulieren.

@bluefox
Einiges an Credits für das Benchmark verbrannt…

• 9 Cloud-Modelle über GitHub Copilot, plus gemma4 26B lokal zum Vergleich:
  • Anthropic: Opus / Sonnet / Haiku 5.5
  • OpenAI: GPT-6.1-sol / -terra / GPT-6-luna
  • Google: Gemini 4 Argon / 3.8 Flash
  • xAI: Grok 4.6
• 105 Fragen: 60 Alltagsfragen, 45 Detailfragen.
• Drei Modi: A ohne Kontext, C Top-5 mit Reranker. Dazu Top-1 ohne Reranker als Zwischenstufe.
• Drei blinde Richter, einer pro Anbieter. Sie bewerten jede Antwort mit 0, 1 oder 2 Punkten.

Ergebnis (richtig, ohne RAG → mit RAG)

Modell	Alltag	Detail
Opus 5.5	82 → 84 %	67 → 89 %
GPT-6.1-sol	81 → 82 %	54 → 87 %
Grok 4.6	61 → 79 %	40 → 87 %
Gemini 4 Argon	72 → 82 %	48 → 86 %
Sonnet 5.5	76 → 84 %	47 → 82 %
Gemini 3.8 Flash	68 → 78 %	34 → 82 %
Haiku 5.5	59 → 69 %	33 → 74 %
GPT-6-luna	63 → 72 %	31 → 74 %
gemma4 26B lokal	14 → 56 %	3 → 67 %

• Detailfragen: RAG hilft jedem Modell deutlich, auch den Top-Modellen (+21 bis +63 Punkte, alle signifikant).
• Alltagsfragen: Die stärksten Modelle kennen die Antworten schon, die kleineren gewinnen trotzdem 7–18 Punkte.
• Mit RAG sind die Anbieter praktisch gleichauf (79–82 %). Ein Mittelklasse-Modell mit RAG schlägt ein Top-Modell ohne RAG.
• Erfundene APIs halbieren sich, von rund 25 % auf rund 10 % der Antworten.

[Bluefox]

@wendy2702 Dieses Post ist noch nicht für dich. Ich glaube nicht, dass du eine RTX5080 irgendwo liegen hast, die du für die Entwicklung anwenden willst. Einfach ignorieren.

[OliverIO]

@bloop

Wo findet man die Alltags und Detailfragen?
Sind das die unter eval?

[wendy2702]

@bloop danke für deine Rückmeldung. Ich finde das eigentlich sehr interessant und deshalb kam mein „Einwand“. Solltest du mal Zeit und Lust haben daraus eine Anleitung zu bauen bin ich bestimmt nicht der einzige den das interessiert.

@bluefox : was hat dich zu deiner Aussage/Annahme veranlasst? Ach eigentlich interessiert mich das und deine Antwort ehrlich gesagt nicht, sondern geht mir am Allerwertesten vorbei.

[bloop]

@OliverIO
Habe die Fragen sowie den Weg und das Ergebnis soeben in den /eval geladen. Ich muss jedoch dazu sagen das zum Zeitpunkt des RAG noch auf der Version 0.3.0 lief und ich somit beim Benchmark noch keine Adapter Dokus im RAG waren.
Ein weiterer Lauf würde mich aktuell wieder weitere 7std, sowie jede Menge Credits kosten. Eventuell nächsten Monat wieder.
Erstmal schauen wo die Entwicklung hin geht und ob sich ein echter Mehrwert für ioBroker und/oder die Adapterentwicklung aufzeigen lässt.

@wendy2702
Ich unterstütze sehr gerne!
Eventuell ergibt sich ja bald die Möglichkeit ein funktionierendes ioBroker RAG für die gesamte Community zur Verfügung zu stellen. Es handelt sich ja lediglich um eine Sammlung öffentlicher Dokumente die für KI Modelle aufgearbeitet wurden. 😜
Übrigens lässt sich sowas nicht nur mit ioBroker umsetzen sondern mit jeder eigenen Datensammlung. Wie zb. Obsidian, ein eigenes Wiki, Notion, uvm.

[OliverIO]

@bloop sagte:

Übrigens lässt sich sowas nicht nur mit ioBroker umsetzen sondern mit jeder eigenen Datensammlung. Wie zb. Obsidian, ein eigenes Wiki, Notion, uvm.

Genau das machen gerade (oder haben bereits) viele Unternehmen um ihr ganzes Wissen für ihre KI und ihre Mitarbeiter besser nutzbar zu machen.

[Thomas Braun]

Was hat denn die Ruhrkohle AG mit dem ioBroker zu tun?

[OliverIO]

@Thomas-Braun

Es ist das gemeint
https://de.wikipedia.org/wiki/Retrieval-Augmented_Generation

[bloop]

@Bluefox sagte:

Was mir noch fehlt, um das einzuschätzen: Ist die REST-Schnittstelle stabil und dokumentiert (Request, Response, Felder wie Quelle und Lizenz)? Dann könnte man im javascript-Adapter eine optionale RAG-URL vorsehen. Wer keinen RAG-Server betreibt, merkt davon nichts.

REST-Schnittstelle: läuft stabil (live getestet: /health, /stats, /query, Fehlerfälle, MCP). Doku war bisher zu dünn – jetzt gibt es eine feste API v1 mit allen Request-/Response-Feldern inkl. Quelle, Lizenz und Lizenzstatus (allow/review): https://github.com/bloop-herbert-bot/ioBrokerRAG/blob/main/docs/api.md