ESP-Mosaico: a small screen for a bigger system

I’m building around a simple idea: a small piece of hardware should make a large AI system easier to understand.

I’m treating the desk, markets, and voice modes as one interface experiment. The useful distinction here is between prepared software and physical-device tests that still need evidence.

ESP-Mosaico is the hardware board at the centre of this experiment. The custom experience has three parts: a desk view for useful status, a markets view for readable snapshots, and a voice bot with visible listening and playback states. This is a work in progress, with physical-device validation still to be documented.

01 / The desk

The desk view is the quiet default. It should answer a small question at a glance: what is happening, and does it need me? The design direction is a compact status display with room for a clock, a timer, and signals from a companion computer. Each integration needs its own working connection before it can become a reliable part of the desk.

02 / The markets view

The markets mode is designed for read-only prices and position summaries. The important information is not just the number. It is the instrument, the source, and the time of the last successful update. A disconnected feed should look disconnected; yesterday’s number should never masquerade as a live one.

This notebook does not claim a live market-data connection or an order-execution system. The next useful test is deliberately boring: disconnect the feed and check that the screen tells the truth.

03 / The voice bot

The voice path splits the job between the board and a companion computer. The board provides the face and physical interaction; the companion handles the heavier model and service work. The intended loop is microphone → speech recognition → model response → speech playback, with visible mute, listening, thinking, and speaking states.

The prepared firmware interface includes Setup and Voice modes, an animated face, playback-driven mouth movement, and a microphone mute control that starts muted. A successful build is only one checkpoint: it does not establish that physical USB audio, installation, or recovery works.

What the work has taught me

1. Make state visible. “Thinking” and “not connected” need different faces. A friendly animation cannot replace an honest status.
2. Test the missing-device path. An installer should remain cautious when no board is detected. That path matters before any successful installation.
3. Keep heavy inference off the board. Treat the hardware as an interface to the larger system. Choose where computation happens deliberately.
4. Recovery is part of the build. A route back to a known state deserves the same attention as a new feature.

Where it stands

Firmware and companion preparation have been reported through host-side checks. No physical board installation, USB audio round trip, or recovery result is claimed here. The desk and markets integrations remain development directions until their device tests are recorded.

The next log should contain evidence: the actual setup, what passed, what failed, and what changed. More AI and Mosaico experiments will join this notebook as the work develops.