I saw these terminal-style cases at todays maker faire in Hannover. But staff at this booth was pretty busy so I didn’t ask them for the model name. The booth itself just used them, but wasn't about hardware, but coding for kids.

I tried ChatGPT, Google Image search but both just haluzinate about cases.

I have absolutely zero usecase. But I like it and I want one.

I built a camera in the shape of a Mamiya RZ67 that runs vision-language models completely offline on a Pi 5. Press the shutter, and it answers your custom prompt with a single sentence about what it sees. No internet, no cloud, no API keys.

GitHub: https://github.com/feeeeely/ai-camera

You can swap between models on the device itself and compare how differently they describe the same scene: Qwen3-VL (2B), MiniCPM-V 4.6 (1B), InternVL3.5 (2B), SmolVLM2 (2.2B), Moondream 2 (2B) and Ministral 3 (3B) turning the description into the final sentence. The prompt is editable on the touchscreen, so the same camera can do dry one-liners, museum labels or plain inventory notes.

After each shot it shows total time, input→output tokens, tok/s and a vision / generate / load breakdown. The token counts turned out to be the most interesting part: the same photo becomes ~145 image tokens on one encoder and over 1300 on another, which is a bigger factor in latency than the text generation itself.

A few things I learned the hard way:

- Moondream returns sometimes empty responses on current Ollama versions.
- qwen3-vl:2b is a thinking-only variant — it burns the entire token budget on invisible reasoning and returns nothing visible. You need the -instruct tag.
- Ollama can't load separate mmproj files, so a lot of GGUF vision models from HuggingFace simply won't run, no matter how you name them.

Hardware: Raspberry Pi 5 (16 GB), Raspberry Pi HQ camera with a 6 mm CS-mount lens, 4.3" DSI touch display, stainless steel shutter button, Waveshare UPS HAT with four 21700 cells. Runtime per photo is 30–60 seconds with the models kept warm in RAM. Happy to answer questions about the setup.

I'm coming from photography, I'm not a developer — the code was written with heavy AI assistance, and I did the hardware integration, debugging and model testing myself. Feedback on the implementation is very welcome.

Mounted an old Raspberry Pi on the kitchen wall running an app I built to replace our MagicMirror setup that kept breaking. Figured this sub might like seeing a Pi doing something as a real, always-on household fixture instead of a project that gets built once and shelved.
It shows:
• A shared family calendar that syncs with Google, Outlook, and iCloud calendars
• A chore chart the kids can tap to check off on the touchscreen
• Rotating family photos
• Weather, a shopping list, and if you’ve got Home Assistant, it’ll show and control smart home stuff too
It’s a full self-hosted app, runs on the Pi itself, doesn’t depend on a cloud service to keep working. One line install script if you want to try it on a spare Pi you’ve got sitting around (I know most of us have at least one). It’s free to try through the end of the year. I’m not trying to make money off this, just trying to cover the actual costs of keeping it running, not looking to profit. Mainly looking for people to actually run it on real hardware and tell me what’s clunky or broken. If you’ve already got a touchscreen Pi setup or an old tablet to add as a display, it will work with that too!

It’s called PiazzaHQ and you can check it out at piazzahq.com and get your free account.

I had a Raspberry Pi 3 Model B sitting around and wanted to see how viable it still is for running an actual public interactive service.

PI//PLACE

The result is PI//PLACE:

https://place.storix.dev

It is a persistent collaborative pixel canvas where everyone sees and modifies the same board similar in concept to r/place.

The basic idea

• No accounts
• No seasons
• No intentional resets
• One persistent shared canvas
• Placement cooldown
• Live Raspberry Pi telemetry

Hardware

• Raspberry Pi 3 Model B
• 4× Cortex-A53 @ 1.2 GHz
• ~1 GB RAM
• 100 Mbit Ethernet

The canvas backend itself runs on the Pi using Node.js, Express and WebSockets.

The public TLS/reverse proxy is hosted separately, so the Pi is not directly exposed to the internet.

Live telemetry

I also built a small telemetry service that records a sample every 30 seconds into SQLite.

The website shows live:

• CPU usage
• RAM usage
• Temperature
• System load
• Uptime
• Connected users
• Total pixel placements

There is also a "Pi Suffering Archive" where the historical telemetry can be viewed and zoomed over time.

One thing I specifically wanted was proper failure handling: if the Pi stops responding, the homepage telemetry turns red and displays:

>THE PI HAS FALLEN

Instead of continuing to show stale data.

Things I ran into while building it

• WebSocket proxying through nginx/HAProxy
• Keeping the canvas state persistent
• Preventing telemetry polling from unnecessarily hammering the Pi
• Storing long-term telemetry without throwing away the raw data
• Placement cooldown handling
• Keeping the frontend usable on very limited hardware
• Cleaning up vulnerable Node.js dependencies before exposing it publicly

The underlying canvas software is based on the open-source PixiBunny project, which I modified and integrated with the rest of the setup.

At the moment, the Pi is handling it surprisingly well.

Now I mostly want to find out what happens when actual internet traffic starts hitting a Pi 3B with less than 1 GB of usable RAM :D

Feedback on the architecture, telemetry, or additional things worth measuring on the Pi is welcome.

AI disclosure

I used AI assistance during development.

Hi all,

Since 2012, when the Raspberry Pi launched, we've been running Pi and More, a community-driven, not-for-profit event in Germany that brings together Raspberry Pi enthusiasts and anyone interested in electronics, embedded systems and small computers. We originally held two events a year, one in Trier and one elsewhere, but had to scale back after Covid. Our last event was in 2023, and this year we're starting up again.

So consider this an invitation: come and visit us on Saturday, September 26 at Hochschule Trier! And if you're interested, bring a talk, show off your projects, run a workshop, or help us put on the event. We're a small group organized as the non-profit CMD e.V., and we can use all the help we can get.

More information on our website: https://piandmore.de

Happy to answer any questions here!

- Daniel