ESP-Claw mit dem eigenen Ollama-Server verbinden – Konfiguration und erste Chats

Nachdem ich euch in Teil 3 meiner ESP-Claw-Serie gezeigt habe, wie ich eine eigene Board-Adaption für mein Guition JC1060P470 geschrieben habe, kommt jetzt der Moment, auf den ich die ganze Serie über hingearbeitet habe: Der erste echte Dialog zwischen meinem ESP32-P4-Board, ESP-Claw und meinem lokalen Ollama-Inferenz-Server.

Hier endet die Grundlagenarbeit, und es beginnt der wirklich spannende Teil meines Projektes. Aber natürlich wäre es ja zu einfach, wenn alles auf Anhieb funktionieren würde. Der Weg zum ersten Chat hatte noch eine unerwartete aber zum Glück recht kurze Sackgasse parat aber dazu gleich mehr.

Phase 1: Die Firmware ist drauf und was passiert beim Booten?

Nach dem erfolgreichen Flash aus Teil 3 habe ich die serielle Konsole geöffnet und den Boot-Vorgang beobachtet. Das war genau der Moment der Wahrheit. Funktioniert die Board-Adaption? Findet ESP-Claw seinen WiFi-Co-Prozessor?

Befehl: idf.py -p COM7 monitor

Was ich im Log gesehen habe, war ein durchgängiger Erfolg:

• PSRAM mit 32 MB bei 200 MHz Octal-Mode erkannt
• Alle Peripherie-Blöcke aus meiner YAML initialisiert (I²C, I²S, GPIO, LDO, MIPI-DSI, LEDC)
• Beide ES8311-Codec-Instanzen (DAC und ADC) gestartet
• ESP-Hosted Host-Seite beginnt SDIO-Probe
• ESP32-C6 als Slave erkannt: transport: Identified slave [esp32c6]
• Capabilities ausgehandelt: WLAN + HCI über SDIO + BLE

Ein Eintrag fiel mir besonders auf:

W (3187) transport: Version mismatch: Host [2.12.0] > Co-proc [2.3.0] ==> Upgrade co-proc to avoid RPC timeouts

Die werkseitig auf dem ESP32-C6 geflashte ESP-Hosted-Slave-Firmware ist älter als die Host-Bibliothek auf meinem P4. Für den grundlegenden Betrieb funktioniert das, aber ich habe es als Punkt für später notiert (die C6-Firmware könnte irgendwann mal ein Update gebrauchen).

Nach wenigen Sekunden tauchte dann der entscheidende Eintrag auf:

wifi_manager: *** Provisioning AP active: esp-claw-000000 @ 192.168.4.1 ***

ESP-Claw hatte seinen eigenen WiFi-Access-Point eröffnet, damit ich ihm die Zugangsdaten meines Heim-WLANs mitteilen kann. Jetzt war es Zeit, das Smartphone zur Hand zu nehmen.

Phase 2: Die unerwartete Sackgasse mit dem Android-Smartphone

Mein Plan war simpel: Mit dem Android-Telefon zum AP esp-claw-000000 verbinden, im Browser http://192.168.4.1 aufrufen, SSID und Passwort meinen Heimnetzwerkes eingeben, fertig. So einfach hatte ich es mir vorgestellt.

Die Realität sah aber anders aus.

Sobald sich mein Smartphone mit dem ESP-Claw-AP verbunden hatte, prüfte Android im Hintergrund, ob hinter diesem WLAN überhaupt Internet erreichbar ist. Da der ESP-Claw-AP natürlich keinen Internetzugang bietet, da er nur die Konfiguration empfangen möchte, schaltete Android nach wenigen Sekunden automatisch zurück auf mein normales Heim-WLAN. Praktisch ständig hat es das automatisch geprüft und entschieden.

Das ist kein Problem mit ESP-Claw, sondern ein bekanntes Verhalten moderner Android-Versionen. Die Funktion nennt sich „intelligenter Netzwerkwechsel“ und soll Nutzer eigentlich davor schützen, mit „kaputten“ WLANs verbunden zu bleiben. Bei der Erstkonfiguration eines IoT-Geräts ist das aber genau das Gegenteil von dem was man möchte.

Ich habe einige Minuten versucht, in den Android-Einstellungen die richtigen Schalter zu finden um den AP halten zu können. Dann bin ich aber zu der entscheidung gekommen einfach den PC zu verwenden. Mein Notebook hatte mit dem ESP-Claw-AP überhaupt keine Probleme und blieb stabil verbunden.

Meine Empfehlung an euch: Bei der ESP-Claw-Erstkonfiguration spart euch den Kampf mit Android wenn ich nicht wisst wie ich wo die Konfiguration erfolgt und nehmt einfach gleich einen PC oder Laptop. Das spart Zeit und Nerven.

Phase 3: Die WiFi-Zugangsdaten eingeben

Vom PC aus war der Vorgang dann ein Kinderspiel:

1. WLAN-Liste öffnen und mit esp-claw-000000 verbinden (kein Passwort nötig)
2. Browser starten und http://192.168.4.1 aufrufen
3. Im Captive-Portal die SSID und das Passwort meines Heim-WLANs eingeben
4. Speichern bestätigen

Nach ein paar Sekunden meldete der ESP-Claw seinen eigenen AP wieder ab, verband sich als Station mit meinem Heim-WLAN und bekam vom Router eine reguläre IP-Adresse zugewiesen.

Bei mir war das 192.168.178.161. Ab diesem Moment war mein ESP-Claw als ganz normaler Teilnehmer in meinem LAN erreichbar einschließlich mDNS-Hostname esp-claw.local.

Phase 4: Das Web-Konfigurations-Interface von ESP-Claw

Über die LAN-IP des Boards öffne ich jetzt das vollständige Konfigurations-Interface von ESP-Claw. Hier kommt der Aha-Moment für jeden, der bisher nur Sprachassistenten-Software wie Home Assistant oder Open WebUI kennt: ESP-Claw bringt ein erstaunlich vollständiges Web-UI mit, das direkt auf dem Mikrocontroller läuft. Kein zusätzlicher Server, keine externe App, alles im 16 MB Flash des ESP32-P4.

ESP-CLAW System Status

Die Seitenleiste zeigt mir alle Konfigurationsbereiche:

• System Status – Überblick über CPU, RAM, Storage
• System Settings – Basic, LLM, IM, Web Search
• Memory – Persistenter Speicher des Agenten
• Web Chat – Direkte Interaktion mit dem Agenten
• Capabilities – Fähigkeiten ein/ausschalten
• Lua Modules – Skript-Module verwalten
• Files – Dateisystem-Zugriff

Der eigentliche Schritt zur LLM-Anbindung passiert unter System Settings → LLM.

Phase 5: Ollama als LLM-Backend konfigurieren

Auf der LLM-Seite stelle ich ESP-Claw mit, dass es nicht OpenAI, Anthropic oder DeepSeek nutzen soll, sondern meinen eigenen Ollama-Server, der bei mir auf 192.168.2.57:11434 läuft. Auf meinem privaten Inferenz-Server, ausgestattet mit zwei NVIDIA RTX A6000 GPUs.

ESP-CLAW LLM config

Da Ollama eine OpenAI-kompatible API bereitstellt, wähle ich oben den Preset „OpenAI Compatible API“. Damit werden Felder vorausgefüllt, die ich anschließend an meine eigene Umgebung anpasse:

Drei wichtige Hinweise aus meiner Praxis:

1. Die Base URL muss mit /v1 enden, nicht ohne. Wenn ihr die URL ohne /v1 im Browser öffnet, bekommt ihr von Ollama nur ein „404“. Das verleitet zu der Annahme der Server sei nicht erreichbar dabei ist nur der Pfad falsch.
2. Der Modellname muss exakt dem aus ollama list entsprechen, inklusive aller Suffixe wie :35b-a3b-bf16. Tippt ihr nur „qwen3.6“ rein, bekommt ihr einen HTTP 404 vom Ollama-Server.
3. Das Feld „Max Tokens Field“ ist trickreich. Neuere OpenAI-APIs nutzen max_completion_tokens, aber Ollama erwartet noch das ältere max_tokens. Wenn ihr das falsche Feld wählt, kommt ein HTTP 400 zurück.

Nach dem Speichern und einem Neustart des Boards ist der Inferenz-Server konfiguriert.

Phase 6: Die Subnetz-Frage zwischen Hauptnetz und Inferenz-Server

Hier muss ich eine Besonderheit meines Heim-Netzwerks erwähnen: Mein ESP-Claw befindet sich im 192.168.178.x-Netz (mein normales Heim-WLAN am Router), während mein Ollama-Server im 192.168.2.x-Netz steht.

Damit ESP-Claw überhaupt mit dem Server reden kann, muss zwischen den beiden Subnetzen geroutet werden. Bei mir kümmert sich darum mein Hauptrouter, der zwischen beiden Subnetzen vermittelt. Falls ihr ein ähnliches Setup habt, prüft das vorher mit einem simplen ping oder einem Browser-Zugriff vom selben Subnetz, in dem ESP-Claw später sitzen wird.

Falls bei euch beides im gleichen Subnetz liegt (z. B. alles auf 192.168.1.x), spart ihr euch das Thema komplett.

Phase 7: Der erste Chat – „Who are you?“

Nach dem Reboot und dem erneuten Aufrufen der ESP-Claw-Web-UI öffne ich den Web Chat aus der Seitenleiste. Das Status-Label zeigt grün „Online“, also läuft die WebSocket-Verbindung zwischen meinem Browser und dem ESP-Claw-Backend.

Mein erster Satz: „Who are you?“

Eine simple Frage, die mir aber sofort verraten würde, ob die komplette Kette funktioniert: Browser → ESP-Claw HTTP-Server → Agent-Logik → HTTP-Request zu Ollama → Modell-Inferenz auf den A6000-GPUs → Antwort-Streaming zurück → Browser.

Nach etwa 23 Sekunden Wartezeit kam die Antwort zurück:

ESP-CLAW running chat dialog

„I am ESP-Claw, an on-device AI agent. I specialize in turning user intent into device-aware help and action, focusing on orchestration, tool use, and practical execution. How can I assist you?“

Es funktionierte. Mein ESP32-P4 sprach gerade mit einem 35-Milliarden-Parameter-Modell, das auf meinen eigenen GPUs in meinem eigenen Netzwerk lief. Kein OpenAI, kein Anthropic, keine Cloud. Nur Hardware unter meinem Dach, die Sache komplett unter meiner Kontrolle.

Das war ehrlich gesagt einer der schönsten Maker-Momente der letzten Wochen.

Phase 8: Was kann ESP-Claw eigentlich? Ein Blick auf die Capabilities

Nach diesem ersten Erfolgserlebnis war ich neugierig, was mein neuer Agent eigentlich schon alles standardmäßig kann. Ein Blick auf die Capabilities-Seite zeigt eine beeindruckende Liste vorgefertigter Fähigkeiten:

ESP-CLAW Capabilities

Bei mir sind 18 Capabilities aktiviert, davon 5 als „LLM-sichtbar“ gekennzeichnet. Der Unterschied:

• Aktiviert bedeutet, die Capability ist im Build enthalten und kann genutzt werden
• LLM-sichtbar bedeutet, das Sprachmodell weiß automatisch, dass diese Capability existiert und kann sie selbständig in seinen Tool-Calls einplanen

Aktiviert sind unter anderem:

• Messenger-Integrationen: QQ, Feishu, Telegram, WeChat, Local IM (Web-Chat)
• System-Integration: Files, Scheduler, System, Time
• KI-Erweiterungen: Skill Manager, MCP Client, MCP Server, LLM Inspect
• Web-Funktionen: Web Search, Router Manager, Session Manager
• Agent-Kern: Memory, Lua-Runtime

Im nächsten Beitrag der Serie werde ich tiefer in die Architektur dieser Capabilities einsteigen denn das ist die Grundlage für alle eigenen Erweiterungen, die ich plane.

Phase 9: Lua-Module – das Tor zu eigenen Skills

Ein Blick in die Lua Modules zeigt mir, dass ESP-Claw mit einer überraschend reichhaltigen Auswahl an Hardware-Bindings ausgeliefert wird was ja auch richtig Sinn macht:

ESP-CLAW Lua Modules

Alle 17 Module sind bei mir aktiv:

• Hardware-Treiber: ADC, GPIO, I2C, MCPWM, Touch, UART
• System-Funktionen: Audio, Display, ESP Heap, Storage, System
• Agent-Integration: Board Manager, Button, Capability, Event Publisher
• Spezielle Module: Delay, LED Strip

Genau hier werde ich später meine eigenen Skripte einklinken um mein Roboter-Auto zu steuern. Die Hardware-Module wie uart und gpio sind genau die Bausteine, die ich brauche, um über WiFi mit meinem ESP32-basierten Roboter-Auto zu kommunizieren.

Phase 10: Memory – das Gedächtnis des Agenten

Ein weiterer faszinierender Bereich ist das Memory-System. ESP-Claw speichert nicht nur die aktuelle Unterhaltung im RAM, sondern hat persistente Speicherdateien auf der FATFS-Partition. Das muss ich mir noch einmal genauer anschauen da ja mein Board auch einen Steckplatz für eine micro-SD Karte mitbringt:

ESP-CLAW Memory

Vier Memory-Dateien sind standardmäßig vorhanden:

1. Long-term Memory – hier sammelt der Agent Fakten über mich, die er sich merken soll
2. Soul – die Persönlichkeitsbeschreibung des Agenten („Practical and execution-oriented“, „Calm, concise, and trustworthy“)
3. Identity – die Identitätskarte („Name: ESP-Claw“, „Role: On-device AI agent“)
4. User Info – Informationen über mich als Nutzer

Das ist eine elegante Lösung: Diese Markdown-Dateien werden in jedem System-Prompt mitgeschickt, sodass der Agent eine konsistente Persönlichkeit hat und sich an wichtige Dinge erinnert. Wer schon einmal versucht hat, einem stateless LLM Konsistenz beizubringen weiß, wie wertvoll sowas ist.

Phase 11: Web Search optional aktivieren

Ein letzter Punkt, den ich in dieser Sitzung konfiguriert habe (oder eher: bewusst nicht konfiguriert habe), war die Web-Suche:

ESP-CLAW Web Search

ESP-Claw kann optional über Brave Search oder Tavily im Internet recherchieren. Beide benötigen API-Keys von externen Anbietern. Da mein Ziel maximale Souveränität ist, lasse ich die Felder erst einmal leer das bricht mit meinem Grundsatz weniger als das LLM selbst, da die Web-Suche ja ohnehin Daten an Dritte sendet.

Vielleicht baue ich später eine eigene Brücke zu einer lokalen Suchmaschine wie SearXNG ein. Für den Anfang reicht es mir aber, wenn mein Agent das nutzt, was Qwen 3.6 35B aus seinem Wissen heraus weiß und sich aus der Memory-Datei erinnert.

Mein persönliches Fazit zu Teil 4

Dies ist der Beitrag, in dem aus drei Teilen Vorbereitung endlich ein funktionierender, lokaler KI-Agent geworden ist. Drei Erkenntnisse nehme ich aus dieser Phase mit:

1. Bei der Erstkonfiguration kein Android-Smartphone verwenden. Der „intelligente Netzwerkwechsel“ ist hier euer Feind. Greift gleich zum PC oder Laptop und ihr spart euch viel Frust.
2. Die OpenAI-kompatible API von Ollama macht die Anbindung trivial, wenn man weiß, welche Felder gefüllt werden müssen. Vor allem das /v1 in der URL, der exakte Modellname und das max_tokens-Feld waren wichtig.
3. ESP-Claw ist erstaunlich vollständig. Capabilities, Lua-Module, Memory-System, Web-UI – alles direkt auf einem 16 MB Flash. Das ist ein Niveau an Software-Engineering, das ich auf einem Mikrocontroller nicht erwartet hätte.

Mit dem ersten Chat ist das Fundament gelegt. Mein ESP-Claw redet mit meinem eigenen LLM, läuft komplett lokal und ist bereit für die spannenden Erweiterungen, die jetzt folgen.

Im nächsten Teil tauche ich tiefer in die Architektur ein: Was sind Capabilities und Skills im Detail? Wie unterscheiden sie sich? Und wie funktioniert das Zusammenspiel zwischen LLM, Lua-Runtime und Hardware? Genau dieses Verständnis brauche ich, bevor ich meine eigenen Skills schreibe um mein Roboter-Auto zu steuern.

Wir lesen uns im nächsten Teil!

Was kommt in den nächsten Beiträgen?

• Teil 1: Auftakt und Vorstellung der Vision
• Teil 2: ESP-IDF v5.5.4 einrichten und ESP-Claw bauen – Schritt für Schritt
• Teil 3: Ein neues Board zu ESP-Claw hinzufügen – meine Board-Adaption für das Guition JC1060P470
• Teil 4 (dieser Beitrag): ESP-Claw mit dem eigenen Ollama-Server verbinden – Konfiguration und erste Chats
• Teil 5: Capabilities und Skills verstehen – die Architektur eines ESP-Claw-Agenten
• Teil 6: Eine eigene Skill schreiben – das Roboter-Auto fernsteuern oder den Geschirrspühler erklären
• Teil 7: Sprache rein, Sprache raus – das HMI-Board als echter Voice-Assistant zur Unterstützung an der Waschmaschine
• Teil 8: Lua-Skripte für Verhaltensmuster – wenn der Agent eigenständig handelt