Im letzten Artikel lief alles im Simulator, und am Ende stand die Frage nach einem Hardware-in-the-Loop-Setup, bei dem die KI selbst mit der Hardware arbeitet. Diesmal hängt echte Hardware am Agenten: Claude Code flasht, liest das serielle Log und reagiert darauf. Und das Projekt ist eines, das ohne KI nie entstanden wäre.
Teil 2 der Reihe „KI in der Embedded-Entwicklung“. Teil 1: Claude Code trifft AVR-Assembler
Das Projekt
Vorhanden sind acht Rollläden mit Rademacher-Fernotron-Motoren. Das System funkt proprietär und unidirektional auf 433,92 MHz. An Alexa oder Apple Home lässt es sich nicht anbinden, neue Fernbedienungen kosten auf dem Gebrauchtmarkt ein Vermögen, und der Hersteller empfiehlt als Upgrade den Austausch aller Motoren gegen ein neues, inkompatibles System – weder nachhaltig noch wirtschaftlich. Also warum nicht das proprietäre Funkprotokoll an den offenen Smart-Home-Standard Matter ankoppeln? Ziel: ein minimales Stück Hardware ohne Löten, das sich als Matter-Bridge mit acht Rollläden meldet und die Befehle in genau die Funktelegramme übersetzt, die auch die Fernbedienung sendet.
Das Projekt stand jahrelang auf meiner Liste und wurde nie angefangen. Das Funkprotokoll hat die Community zum Glück längst entschlüsselt (tronferno, FernoPy). Aber Matter lernen, sich in ESP-IDF und das Matter-SDK einarbeiten, Funk-Encoder, Positionsschätzung, die Eigenheiten von Alexa: Der Aufwand hätte den Nutzen weit überstiegen. Kann KI hier helfen?
Der Signalweg: Alexa und Apple Home sprechen Matter mit dem Stick, der Stick funkt einseitig zu den Motoren.
Warum Matter?
Matter ist der offene Smart-Home-Standard der Connectivity Standards Alliance, hinter dem unter anderem Amazon, Apple und Google stehen. Er läuft lokal über IP (WLAN, Ethernet oder Thread), ohne Cloud: Ein Matter-Gerät spricht ohne eigene App oder Hersteller-Hub mit Alexa, Apple Home oder Google Home, auch mit mehreren gleichzeitig. Dazu kennt Matter Gerätetypen wie „Window Covering“ und Bridges, die Geräte fremder Systeme als eigene Endpunkte einblenden – genau das Richtige für das alte Funksystem.
Schritt 1: Entwickeln ohne Hardware
Ausgangspunkt war meine Vorgabe: möglichst einfach, nichts löten, direkte Matter-Anbindung ohne Hub oder Server. Claude suchte daraufhin die Hardware aus – ein M5Stack AtomS3 Lite (ESP32-S3) und eine M5Stack Unit RF433T als Sender, verbunden per Grove-Kabel –, recherchierte das Protokoll und plante die Schritte. Die Hardware war noch unterwegs, also:
User: Don't have the hardware yet, but can you start implementing already?
Claude richtet Toolchain und Repository ein und baut zuerst alles, was sich ohne Hardware testen lässt, als reines C++17: Telegrammaufbau, Puls-Encoder, Positionsschätzung über die Fahrzeiten (die Motoren melden keine Position zurück). Dazu Unity-Tests, die auf dem Mac laufen; der Encoder wird bitgenau gegen Testvektoren geprüft.
Der erste Prototyp lief mit Arduino-ESP32, dessen vorkompilierte Matter-Bibliothek aber nur vier Endpunkte erlaubt, zu wenig für acht Rollläden. Nach einigem Hin und Her geht es mit ESP-IDF und esp-matter weiter.
Schritt 2: Hardware in the Loop – der erste Flash
Die komplette Hardware: M5Stack AtomS3 Lite (ESP32-S3) und die 433-MHz-Sendeeinheit RF433T, verbunden per Grove-Kabel.
Dann ist die Hardware da und steckt per USB am Mac. Claude sucht den richtigen Port, baut, flasht, startet das Board neu und beobachtet das Boot-Log. Darin steht:
1 |
|
Ein Boot-Loop. Knapp sechs Minuten später ist er behoben, ohne dass ich etwas tun muss: Claude liest Backtrace und Stackgrößen, findet die Ursache (ein NVS-Puffer und Kopien der Konfiguration auf dem nur 3,5 KB großen Stack des Main-Tasks), legt die Daten in statischen Speicher, vergrößert den Stack, flasht neu, prüft das Boot-Log und committet. Die erste Nachricht, die ich lese:
Claude: First flash crashed. The first flash put the board in a boot loop: my settings code overflowed the small main-task stack (and the console's stack was too small too). I fixed it, reflashed, and committed the fix.
Genau so ein Fehler ist in den Host-Tests unsichtbar, weil der Stack auf dem Mac Megabytes groß ist. Er zeigt sich nur auf dem Zielsystem, und dort hat der Agent ihn selbst gefunden.
Pairing
Zehn Minuten nach meinem Prompt war der Stick in Alexa eingebunden. Beim Pairing („Commissioning“) scannt man in der Alexa-App den QR-Code, den Claude gleich mitliefert; per Bluetooth LE bekommt der Stick WLAN-Daten und ein Zertifikat, danach läuft alles lokal. Alexa warnt nur vor einem nicht zertifizierten Gerät, dann erscheinen die Bridge und acht Rollläden. Über die Freigabe in der Alexa-App kam später das iPhone dazu; seitdem steuern Alexa und Apple Home dieselben Rollläden parallel.
Die acht Rollläden in Apple Home, nach Räumen sortiert.
Schritt 3: Der erste Funkbefehl
Die ID meiner Fernbedienung über die serielle Konsole konfiguriert, in der Alexa-App einen Rollladen auf 43 % gezogen, und der echte Motor fährt los und hält per getimtem STOP an. Beim ersten Versuch. Die Funktelegramme erzeugt das RMT-Peripheral des ESP32, das Pulsfolgen hardwaregetaktet mit 2,5 µs Auflösung ausgibt.
Ein Telegramm, wie es die Firmware sendet: Präambel, dann sechs Bytes, jedes zweimal mit Paritätsbits. Gezeichnet aus der Ausgabe des echten Encoders, die Absender-ID ist frei gewählt.
Schritt 4: Debuggen am laufenden System
Ab hier verschiebt sich die Arbeit: Der Code war schnell geschrieben, die eigentlichen Probleme stecken im Zusammenspiel mit Alexa und Apple Home. Die Rollen sind klar verteilt: Claude hat das serielle Log im Blick und liest bei Bedarf den Quellcode des Matter-SDK; ich bin der Sensor, der sieht, ob sich ein Rollladen bewegt.
Die meisten Probleme hängen damit zusammen, wie Alexa die Bridge sieht: als acht einzelne Geräte.
Jeder Rollladen ist in der Alexa-App ein eigenes Gerät. Eine Routine „alle Rollläden öffnen“ schickt deshalb acht einzelne Befehle.
- Alexa sendet nichts. Eine solche Routine lässt einige Rollläden zu. Claude prüft das Log: Es ist überhaupt kein Befehl angekommen. Mein Einwurf: "maybe it thinks they are already open?" Treffer: Nach einem Neustart hatte die Firmware alle Rollläden als offen gemeldet, und Alexa überspringt Befehle für Geräte, die angeblich schon am Ziel sind. Jetzt werden die Positionen im Flash gespeichert.
-
Acht Telegramme statt einem. Im Log misst Claude, dass die acht Befehle etwa 200 ms auseinander eintreffen. Bei gut einer Sekunde Sendezeit pro Telegramm (mit Wiederholungen) fuhr das letzte Zimmer erst nach sechs Sekunden los. Jetzt sammelt die Firmware Befehle und fasst sie zu Gruppentelegrammen zusammen; im Log steht danach
rf: UP g0 m0 (8 merged): ein Telegramm für das ganze Haus. - Verlorene Befehle nach Neustarts. Nach einem Flash verwarf die Bridge die Pakete eines Echos, das weiter seine alte Verbindung nutzte; fünf von acht Befehlen gingen verloren. Den Wiederaufbau plant das SDK standardmäßig erst nach zehn Minuten, wie Claude im Quellcode findet. Zwei Konfigurationswerte später sind beide Echos 30 Sekunden nach dem Booten wieder verbunden.
Zwei weitere Prompts später zeigt die RGB-LED des AtomS3 den Pairing- und Betriebsstatus der Bridge, und Updates sowie Konsole sind über WLAN zugänglich.
Der versteckte Fehler, den das Log nicht zeigte
Ab und zu reagierte ein Rollladen nicht, meist während Routinen mit mehreren Rollläden, auch als der Stick dank WLAN-Updates zwei Meter daneben stand. Mehr Wiederholungen und anderes Timing brachten wenig; ich hatte das schon als Grenze eines unidirektionalen Funksystems abgehakt. Das Log sagte jedes Mal: Befehl empfangen, Telegramm gesendet. Verdächtigt hat Claude (teils auf mein Nachfragen) schlechten Empfang bei laufendem Motor, den Rolling Counter und die Reihenfolge der Wiederholungen. Erst als ein Rollladen direkt neben dem Stick in zwei Routinen hintereinander alle acht Kopien seines Befehls verpasste, ging Claude die Sendekette bis in den Treiber durch und landete beim RMT-Peripheral.
Kurz zur Funktionsweise: Das RMT (Remote Control Transceiver) gibt Pulsfolgen ohne Zutun der CPU aus. Die Software legt eine Liste von Symbolen, jedes ein High- und ein Low-Abschnitt mit seiner Dauer, in einen kleinen RAM-Bereich im Peripheral, und die Hardware arbeitet sie taktgenau ab. Ein Telegramm braucht 141 Symbole, die Firmware hatte aber nur Platz für 96 reserviert. Der Treiber arbeitet deshalb im Ping-Pong-Betrieb: Ist eine Hälfte gesendet, füllt ein Interrupt sie nach, während die andere hinausgeht.
Genau dieser Interrupt läuft in der Standardkonfiguration nicht, solange der Flash beschrieben wird, denn dann ist der Cache abgeschaltet. Und geschrieben wurde reichlich: esp-matter speichert die Position jedes fahrenden Rollladens alle 500 ms im Flash, während einer Routine rund 30-mal pro Sekunde, samt gelegentlichem Löschen eines Sektors, das einige zehn Millisekunden dauert. Fällt das mitten in ein Telegramm, geht es verstümmelt hinaus, und der Motor verwirft es wegen der falschen Prüfsumme.
Die Lösung waren zwei kleine Änderungen: Der Funkkanal reserviert jetzt Platz für 144 Symbole, das ganze Telegramm liegt also vor dem Start im Peripheral. Und die Positionen landen erst drei Sekunden nach der letzten Änderung im Flash. Seitdem laufen die Routinen sauber durch.
Bewiesen ist der Zusammenhang allerdings nicht, und genau da liegt die Lehre: Das Log zeigt, was die Firmware senden wollte, nicht, was tatsächlich hinausging. Mit einem Logic Analyzer am Datenpin des Senders oder einem SDR-Empfänger hätte Claude die verstümmelten Telegramme selbst gesehen, statt über Empfang und Zählerstände zu spekulieren.
Der Mensch als Handlanger der KI?
Moment, der Entwickler als "Sensor" für die KI? Wird der Mensch zum bloßen Anhängsel der Maschine degradiert? Zumindest noch nicht ganz: Zu oft verrennt sich Claude in eine Hypothese – etwa über das Verhalten der Funkempfänger – und beginnt, darauf ungeprüft komplexe Workarounds zu bauen. Der erfahrene Entwickler sieht das sofort, und meist reicht ein eingeworfenes "are you sure?", damit Claude innehält. Auch frühe Designentscheidungen trifft manchmal besser der Mensch: Claude hielt lange an einem einzelnen Matter-Gerät statt einer Bridge fest und versuchte zu lange, die Grenzen der Arduino-Bibliothek zu umgehen.
Aufwand und Ergebnis
Mein Einsatz, verteilt über eine Woche:
- Rund 140 Nachrichten mit zusammen rund 13.000 Zeichen, ohne eingefügte Logs. Die meisten unterwegs vom Smartphone aus, oft nur ein Wort wie "Flash" oder ein Satz wie "just ran the routine".
- Keinen Code gelesen oder geschrieben – abgesehen von ein paar Stichproben "was macht der da eigentlich"; die serielle Konsole habe ich ein paar Minuten lang selbst bedient.
- Dazu Hardware einstecken, mit Alexa und dem iPhone koppeln, Rollläden beobachten.
Insgesamt schätze ich zwei bis drei Stunden, verteilt in kleinen Häppchen.
Herausgekommen ist eine funktionierende, maßgeschneiderte Matter-Bridge, bestehend aus rund 2.700 Zeilen C++ Firmware, 1.400 Zeilen Tests mit 138 Testfällen, 38 Commits und einer README. Klassisch hätte ich dafür mehrere Wochen Abendarbeit gebraucht, realistisch hätte ich nie angefangen. Kosten: keine 20 Euro für die Hardware, 20 Euro für das Claude Monatsabo. Verwendet habe ich Claude Code Desktop mit Opus 5.5. Mit Codex, Kiro o.ä. hätte das vermutlich genauso funktioniert, vorausgesetzt ein halbwegs aktuelles Modell ist verfügbar.
Fazit
Teil 1 hat gezeigt, wie KI Embedded-Software schreibt. Teil 2 zeigt, was sich ändert, wenn der Agent die Hardware selbst flashen und das Log lesen kann: Er schließt die Schleife zwischen Code und realem Verhalten selbst. Der Stack Overflow ist ein kleines Beispiel, aber typisch: Fehler, die nur auf dem Zielsystem auftreten, sind gefunden und behoben, bevor ich sie überhaupt sehe.
Die Grenze liegt dort, wo der Agent keine Sensoren hat: ob sich ein Rollladen bewegt, was die Alexa-App anzeigt, ob ein Funksignal im hintersten Zimmer ankommt. Der nächste logische Schritt wäre deshalb Messtechnik am Agenten: ein Logic Analyzer oder SDR-Empfänger am Mac, mit dem Claude seine eigenen Funktelegramme prüfen kann.
Ein interessanter Aspekt: Projekte wie dieses, alte Geräte mit Nischenprotokoll an moderne Systeme anzubinden, waren bisher schlicht unwirtschaftlich. Jetzt sind sie ein Nebenbei-Projekt für ein paar Abende. Welche Altgeräte würdet ihr auf diese Weise wiederbeleben? Und wer schon Erfahrung mit Hardware-in-the-Loop-Setups für KI-Agenten hat: gern in die Kommentare.
Das Projekt auf GitHub: matter-shutter-bridge
-
01-hardware.jpg
(230 KB)
-
02-alexa.png
(130 KB)
-
03-apple-home.png
(370 KB)
-
signalweg.png
(150 KB)
-
telegramm.png
(140 KB)