Wie JBlanked Flipper Zero, Cardputer und PicoCalc mithilfe von ZimaBoard 2 mit lokaler KI verbindet

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

How JBlanked Connects Flipper Zero, Cardputer, and PicoCalc to Local AI with ZimaBoard 2 - Zima Store Online

Vielen Dank an JBlanked für die Dokumentation einer anderen Möglichkeit, lokale KI in die Entwicklung eingebetteter Geräte zu integrieren. In seinem vollständigen Video verwandelt er das ZimaBoard 2 in einen lokalen Ollama-Server und verbindet Handheld-Geräte wie Cardputer-ADV, PicoCalc und Flipper Zero mit dieser gemeinsamen KI-Umgebung.

Anstatt zu versuchen, ein großes Sprachmodell direkt auf jedem kleinen Gerät auszuführen, teilt das Experiment die Arbeitslast auf: Das ZimaBoard 2 übernimmt den lokalen KI-Dienst, während die Handhelds als schlanke Entwicklungsschnittstellen dienen. JBlanked verwendet anschließend seinen Open-Source-Picoware-Agenten, um Anwendungen zu erstellen, Geräteinformationen zu prüfen und Hardware über diese lokale KI-Verbindung zu verwalten.

Hinweis zur Zusammenarbeit: Dieser Artikel basiert auf dem von JBlanked demonstrierten Setup und der öffentlichen Dokumentation zu Picoware und FlipperHTTP. Softwareversionen, die Verfügbarkeit von KI-Modellen, die Hardwarekompatibilität und die lokale Inferenzleistung können sich im Laufe der Zeit ändern.

Das Ergebnis: Ein kompakter Heimserver kann die KI-Schicht für mehrere ressourcenbeschränkte Maker-Geräte bereitstellen. Die Handheld-Hardware führt weiterhin ihre eigene Firmware und Benutzeroberfläche aus, während rechenintensivere Aufgaben mit Sprachmodellen von Ollama auf dem lokalen Server übernommen werden können.

Die lokale KI-Einrichtung auf einen Blick

Das Projekt kombiniert einen kompakten x86-Server mit mehreren eingebetteten Plattformen. Anstatt jedem Gerät denselben Software-Stack aufzuzwingen, verwendet JBlanked je nach den unterstützten Funktionen der einzelnen Geräte unterschiedliche Verbindungsschichten.

Komponente	Rolle im Setup	Wichtige Überlegung
ZimaBoard 2	Dient als zentraler lokaler Server, auf dem ZimaOS und die KI-Umgebung ausgeführt werden.	Die Modellleistung hängt von der vollständigen Hardwarekonfiguration ab, nicht nur von der CPU des Boards.
ZimaOS	Stellt die Serverumgebung und den App Store bereit, über den Ollama bereitgestellt wird.	Vor der Verwendung des Servers für sensible Projekte sollten die Anwendungskonfiguration und der Netzwerkzugriff überprüft werden.
Ollama	Führt das Sprachmodell lokal aus und beantwortet Anfragen verbundener Geräte.	Verschiedene Modelle haben unterschiedliche Anforderungen an Speicher, Datenspeicher und Beschleuniger.
NVIDIA GeForce RTX 3060	Wird in der demonstrierten ZimaOS-Umgebung als verfügbare GPU mit 12 GB VRAM angezeigt.	Die im Video gezeigte GPU ist Bestandteil der demonstrierten Konfiguration und sollte bei der Bewertung der Inferenz-Ergebnisse berücksichtigt werden.
Cardputer-ADV	Führt Picoware aus und verwendet die Agent-Oberfläche zur Kommunikation mit dem lokalen KI-Server.	Das Handheld bleibt die Benutzeroberfläche; das Sprachmodell selbst läuft auf dem Server.
PicoCalc	Verwendet Picoware als weiteren Client für denselben lokalen KI-Workflow.	Die verfügbaren Funktionen hängen vom aktuellen Picoware-Build und der Gerätekonfiguration ab.
Flipper Zero	Verwendet einen Netzwerk-Anfragepfad zur Kommunikation mit dem lokalen KI-Dienst.	Für die Netzwerkkommunikation ist eine kompatible WLAN-fähige Bridge oder ein entsprechendes Entwicklungsboard erforderlich.

Warum das ZimaBoard 2 als KI-Server verwenden?

Das Interessante an diesem Projekt ist nicht einfach, dass das ZimaBoard 2 eine KI-Anwendung ausführen kann. Entscheidend ist, wie das Board die Architektur kleiner Embedded-Projekte verändert.

Geräte wie Cardputer, PicoCalc und Flipper Zero sind auf Portabilität und spezialisierte Embedded-Hardware ausgelegt. Sie eignen sich für Benutzeroberflächen, Skripte, Firmware-Experimente, Netzwerktools und portable Anwendungen, ihre integrierten Ressourcen sind jedoch deutlich begrenzter als die eines herkömmlichen KI-Arbeitsplatzes.

Der ZimaBoard 2 Mini-Home-Server stellt einen separaten x86-Host mit kabelgebundener Netzwerkverbindung, Speicheranbindung und PCIe-Erweiterung bereit. Dadurch können die Handheld-Geräte kompakt bleiben, während die anspruchsvollere Serverarbeit an anderer Stelle ausgeführt wird.

Im Workflow von JBlanked führt das ZimaBoard 2 ZimaOS aus, während Ollama den lokalen Sprachmodelldienst bereitstellt. Sobald dieser Dienst im lokalen Netzwerk verfügbar ist, können kompatible Geräte damit kommunizieren, ohne dass jedes Handheld über ausreichend Rechenleistung und Arbeitsspeicher verfügen muss, um das Modell selbst zu hosten.

Das Video zeigt außerdem ein wichtiges Detail zur demonstrierten Serverkonfiguration: Während Ollama läuft, zeigt das ZimaOS-System-Dashboard eine NVIDIA GeForce RTX 3060 mit 12 GB VRAM an. Die im Demo gezeigte Leistung sollte daher im Kontext eines lokalen Servers mit GPU und nicht als Test eines CPU-basierten ZimaBoard 2 betrachtet werden.

Ollama läuft in ZimaOS; im System-Dashboard sind eine NVIDIA GeForce RTX 3060 und 12 GB VRAM sichtbar.

Ollama läuft innerhalb der ZimaOS-Umgebung. Das dahinter sichtbare System-Dashboard zeigt eine NVIDIA GeForce RTX 3060 und 12 GB VRAM an und verdeutlicht, dass der demonstrierte lokale KI-Server über GPU-Beschleunigung verfügt.

So funktioniert die lokale KI-Verbindung

Das grundlegende Design lässt sich als drei Ebenen verstehen:

Serverebene: ZimaBoard 2 führt ZimaOS aus und hostet Ollama.
Agenten- oder Netzwerkebene: Picoware oder der Netzwerk-Stack des Flippers sendet Anfragen zwischen dem eingebetteten Gerät und dem lokalen Server.
Geräteebene: Cardputer-ADV, PicoCalc oder Flipper Zero stellt die physische Schnittstelle bereit und führt gerätespezifische Aktionen aus.

Diese Trennung ist nützlich, da das Sprachmodell nicht direkt auf jeder Hardware ausgeführt werden muss. Die Firmware jedes Geräts kann die von ihm unterstützten Funktionen bereitstellen, während der Server die Modellfunktionen für die Interpretation von Anfragen oder die Unterstützung bei Entwicklungsaufgaben bereitstellt.

Cardputer-ADV und PicoCalc verwenden Picoware Agent

Das Open-Source-Projekt Picoware von JBlanked ist eine Open-Source-Firmwareumgebung für Cardputer-ADV, PicoCalc, Flipper Zero und weitere Geräte auf Basis von ESP32 oder Raspberry Pi Pico.

Für dieses Experiment ist Picoware Agent die wichtigste Komponente. Der Agent bietet eine von einem LLM unterstützte Schnittstelle mit verschiedenen Betriebskontexten, anstatt nur als generisches Chatfenster zu fungieren.

Zu den dokumentierten Modi gehören ein allgemeiner Chat, ein App Creator zum Erstellen oder Bearbeiten von Picoware-Anwendungen sowie Geräteverwaltungsfunktionen, die mit Informationen und Befehlen arbeiten können. Durch die Verbindung dieser Funktionen mit der Ollama-Instanz auf dem lokalen Server erhält das Handgerät einen KI-gestützten Entwicklungsworkflow, während die Modellverarbeitung vom kleinen Gerät ferngehalten wird.

Flipper Zero sendet Anfragen an den lokalen KI-Server

Der Flipper Zero verwendet ein anderes Interaktionsmuster. Im Video demonstriert JBlanked, wie das Gerät über eine am Flipper angebrachte WLAN-fähige Entwicklungsplatine eine strukturierte Anfrage-Nutzlast für das lokale Modell vorbereitet.

Die auf dem Bildschirm angezeigte Nutzlast enthält ein Modellfeld für qwen3.5:9b. Dies veranschaulicht die Aufgabenteilung deutlich: Der Flipper bereitet die Anfrage vor und sendet sie, während das ausgewählte Sprachmodell auf dem leistungsfähigeren lokalen Server ausgeführt wird.

Flipper Zero gibt eine lokale KI-Anfrage-Nutzlast für das Modell qwen3.5:9b ein, während eine WLAN-Entwicklungsplatine am Gerät angebracht ist

Flipper Zero bereitet eine Anfrage-Nutzlast für den lokalen KI-Dienst vor. Auf dem Bildschirm ist das Modellfeld auf qwen3.5:9b, während eine WLAN-fähige Entwicklungsplatine oberhalb des Geräts angebracht ist.

Diese Unterscheidung ist wichtig. Der Flipper führt das vollständige Sprachmodell nicht lokal aus. Seine Aufgabe besteht darin, die portable Schnittstelle und den Netzwerkpfad bereitzustellen, während Ollama und das ausgewählte Modell auf dem Server ausgeführt werden.

Was kann der lokale KI-Agent tatsächlich?

Die Verbindung eines Handheld-Geräts mit einem LLM wird interessanter, wenn das Modell mehr kann, als nur eine Frage zu beantworten. JBlanked demonstriert den KI-Server als Teil eines Workflows für die Embedded-Entwicklung.

Picoware-Apps erstellen

Picoware umfasst einen App-Creator-Kontext für seinen KI-Agenten. Damit kann ein Entwickler eine Anwendung oder Änderung in natürlicher Sprache beschreiben und das Modell dabei unterstützen lassen, die entsprechende Picoware-Anwendung zu erstellen oder zu bearbeiten.

In der Demonstration wird der App Creator aufgefordert, eine einfache Anwendung zu erstellen, die beim Start den Gruß „hello from youtube“ anzeigt. Der Agent gibt eine strukturierte Beschreibung des gewünschten Verhaltens und der Funktionsweise der Benutzeroberfläche zurück.

PicoCalc mit Picoware App Creator für eine „hello from youtube“-Anwendung neben Flipper Zero und Cardputer-ADV

Picowares App Creator läuft auf PicoCalc. Der Agent arbeitet an einer Anfrage für eine Anwendung, die „hello from youtube“ anzeigt, während Flipper Zero und Cardputer-ADV neben dem Gerät liegen.

Das kann die Distanz zwischen einer Idee und einem Prototyp verkürzen, insbesondere auf einem Gerät, auf dem das direkte Eingeben und Bearbeiten großer Mengen Quellcode auf dem kleinen Bildschirm sonst umständlich wäre.

Von KI generierter Code muss weiterhin überprüft werden. Eine plausibel wirkende Ausgabe kann falsche APIs, unvollständige Fehlerbehandlung, unsichere Annahmen oder ein Verhalten enthalten, das nicht zur Zielhardware passt.

Firmware- und Entwicklungsinformationen prüfen

Der Agent-Workflow kann auch als Entwicklungsassistent genutzt werden. Statt das Handheld-Gerät als herkömmlichen Chat-Client zu behandeln, kann das System lokale Modellantworten mit den vom Gerät und seiner Firmware bereitgestellten Informationen kombinieren.

Dieser Ansatz ist besonders auf kleinen Displays nützlich, auf denen das manuelle Durchsuchen von Protokollen, Dokumentationen oder Befehlsausgaben länger dauern kann, als den Agenten um die Interpretation einer konkreten Anfrage zu bitten.

Gerät verwalten

Das Agent-Framework von Picoware umfasst außerdem Funktionen zur Geräteverwaltung. Das Modell kann mit den vom Firmware bereitgestellten Tools arbeiten, anstatt dem Benutzer lediglich Text zur manuellen Ausführung zurückzugeben.

In einem Beispiel im Video wird gefragt: „Wie viele Netzwerke befinden sich in der Nähe?“ Die Geräteverwaltung antwortet, dass sechs nahegelegene WLAN-Netzwerke verfügbar sind. Damit wird demonstriert, dass der Agent Geräteinformationen verwenden kann, um eine praktische Anfrage zu beantworten, anstatt sich ausschließlich auf das allgemeine Wissen des Modells zu stützen.

PicoCalc Picoware-Geräteverwaltung meldet sechs nahegelegene WLAN-Netzwerke neben Flipper Zero und Cardputer-ADV

Der Picoware-Gerätemanager auf PicoCalc beantwortet die Frage „Wie viele Netzwerke befinden sich in der Nähe?“. Die Benutzeroberfläche meldet sechs WLAN-Netzwerke in der Nähe und zeigt, wie der Agent lokale KI mit vom Gerät abgerufenen Informationen kombinieren kann.

Hier unterscheidet sich ein KI-Agent von einem normalen Chatbot. Das Sprachmodell liefert die Interpretations- und Anweisungsebene, während die Firmware festlegt, welche Geräteoperationen und Informationsquellen tatsächlich verfügbar sind.

Warum ein gemeinsam genutzter lokaler KI-Server für kleine Geräte nützlich ist

Die Architektur begegnet einem grundlegenden Missverhältnis bei eingebetteten KI-Projekten: Die mobilsten Geräte verfügen häufig über die geringste Rechenleistung für Sprachmodelle.

Ein gemeinsam genutzter Server verändert diesen Kompromiss. Ein Entwickler kann die physische Benutzeroberfläche in einem handtellergroßen Gerät unterbringen und ihm über das Netzwerk Zugriff auf einen leistungsfähigeren lokalen Rechner geben.

KI direkt auf dem Handheld-Gerät ausführen	ZimaBoard 2 als KI-Server verwenden
Die Rechenleistung ist auf den eingebetteten Prozessor begrenzt.	Die KI-Verarbeitung wird auf einen dedizierten x86-Server und die dort verfügbare Beschleuniger-Hardware verlagert.
Die Modellgröße ist durch den Gerätespeicher stark begrenzt.	Der Server kann seinen eigenen Arbeitsspeicher, GPU-VRAM und Speicherplatz für Modelldateien nutzen.
Jedes Gerät benötigt seine eigene KI-Implementierung.	Mehrere Clients können sich einen lokalen Inferenzdienst teilen.
Eine Aktualisierung des Modells kann Änderungen auf jedem Gerät erfordern.	Das Modell kann zentral auf der Serverseite verwaltet werden.
Das Handheld-Gerät muss sowohl die Benutzeroberfläche als auch die Inferenzverarbeitung übernehmen.	Das Handheld-Gerät kann sich auf Benutzeroberfläche, Firmware, Netzwerkfunktionen und gerätespezifische Funktionen konzentrieren.

Ein KI-Backend, mehrere Maker-Geräte

Eine der nützlichsten Erkenntnisse aus JBlankeds Experiment ist, dass ZimaBoard 2 nicht an eine einzelne Frontend-Lösung gebunden ist. PicoCalc und Cardputer-ADV können über Picoware teilnehmen, während Flipper Zero über seinen eigenen Netzwerk-Workflow mit derselben lokalen KI-Umgebung kommunizieren kann.

Dadurch wird der Server zu einem wiederverwendbaren Bestandteil eines größeren Maker-Labors. Statt für jeden neuen Mikrocontroller oder tragbaren Computer eine eigene KI-Umgebung aufzubauen, können Entwickler den Inferenzdienst zentral halten und sich auf die Entwicklung der Client-Integration konzentrieren, die für das jeweilige Gerät sinnvoll ist.

Das Konzept kann auch Experimente vereinfachen. Ein Modell kann auf dem Server geändert werden, ohne das Handheld-Gerät auszutauschen, während sich die Firmware auf dem Handheld unabhängig von der KI-Laufzeitumgebung weiterentwickeln kann.

Was dieses Experiment beweist – und was nicht

Der Build von JBlanked ist eine nützliche Demonstration dafür, wie lokale KI in die Entwicklung eingebetteter Systeme integriert werden kann. Es ist jedoch wichtig, die Architektur von Garantien hinsichtlich Leistung oder Sicherheit zu unterscheiden.

Das Experiment demonstriert	Es garantiert nicht
ZimaBoard 2 kann als lokaler Ollama-Host für Clients auf Embedded-Geräten dienen.	Ohne die in der gezeigten Umgebung vorhandene GPU wird dieselbe Leistung erzielt.
Die ZimaOS-Demoumgebung erkennt eine NVIDIA GeForce RTX 3060 mit 12 GB VRAM.	Jedes Modell passt in 12 GB VRAM oder läuft mit derselben Geschwindigkeit.
PicoCalc und Cardputer-ADV können Picoware als Teil eines lokalen KI-Workflows verwenden.	Jede Picoware-Funktion und jedes Modell funktioniert auf allen unterstützten Geräten identisch.
Der Flipper Zero kann über ein netzwerkfähiges Setup strukturierte Anfragen an den lokalen KI-Server senden.	Auf dem Flipper Zero selbst läuft das Sprachmodell.
Ein KI-Agent kann bei der Erstellung von Apps und bei Geräteverwaltungs-Workflows unterstützen.	Von KI generierter Code, Interpretationen oder Befehle sind nicht automatisch korrekt oder sicher.
Ein einzelner lokaler Server kann mehrere Schnittstellen für kleine Geräte unterstützen.	Ein lokales Netzwerk bietet nicht automatisch Authentifizierung, Isolierung oder vollständigen Datenschutz.

Lokal bedeutet nicht null Konfiguration

Der lokale Betrieb von Ollama macht es nicht erforderlich, jede Inferenzanfrage an einen gehosteten Chatbot-Dienst zu senden. Das vollständige System benötigt jedoch weiterhin eine normale Server- und Netzwerkplanung.

Die anfänglichen Modell- und Anwendungspakete müssen installiert werden, die Handheld-Geräte benötigen Netzwerkzugriff auf den Server, und jeder freigegebene Dienst sollte unter Berücksichtigung der vorgesehenen Netzwerkgrenzen konfiguriert werden. Entwickler sollten außerdem genau prüfen, welche Tools ein KI-Agent aufrufen darf, bevor sie Funktionen zur Geräteverwaltung aktivieren.

Auch die Konfiguration des Beschleunigers ist relevant. Die im ZimaOS-Dashboard von JBlanked sichtbare RTX 3060 verfügt über 12 GB VRAM. Daher müssen bei der Modellauswahl weiterhin der verfügbare Grafikspeicher, die Laufzeitunterstützung und die Leistungsanforderungen des vorgesehenen Workloads berücksichtigt werden.

Bei Anwendungsfällen zur Codegenerierung sind Backups oder Versionskontrolle besonders wichtig. Wenn eine KI-gestützte Änderung eine unbrauchbare Anwendung oder Firmware-Konfiguration erzeugt, benötigt der Entwickler einen bekannten funktionierenden Zustand, zu dem er zurückkehren kann.

Für wen ist ein solches Setup interessant?

Diese Architektur ist besonders interessant für Entwickler und Maker, die bereits mit Embedded-Geräten arbeiten, aber mit lokalen LLMs experimentieren möchten, ohne jedes Projekt in eine Integration mit einer Cloud-API zu verwandeln.

Es kann nützlich sein für:

Cardputer- und PicoCalc-Entwickler, die Picoware-Anwendungen erstellen.
Flipper-Zero-Nutzer, die mit netzwerkverbundenen Tools experimentieren.
Embedded-Entwickler, die KI-Unterstützung in der Nähe ihrer Testhardware nutzen möchten.
Homelab-Nutzer, die nach einer weiteren praktischen Aufgabe für einen lokalen Server suchen.
Maker, die mehrere stromsparende Geräte ein gemeinsames KI-Backend nutzen lassen möchten.

Ein Cloud-KI-Dienst kann für Nutzer, die nur gelegentlich chatten oder Code generieren möchten und keinen Server verwalten wollen, weiterhin die einfachere Lösung sein. Eine größere Workstation oder ein leistungsfähigeres System mit GPU kann ebenfalls geeigneter sein, wenn Modellgröße und Inferenzgeschwindigkeit die wichtigsten Prioritäten sind.

Der ZimaBoard-2-Ansatz wird noch überzeugender, wenn das Ziel darin besteht, den KI-Dienst im selben Homelab zu betreiben und ihn mehreren unabhängigen Projekten bereitzustellen.

Baue einen lokalen KI-Hub für dein Maker-Labor

Das Projekt von JBlanked zeigt eine interessante Richtung für lokale KI: Statt zu fragen, ob jedes kleine Gerät ein Sprachmodell ausführen kann, sollte man fragen, ob diese Geräte ein gemeinsam genutztes Modell verwenden können, das an einem dafür besser geeigneten Ort läuft.

Wenn ZimaOS Ollama auf dem ZimaBoard 2 hostet, Picoware eine KI-gestützte Schnittstelle für Geräte wie PicoCalc und Cardputer-ADV bereitstellt und ein netzwerkfähiger Workflow den Flipper Zero in dieselbe Umgebung einbindet, wird das System zu einem flexiblen lokalen KI-Hub für eingebettete Experimente.

Die vier Demonstrationen zeigen außerdem, warum der Server als vollständiges System bewertet werden sollte. Die Handheld-Geräte stellen die Schnittstellen und hardwarespezifischen Funktionen bereit, Ollama liefert die Modell-Serving-Schicht, und die in ZimaOS sichtbare GPU stellt zusätzliche Rechenressourcen für den lokalen KI-Workload bereit.

Einen weiteren Einblick in die Möglichkeiten lokaler Modelle auf derselben Plattform bietet der Test des lokalen KI-Assistenten auf dem ZimaBoard 2. Er untersucht den Zusammenhang zwischen kompakter Serverhardware, Modellgröße, Speicher und KI-Workloads.

Sieh dir JBlankeds vollständiges Video an, um das Setup und den Geräte-Workflow direkt zu sehen, oder erkunde das Picoware-Projekt auf GitHub, wenn du verstehen möchtest, wie der Agent und die unterstützten Geräte zusammenspielen.

Möchtest du sehen, was andere Entwickler mit kompakten Servern, lokaler KI und ungewöhnlicher Hardware machen? Tritt der ZimaSpace-Discord-Community bei, um weitere Builds zu entdecken, Setups zu vergleichen und deine eigenen Experimente zu teilen.