Eine Vase aus Spanien
Im Urlaub kauften wir eine Vase, die nun im Wohnzimmer hinter Glas wohnen soll — Enkelschutz, denn ein im Wohnzimmer geworfener Ball trifft mit Verlässlichkeit, was er nicht treffen sollte. Damit man das Stück trotzdem von allen Seiten sehen kann, braucht es einen Drehteller. Klar, kann man kaufen. Aber so eine Aufgabe ist auch ein willkommener Anlass, einen Mikrocontroller wieder einmal in die Hand zu nehmen — und diesmal mit einem AI-Coding-Assistenten an der Seite.
Hardware
Das Herzstück ist ein LilyGo TTGO T-Display — ein ESP32 mit einem 1,14"-IPS-Farbdisplay (240×135 Pixel), zwei Tastern und WLAN. Daran hängen ein 28BYJ-48-Schrittmotor mit 64:1-Getriebe (über einen ULN2003-Treiber) und ein Ring aus 16 farbigen WS2812B-LEDs zur Innenbeleuchtung. Die mechanische Aufnahme — Drehlager, Sockel, Tellerträger — ist im nächsten Abschnitt beschrieben.
Versorgt wird das Ganze über USB. Bei voller weißer Beleuchtung würde der LED-Ring etwa 960 mA ziehen — mehr als der USB-Bus liefert. Die Firmware deckelt deshalb die Helligkeit per Default bei 60 %, was den Spitzenstrom auf rund 580 mA bringt. Praktisch unsichtbar, betriebssicher.
3D-Design
Die mechanische Basis ist ein industrielles 120-mm-Aluminium-Drehlager mit einer axialen Tragfähigkeit von 5 kg — robust genug auch für ein deutlich schwereres Schaustück als die Vase. Darum herum sind drei Kunststoffteile selbst entworfen und gedruckt: ein Sockel, der den Stepper, die ULN2003-Treiberplatine und das TTGO-Display in passgenauen Aufnahmen hält; ein Tellerträger, der auf dem Lager läuft und das Drehmoment vom Motor entgegennimmt; und ein LED-Ringhalter, der das Licht von innen nach oben streut.
Konstruiert wurde alles in Onshape — einem cloudbasierten parametrischen CAD-System, das im Browser läuft, vollständige Versionierung mitbringt und keine lokale Installation braucht. Der Druck erfolgte auf einem BambuLab-Drucker im Standardprofil; die Druckzeit für sämtliche Teile zusammen war länger als so manche Iterationsschleife am Web-UI.
Diese CAD-Arbeit habe ich noch klassisch von Hand erledigt — Skizzen ziehen, Profile extrudieren, Bohrungen setzen, Kanten verrunden. Wie weit Agentic Coding inzwischen auch beim mechanischen Konstruieren trägt, möchte ich bei Gelegenheit ausprobieren.
Onshape-Modell des Sockels — Aufsicht (links) und Unteransicht mit den Aufnahmen für Display, Treiberplatine und Schraubdomen (rechts).
Web-UI und Funktionsumfang
Der ESP32 bringt seinen eigenen Web-Server mit. Beim Boot zeigt das Display kurz seine MAC-Adresse und seine IP-Adresse an — danach genügt der Browser auf einem beliebigen Gerät im LAN, um:
- die Drehzahl zwischen 0,05 und 15 RPM einzustellen, mit Beschleunigungsrampe, sodass Richtungswechsel weich durch den Nullpunkt gleiten;
- die Drehrichtung umzukehren;
- den Lichtring in HSV zu steuern (Farbton, Sättigung, Helligkeit, an/aus);
- das Nacht-Fenster (Start- und Endzeit) zu definieren — in diesem Zeitraum schalten sich Motor und Licht automatisch ab und morgens wieder an.
Eine NTP-Zeitsynchronisation sorgt dafür, dass das Nacht-Fenster zur richtigen Zeit greift. Ein WiFi-Watchdog reagiert in zwei Stufen auf einen Verbindungsabriss: zunächst ein sanftes WiFi.reconnect(), ab dem dritten Fehlversuch ein vollständiger STA-Stack-Reset — alles ohne CPU-Reboot, damit die Drehung nicht ungebremst stoppt. Ein OTA-Update-Endpoint erlaubt das Einspielen einer neuen Firmware oder neuer UI-Dateien per Drag-and-Drop im Browser. Das Display selbst geht nach 60 Sekunden ohne Tastendruck schlafen, damit es nachts nicht stört.
Die HTML-, CSS- und JavaScript-Dateien des Web-UI liegen im LittleFS-Filesystem des Chips — so kann man die Oberfläche überarbeiten, ohne die Firmware neu zu kompilieren.
Toolchain
Der Aufbau der Werkzeugkette war der eigentliche Aufwand. Der Code entsteht unter WSL2 im Wechsel mit Claude Code, wird per Datei-Sync in das Windows-Filesystem gespiegelt und dort mit der Arduino IDE 2 kompiliert und auf das Device geladen. Nach dem ersten Flash über USB läuft alles weitere als Over-the-Air-Update über den Browser — kein Kabel mehr, auch nicht für Asset-Änderungen. Das Schwierigste war die etwas hakelige DMA-Ansteuerung des Displays, die einen passenden TFT_eSPI-Setup verlangt.
Bis dieser Pfad durch den Dschungel gefunden war: etwa zwei Tage.
Aber sobald die Toolchain steht, ist eine Anwendung wie der Drehteller in rund zwei Stunden produktionsreif — inklusive Verdrahtungsplan, Web-UI und Watchdog. Die Diskussion mit dem KI-Assistenten ersetzt einen Großteil der klassischen Datenblatt-Suche und der Library-Recherche und beschleunigt jede einzelne Iteration.
Größenordnung
Der gesamte Drehteller-Code, in Zeilen:
| Datei | Zeilen | Zweck |
|---|---|---|
| TurnTable.ino | 264 | Setup, Loop, Statusverwaltung |
| WebUi.cpp / .h | 271 | REST-API + LittleFS-Auslieferung |
| Display.cpp / .h | 219 | TFT_eSPI-Wrapper, Statusansicht, Auto-Sleep |
| StepperDrive.cpp / .h | 165 | Beschleunigungsrampe, Schrittmotor-Tick |
| NightSchedule.cpp / .h | 124 | Edge-getriggerter Tag/Nacht-Wechsel |
| LedRing.cpp / .h | 118 | NeoPixel-Ansteuerung in HSV |
| Config.h | 102 | Pin-Belegung, Timing-Konstanten |
| TimeSync.cpp / .h | 60 | NTP-Polling |
| Web-Assets im Flash (data/) | 283 | index.html, app.js, style.css, files.html |
| README.md | 166 | Build, Pinout, API |
Insgesamt rund 1.400 Zeilen Firmware (C++/Arduino) plus knapp 300 Zeilen Web-Assets für einen voll funktionsfähigen Vase-Beleuchter mit WLAN, Web-UI, NTP, Nacht-Schedule, Reconnect-Watchdog, Display-Auto-Sleep, Beschleunigungsrampe und OTA. Das ist ziemlich kompakt.
Eine zweite App auf derselben Plattform: micmon
Sobald die Werkzeugkette stand, lag eine zweite Anwendung nahe — diesmal kein Aktor, sondern ein Monitor: micmon, ein kleines Wand-Display, das die Auslastung des RAP-Clusters live anzeigt. Identisches TTGO T-Display, identische Toolchain, ein knapper HTTP-Client pollt alle 5 Sekunden den Cluster-Endpoint und rendert pro Worker einen gestapelten Balken (Read- gegenüber Schreib-Last). Insgesamt etwa 850 Zeilen Code. Aufwand: ein Nachmittag.
Damit wird sichtbar, was die durchgängige Tool-Chain wirklich wert ist: dieselbe Plattform, einmal als drehender, leuchtender Aktor (TurnTable), einmal als nüchterne Beobachtungsstation (micmon). Der Sprung von der einen zur anderen Anwendung kostet beinahe nichts mehr, sobald die Chain einmal steht.
Was sich damit für Hardware-Bastler öffnet
Die spannendste Beobachtung am Rande dieser Projekte: Mit Agentic Coding kann jemand, der vor allem an der Hardware tüftelt und nur einen begrenzten Software-Hintergrund mitbringt, erstmals ernsthafte Software-Lösungen bauen — Lösungen, die nicht nur funktionieren, sondern eine gewisse Professionalität ausstrahlen.
Der Schlüssel ist allerdings ein Gerüst, das die wichtigen Architekturentscheidungen bereits in sich trägt. Der KI-Assistent ist ein begnadeter Detail-Erfüllungsgehilfe, aber er wählt nicht von sich aus den asynchronen Webserver statt des blockierenden, er führt nicht ohne Aufforderung einen Watchdog ein, er trennt Web-Assets nicht automatisch vom Firmware-Code. Wer ihn nur fragt „bau mir ein Web-UI für meinen Sensor", bekommt etwas, das kompiliert — aber das beim ersten Verbindungsabriss steht oder beim nächsten UI-Update einen erneuten USB-Flash erzwingt.
Mit dem richtigen Skelett von Anfang an sieht das anders aus. Die TurnTable-Firmware demonstriert, was so ein Gerüst leisten muss:
ESPAsyncWebServerstatt klassischem WebServer — der HTTP-Server blockiert nicht den Loop, in dem der Schrittmotor und der LED-Ring laufen.- OTA-Update von Anfang an — nach dem ersten USB-Flash gibt es kein Kabel mehr. Klingt banal, ist aber der Unterschied zwischen „ich teste schnell mal was" und „ich muss erst hinterm Schrank das Gerät rausziehen".
- Web-Assets im Flash-Filesystem statt im PROGMEM — UI-Iterationen kosten keinen Compile-Zyklus, und Mehrsprachigkeit oder ein Theme-Wechsel werden zu reinen Asset-Tausch-Operationen.
- Wiederverbindungs-Watchdog mit Eskalation — das Gerät überlebt einen Router-Neustart, ohne dass man es vom Strom nehmen muss.
- Beschleunigungsrampe statt harter Sprünge — die Mechanik wird geschont, Schritte werden nicht ausgelassen, der Aktor verhält sich „erwachsen".
- Sauber getrennte Module mit klaren Schnittstellen —
Display,StepperDrive,LedRing,NightSchedule,WebUi,TimeSync. Jedes Modul kann der Coding-Agent isoliert verstehen, anpassen oder erweitern, ohne anderswo Schaden anzurichten.
Diese Entscheidungen müssen einmal getroffen und im Code verankert werden — am besten von jemandem, der weiß, wo die Falltüren liegen. Danach übernimmt der KI-Agent: Er ergänzt das WebUi um einen neuen Endpoint, baut einen weiteren Effekt in den LedRing, integriert ein zusätzliches Sensor-Modul — alles innerhalb des Rahmens, der die professionellen Eigenschaften garantiert. Was früher zwei Wochen Einarbeitungskurve gekostet hätte, ist jetzt ein Nachmittag.
So wird Agentic Coding für Hardware-affine Menschen mehr als ein Spielzeug: Es wird zur Brücke zu professioneller Software, ohne dass man die ganze Software-Welt vorher verstanden haben müsste — vorausgesetzt, jemand hat das Gerüst gebaut.
Etwas für Studierende
Der Drehteller eignet sich gut als überschaubare Aufgabe in Lehre oder Selbststudium: 1.400 Zeilen Firmware sind in einem Wochenende lesbar, der Code ist modular gegliedert, jede Datei hat einen klaren Zweck. Mögliche Erweiterungen, in steigendem Schwierigkeitsgrad:
- Alexa-Anbindung über eine passende Bibliothek (z.B.
fauxmoESP) — der Drehteller wird zum sprachgesteuerten Smart-Home-Gerät. - Mehrsprachiges UI — die Trennung zwischen Firmware und Web-Assets im LittleFS macht Lokalisierung einfach. Eine zweite
index.htmlreicht. - Persistente Konfiguration über NVS — die zuletzt eingestellte Drehzahl, Richtung und das Nacht-Fenster überleben einen Stromausfall.
- MQTT-Integration — der Teller meldet seinen Zustand an einen Broker, andere Geräte können reagieren.
- Eigene Ideen — der Code ist klein genug, um ohne große Reibung daran herumzuprobieren.
Wer mehr über den Prozess der KI-gestützten Entwicklung wissen möchte, findet auf der Startseite und unter Rapid Application Platform ausführlichere Erfahrungsberichte. Beides ist mit demselben Werkzeugkasten gebaut, allerdings auf ganz anderem Größenmaßstab.
Kontakt: Dr. Gero Scholz · gero.scholz@gmail.com