esp32-eye: Der Katzen-Wassernapf-Monitor, der MiniCPM-V 4.7 zweimal aufruft

Zwei ESP32-S3-Boards, ein MacBook und zwei verschieden große Versionen von MiniCPM-V 4.7 führen jetzt Protokoll darüber, welche Katze wann aus dem Wassernapf getrunken hat. Ein Kameraboard überwacht den Napf, ein MacBook führt das kleine Modell lokal aus, um eine eng umrissene Frage zu beantworten, und das große Modell wird erst hinzugezogen, nachdem ein Ereignis bereits eingetreten ist. Das Projekt heißt esp32-eye, ist unter github.com/emwstudio/esp32-eye zu finden und wurde am 25. Oktober 2026 veröffentlicht. OpenBMB stellte es in der ersten Novemberwoche vor, wodurch die meisten darauf aufmerksam wurden.

Das zugrunde liegende Modell ist der Teil, bei dem Präzision angebracht ist. OpenBMB hat MiniCPM-V 4.7 am 6. und 7. Oktober 2026 auf Hugging Face hochgeladen, am 12. Oktober die Modellkarte und die Apache-2.0-Lizenz veröffentlicht und am 15. Oktober eine englischsprachige Pressemitteilung über PR Newswire herausgegeben. Das ist also keine Launch-Story, und der Katzenmonitor ist kein Hersteller-Benchmark. Es ist die detaillierteste öffentliche Bereitstellung des Modells, die jemand außerhalb des Labors bisher dokumentiert hat, und es handelt sich zufällig um ein Haushaltsgerät.

Was der Build tatsächlich macht

Die Hardware ist bewusst günstig und etwas unhandlich. Ein Waveshare ESP32-S3-CAM-OV5640 sitzt auf dem Schüsselrand und streamt 1024×768-JPEG-Frames plus Mikrofon-Audio über Wi-Fi. Ein zweites Board, ein Waveshare ESP32-S3-Touch-AMOLED-2.16, ist das Schreibtischdisplay: ein 480×480-Panel, das einen Live-Videostreifen, vier Katzenkarten, einen Tageszähler gegenüber einem Ziel von acht Drinks und eine kleine Highlight-Animation zeigt, wenn eine Katze bestätigt wird. Das MacBook ist das Gehirn. Ein FastAPI-Server nimmt den Stream entgegen, führt die Erkennungslogik aus, schreibt in SQLite und schneidet für jedes Ereignis einen MP4-Clip mit fünf Sekunden Vorlauf, drei Sekunden Nachlauf und dem Originalton.

Die Platzierung der Kamera ist das Erste, was man verstehen muss, denn sie erklärt das gesamte Erkennungsdesign. Das Objektiv blickt vom Rand des Napfes aus zum Gesicht der Katze nach oben, was bedeutet, dass die Wasseroberfläche nicht im Bild ist. Das System kann keine Katze beim Trinken sehen. Es kann nur eine Katze sehen, die den Napfbereich einnimmt, und den Rest aus Persistenz und Identität ableiten. Jeder, der schon einmal ein Kameraprojekt gebaut hat, weiß, dass hier normalerweise die Ehrlichkeit den Raum verlässt; hier steht es in der README.

Die Pipeline vor dem Lauf eines beliebigen Modells ist eine Graustufen-Hintergrunddifferenz gegen ein Referenzbild einer leeren Schüssel. Liegt der Vordergrundanteil unter 15 Prozent, wird das Bild verworfen, ohne ein neuronales Netz zu berühren. Oberhalb von 15 Prozent wird das lokale MiniCPM-V 4.7 1B mit einer Frage konfrontiert: Ist in diesem Bild eine Katze? Eine positive Antwort plus ein Vordergrundanteil über 35 Prozent werden zu einer Ja-Stimme. Drei aufeinanderfolgende Ja-Stimmen öffnen ein Ereignis; vier aufeinanderfolgende Nein-Stimmen schließen es.

Die Aufteilung in zwei Modelle ist der interessante technische Teil.

Ein Vision-Modell alle 1,5 Sekunden für immer laufen zu lassen, ist eine schlechte Idee, und der Build behandelt es auch so. Das 1B läuft lokal über llama.cpp als Q4_K_M-Quantisierung auf einem OpenAI-kompatiblen llama-server auf Port 8080. Es ist günstig genug, dass sich das Projekt wiederholte Aufrufe leisten kann, aber es wird weiterhin durch die Hintergrunddifferenz begrenzt, sodass ein leerer Raum nichts kostet. Die Aufgabe des 1B ist bewusst eng gefasst: Präsenz, nicht Identität, nicht Verhalten.

Identität ist die teure Frage, und sie wird einmal pro Ereignis gestellt. Wenn ein Ereignis abgeschlossen wird, entnimmt der Server Frames aus dem Clip und schickt sie über ModelBests Cloud-API an MiniCPM-V 4.7 35B-A3B, zusammen mit einem Referenzfoto für jede der vier Katzen. Das große Modell liefert eine Katzen-Kennung, einen Konfidenzwert und ein Ja/Nein dazu, ob die Szene eine Trinkszene ist. Frames, die die Trink-Prüfung nicht bestehen, werden verworfen und nicht gezählt. Mehrdeutige Identitäten werden als unbekannt gespeichert, statt sie der nächstgelegenen Katze zuzuweisen, und wenn der Cloud-Aufruf fehlschlägt, gerät das Ereignis in einen Wiederholungspfad, statt mit der Vermutung des 1B-Modells nachträglich aufgefüllt zu werden.

Diese Arbeitsteilung ist dasselbe Argument, das die On-Device-Literatur seit zwei Jahren vorbringt – jetzt mit Beleg. Ein kleines Modell ist ein Sensor. Ein großes Modell ist ein Richter. Das Kostenmodell folgt direkt daraus: Das 1B-Modell wird in Millisekunden und Batterie bezahlt, das 35B-Modell in Tokens, und die Token-Rechnung skaliert mit der Zahl der Trinkereignisse statt mit der Zahl der Frames. In einem Vier-Katzen-Haushalt sind das eine Handvoll Aufrufe pro Tag.

Was die 89 Ereignisse belegen – und was nicht

Der Beitrag von OpenBMB berichtet, dass in einem Haushalt mit vier Katzen über drei Tage hinweg 89 Trinkereignisse manuell überprüft wurden und jede Katzenidentität korrekt war. Das ist ein echtes Ergebnis und zugleich ein eng begrenztes. Die Identitätsaufgabe ist eine geschlossene Vierfachauswahl unter Katzen, für die das System bereits Referenzfotos hat. Es ist keine Open-Set-Re-Identifikation, keine Aussage über hundert Katzen und keine Behauptung, dass das System in einem Haus funktioniert, das es noch nie gesehen hat.

Neunundachtzig Ereignisse über drei Tage sind grob dreißig pro Tag bei vier Katzen, oder etwa siebeneinhalb pro Katze und Tag, was für eine Studie zur Wasseraufnahme plausibel und viel zu klein ist, um eine Fehlerrate mit irgendeiner Verlässlichkeit zu schätzen. Ein System, das 89 von 89 Malen richtig liegt, könnte trotzdem einmal in fünfzig falsch liegen. Die Zahl, an der man sich festhalten sollte, ist nicht 100 Prozent; es ist, dass niemand es in drei Tagen gewöhnlicher Nutzung korrigieren musste.

Es gibt außerdem einen Vorbehalt bezüglich der Herkunft. Der Autor ist Community-Botschafter bei OpenBMB, und der Showcase lief über OpenBMBs eigenes Konto. Das macht das Ergebnis nicht falsch, bedeutet aber, dass die Validierung nicht von einem Skeptiker entworfen wurde und kein Dritter sie wiederholt hat.

Warum die 1B die Katze nicht identifiziert

Das README enthält den nützlichsten Satz im gesamten Projekt, und es ist ein negatives Ergebnis: Bei drei hellfarbigen Katzen, die sich ähnlich sehen, war das lokale MiniCPM-V 4.7 1B nicht zuverlässig darin, eine von vier auszuwählen. Das Team hat es ausprobiert, die Vierfach-Unterscheidung als unzuverlässig befunden und die Identitätszuordnung lieber auf das 35B verlagert, statt eine Vermutung auszuliefern.

Das lohnt sich, genauer zu betrachten, denn es widerspricht der Art und Weise, wie kleine Vision-Modelle üblicherweise verkauft werden. Ein Modell mit 1,55 Milliarden Parametern, das bei OCR- und Diagramm-Benchmarks gut abschneidet, ist nicht automatisch gut darin, zwei ähnliche Tiere in einer festen Kameraperspektive auseinanderzuhalten. Fein granulare Identität ist genau die Art von Aufgabe, bei der ein komprimiertes visuelles Token-Budget schadet: Die Unterschiede zwischen zwei getigerten Katzen sind klein, lokal und lassen sich leicht wegmitteln. Die Antwort dieses Builds – das kleine Modell für die leichte Frage zu verwenden und für die schwierige zu bezahlen – ist nützlicher als jede Zeile in einem Leaderboard.

Was der Betrieb kostet und was passiert, wenn die Cloud-Teilstrecke ausfällt

Nur ein Teil dieser Pipeline kostet Geld. Das 1B-Modell ist eine lokale GGUF-Datei auf einem Laptop, daher sind die Grenzkosten pro Frame Strom. Das 35B-Modell ist ein gehosteter Aufruf an die API von ModelBest, also an den eigenen Endpunkt des Anbieters statt an einen Drittanbieter-Host, und das Projekt benötigt dafür einen Schlüssel. Die README stellt ausdrücklich klar, dass das 35B-Modell nicht lokal bereitgestellt wird: Das MacBook hält keine 35 Milliarden Parameter, sondern einen Client.

Diese Aufteilung erzeugt einen Fehlermodus, den das Projekt behandelt, statt ihn zu verbergen. Wenn der Cloud-Aufruf fehlschlägt, wird das Ereignis erneut versucht; das 1B-Ergebnis wird nie zu einer Identität erhoben. Für ein Hobbyprojekt ist das ungewöhnlich diszipliniert. Für alles, was Produktionscharakter hat, setzt dasselbe Design einen einzelnen externen Endpunkt auf den kritischen Pfad eines Systems, dessen ganzer Zweck darin besteht, Ereignisse unbeaufsichtigt aufzuzeichnen.

Das ist die Lücke, die ein Router füllt, und es lohnt sich, genau zu sein, was ein Router hier kann und nicht kann. OrcaRouter bietet eine einzige API für mehr als 200 Modelle mit durchgereichtem Listenpreis des Anbieters zu 0 % Aufschlag, plus automatischem Failover zwischen Upstreams, was die richtige Form für eine Pipeline wie diese ist. Derzeit führt er MiniCPM-V 4.7 nicht, daher würde der 35B-Teil in esp32-eye weiterhin über die eigene API des Anbieters laufen. Die ehrliche Version des Rats lautet: Behalte den Retry-Pfad, und wenn der Identitätsschritt tragend wird, stelle ein zweites Modell, das du tatsächlich erreichen kannst, hinter denselben Aufruf.

Was ist noch unbestätigt

Drei Dinge würden daran ändern, wie viel Gewicht dieser Aufbau verdient. Das erste ist ein zweiter Haushalt. Alles, was bisher berichtet wurde, stammt aus einem einzigen Zuhause mit vier bekannten Katzen und einer festen Kamera. Das zweite ist ein längerer Lauf: Drei Tage können nicht zwischen einem System unterscheiden, das funktioniert, und einem System, das funktioniert, bis eine Katze ihr Fell wechselt, sich das Licht ändert oder ein Besucher kommt. Das dritte ist eine unabhängige Prüfung der 89 Ereignisse, die derzeit auf der manuellen Überprüfung durch den Erbauer selbst beruht.

Was bereits etabliert ist, ist bescheidener und nützlicher. MiniCPM-V 4.7 existiert in zwei Größen, die sich kombinieren lassen: ein dichtes 1,55B-Modell, das in einer Q4_K_M-Datei auf einem Laptop läuft, und ein spärliches Mixture-of-Experts-Modell mit 35,2B, das pro Token etwa 3 Milliarden Parameter aktiviert und bei einer Identitätsaufgabe mit vier Möglichkeiten gut genug ist, um damit betraut zu werden. Ein Katzennapf ist ein seltsamer Ort, um das zu beweisen, aber er ist ein echter.

Wenn Sie es reproduzieren möchten, enthält das Repository die Kamera-Firmware, die AMOLED-Firmware, den FastAPI-Server und die Modelltestskripte, und das einzige Konto, das Sie benötigen, ist ein ModelBest-Schlüssel für den Identity-Teil. Wenn Sie das Modell lesen möchten, anstatt die Katze laufen zu lassen, sind die Zahlen des Anbieters der richtige Ausgangspunkt, und die Einschränkungen finden sich im Repo.