Pfingsten habe ich an zwei Adapter-Projekten herumgeschraubt, die ich Euch hier vorstellen möchte — beide sind noch nicht so weit, daß ich sie als richtige ioBroker-Adapter anmelden könnte, aber sie tun jeweils schon das, wofür ich sie konkret gebaut habe. Und ich hätte gerne Mitstreiter, Mit-Meckerer und Mit-Tester.

TL;DR — die beiden Projekte

• iobroker.mcp — eine Brücke zwischen ioBroker und LLM-Clients über das Model Context Protocol. Zur Zeit als externer Python-Server (stdio, neben dem LLM-Client installiert), spricht via simple-api mit dem ioBroker. Ziel-Architektur: nativ als ioBroker-Adapter laufend, über HTTP(S) Streamable Transport direkt an LLM-Clients angebunden, keine simple-api-Abhängigkeit mehr. Repo: https://github.com/McCavity/iobroker-mcp
• iobroker.blink — ein echter Blink-Adapter auf Basis von blinkpy (Python). Zur Zeit nur ein Hotfix-CLI, das aus einem JS-Adapter-Skript via exec() aufgerufen wird (Arm/Disarm via Sunset/Sunrise-Trigger). Ziel-Architektur: vollständiger Adapter mit Long-Running-Bridge, allen Datenpunkten der Networks/Cameras (Arm-Status, Motion, Battery, Snapshot etc.). Auslöser für das Projekt: das alte Setup via HAM-Adapter war seit Wochen kaputt, weil Amazon Blink im Oktober/November 2025 die Auth-Architektur auf OAuth umgestellt hat — das HAM-genutzte Plugin ist seit April 2025 archiviert.

Beide Projekte sind heute über denselben Diagnose-Faden verbunden, deshalb stelle ich sie zusammen vor.

Hinweis zur KI-Beteiligung (gemäß dem angepinnten Forum-Hinweis): Beide Projekte sind in enger Zusammenarbeit mit einem LLM-basierten Coding-Agent (Claude Code) entstanden — sowohl Architektur-Entscheidungen als auch Code-Anteil. Mein Anteil sind Anforderungen, Domain-Wissen, Live-Tests im eigenen Setup und Review. In den Repos ist die KI-Beteiligung durch Co-Authored-By-Marker in den Commits sowie Hinweise in den READMEs dokumentiert. Auch diesen Forum-Beitrag haben wir gemeinsam in mehreren Iterationen geschrieben.

Wie es dazu kam — die Blink-Saga in Kurz

Mein Skript für die Außen-Kameras (Arm 30 Min vor Sonnenuntergang, Disarm 30 Min nach Sonnenaufgang, klassisch über astro-Trigger) ist irgendwann gestorben — Schreibversuche auf den HAM-Datapoint kamen mit ack=false zurück, im HAM-Log stand nur HAPStatus -70402 SERVICE_COMMUNICATION_FAILURE. Ich hatte Debug-Logs im JS-Adapter aktiviert, mit -70402 etwas anzufangen versucht, dann gemerkt, daß auch das HAM-Plugin selbst noch ein eigenes Debug-Level hat, das ich nicht aktiviert hatte — und an dem Punkt ist mir die Lust ausgegangen. Plan-B waren feste Zeitpläne in der Blink-App, suboptimal aber tat irgendwas. Mit Repo-Versionen, Plugin-Source und dem eigentlichen Fehler habe ich mich gar nicht mehr beschäftigt.

Pfingst-Sonntag habe ich den Fall an einen LLM-Helfer weitergereicht (Claude Code), den ich vorher mit einem MCP-Server für ioBroker bewaffnet hatte — und das war der Wendepunkt. Damit war der Diagnose-Loop in zwanzig Minuten am Killer-Finding. Nichts davon hätte ich nicht prinzipiell auch selbst tun können. Aber zwischen "kann ich prinzipiell" und "mache ich tatsächlich" liegt halt manchmal das Leben.

iobroker.mcp — Werkzeug und Stand

Damit der Rest nachvollziehbar ist, ein kurzer Schwenk zum Begriff:

Model Context Protocol (MCP) ist eine 2024 von Anthropic vorgestellte Spezifikation, mit der LLM-Clients (Claude Code, Codex, OpenCode etc.) strukturiert auf externe Datenquellen und Werkzeuge zugreifen können. Ein MCP-Server ist ein kleines Programm, das eine Sammlung von Tools bereitstellt — Funktionen mit Name, Beschreibung, Parameter-Schema und Rückgabe. Das LLM sieht diese Tools, kann sie strukturiert aufrufen, bekommt das Ergebnis und arbeitet damit weiter.

Konkret an einem ioBroker-Beispiel: ich sage in einem normalen Chat zu Claude "schalte die Blink-Außen-Kameras scharf". Claude kennt iobroker.mcp und sieht darin das Tool write_state(id, value). Sie ruft auf:

write_state("ham.0.Blink-Blink-Außen.Blink-Außen-Arm.On", true)

Der MCP-Server übersetzt das aktuell in einen HTTP-Call gegen den simple-api-Adapter (GET /set/<id>?value=true). Die simple-api sitzt im ioBroker, setzt den Datenpunkt im Objektbaum auf true mit ack=false, der jeweilige Adapter reagiert wie sonst auch — fertig.

Aktueller Stand:

• FastMCP, Python (~400 Zeilen), MIT-Lizenz, public Repo
• Transport: stdio, d.h. zur Zeit als Co-Installation neben dem LLM-Client (Mac, Linux-Workstation o.ä.)
• Kommunikation mit ioBroker: über simple-api (Voraussetzung: simple-api-Adapter installiert und Instanz aktiv, im LAN ohne Auth)
• Acht Tools:

Ziel-Architektur:

• Nativ als ioBroker-Adapter laufend (also in der Adapter-Sprache des Ökosystems, also TypeScript/JavaScript — hier fehlt mir noch einiges an Erfahrung, deshalb Bitte um Mit-Hilfe weiter unten).
• HTTP(S) Streamable Transport statt stdio, damit der LLM-Client direkt mit dem Adapter sprechen kann (von überall, nicht nur lokal auf dem MCP-Server-Host).
• Keine simple-api-Abhängigkeit mehr — Adapter spricht direkt mit dem ioBroker-Objektbaum und der States-Datenbank.
• Authentifizierung optional (Token, später ggf. Pro-User), damit das Ding auch außerhalb LAN nutzbar bleibt.

iobroker.blink — Anlaß, Workaround und Stand

Anlaß: HAM-Adapter mit homebridge-blink-for-home als Brücke zu Blink — funktionierte über Jahre, fiel im Herbst 2025 aus. Mit MCP-Server-Unterstützung dann diagnostiziert: das Plugin schweigt sich über sein eigenes Scheitern aus (in log.js sind log.info/log.debug als No-Op definiert), und sobald man logging: "debug" aktiviert, kommt der eigentliche Fehler ans Tageslicht: HTTP 426 An app update is required. Amazon hat eine Mindest-App-Version eingeführt; das Plugin meldet sich noch mit appVersion: 6.18.0 (2210101952) aus Oktober 2022. Plus: das Original-Repo ist seit 24. April 2025 archiviert, der aktive Fork hat das Problem ebenfalls (Issue #2 im Flomentum-Solutions/homebridge-blink-for-home-new), Home Assistant trifft die gleiche Wand (Issue #154477 im HA-Core).

Der Grund ist nicht "Version-String veraltet". Amazon hat den Blink-Login komplett auf OAuth umgestellt (Access-Token + Refresh-Token statt klassischer Session-Cookies). Ein Plugin-Update mit gepatchtem Version-String würde nichts retten — die ganze Auth-Architektur muß umgeschrieben werden. Im Python-Ökosystem gibt's allerdings schon eine Lösung: blinkpy von fronzbot hat den OAuth-Flow im PR #1115 bereits implementiert und wird aktiv gepflegt.

Aktueller Stand (Workaround):

• HAM-Adapter raus (iobroker del ham — 541 npm-Pakete entfernt)
• blinkpy 0.25.5 in einem venv unter /home/iobuser/blink-venv/
• Mini-CLI blink_control.py mit arm/disarm/status (gut 100 Zeilen)
• JS-Skript ruft via exec() mit den astro-Triggern auf
• Live verifiziert: Pfingst-Sonntagabend Arm-Trigger gefeuert, gestern früh 06:02 Disarm-Trigger ebenfalls

Heute morgen habe ich allerdings festgestellt, daß mein Batterie-Check noch über den alten HAM-Adapter ging und dort jetzt natürlich ins Leere zeigt — diese Funktionalität ist verloren, bis ein richtiger Adapter da ist. Damit ist klar: das Hotfix-CLI deckt nur die Arm/Disarm-Schedule ab, alles andere fällt aktuell aus.

Ziel-Architektur:

• Vollständiger ioBroker-Adapter mit Long-Running-Bridge (vermeidet die 30-60s Cold-Start-Latenz, die das Python-CLI pro Aufruf hat)
• Vermutlich Python-Subprozeß für die blinkpy-Anbindung, JSON-RPC oder MQTT als IPC, JS/TS-Adapter-Wrapper drumherum — Architektur noch offen, Vorschläge willkommen
• Datenpunkte für alle Networks und Cameras: Arm-Status (lesend + schreibend), Motion-Detection, Battery-Level, Wifi-Strength, Snapshot-Fetch, ggf. Live-View-URL
• 2FA-Erst-Auth einmalig per Konfig-UI, Token-Refresh dann transparent

Die Bitte

Was ich gebaut habe sind zwei Prototypen — der eine läuft schon im Alltag (das MCP-Werkzeug), der andere ist erstmal nur ein Pflaster (das Blink-Hotfix-CLI). Für beide brauche ich Mitstreiter, weil ich an einigen Stellen noch Bedarf habe:

• JS/TS-Adapter-Entwicklung im Allgemeinen — ich habe einiges an Python-Code geschrieben, aber das ioBroker-eigene Adapter-Ökosystem ist auf Node-basiert. Wer Lust hat, mir hier auf die Sprünge zu helfen, ist herzlich willkommen.
• HTTP(S) Streamable MCP Transport in einem ioBroker-Adapter — falls jemand das schon mal gemacht oder gesehen hat, Hinweise gerne.
• Architektur-Diskussion für iobroker.blink — Long-Running-Python-Bridge vs. native Node-Implementierung der Blink-API? IPC via MQTT/JSON-RPC/Unix-Socket? Ich habe Meinungen, aber keine endgültigen Antworten.
• Test-Setups für iobroker.blink — wer Blink-Hardware hat und im Adapter-Beta testen würde, gerne melden.
• Wunschverhalten für beide Adapter — was würde Euch sinnvoll erscheinen? Auch "ich würde das so nie nutzen, weil..." ist wertvolles Feedback.

Sobald die Repos ein bißchen Substanz haben, werde ich für iobroker.blink einen eigenen "Test/Entwicklung"-Thread aufmachen — Hinweis kommt hier dann nochmal. iobroker.mcp läuft erstmal weiter im jetzigen Repo (https://github.com/McCavity/iobroker-mcp), Issues / Feature-Requests / PRs nehme ich gerne an.

LG

McCavity