Beta v2.3.2-beta MIT RP2040
Open-source firmware for the Raspberry Pi Pico W. It reads up to sixteen sensors, draws them on a touch display, serves its own web interface over your LAN, keeps an audit trail, and updates itself over the air — with no account to create and no service to depend on.
calib.csv and stored history are not. Download a backup first.
This generation
Twenty-two releases in six days took the line from 2.2.0 to 2.3.2 — the web server learned HTTPS, the device learned to speak Prometheus, Home Assistant and syslog, and every release was verified on real hardware.
Keep-alive is now on by default — one TLS handshake per session instead of one per request — and the accept path draws from a static pool that is reserved only when HTTPS actually starts, returning the RAM it once cost every configuration. The telemetry batch ceiling rose from 50 to 250 records per upload, and the white flash between dark-themed pages is gone.
The receive buffer now holds a whole TLS record, so uploads stop dying at the fourth kilobyte — language packs and firmware images stage over HTTPS. The browser serialises its dashboard fetches to match the chip's one-at-a-time TLS server, and the HTTPS-to-HTTP cookie trap is detected and explained instead of failing silently.
Three integrations that speak your infrastructure's language: a
Prometheus /metrics endpoint behind the same login lockout,
Home Assistant MQTT Discovery so sensors appear on their own, and the
event log shipped as RFC 5424 syslog over UDP — with a NIL timestamp
before NTP syncs rather than an invented one.
Capabilities
Everything below runs on the device. Nothing phones home.
Core 0 runs sensors, networking, the web server and telemetry. Core 1 does nothing but drive the display, reading lock-free snapshots — so a busy network never stutters the screen.
Live readings, history graphs and settings on a 320×240 TFT, driven by touch.
Design your own colour scheme in the browser: the theme editor logs into the
device, applies a preview and repaints the real panel while you work. Up to
eight live on the filesystem as .thm files.
A complete management UI served straight from the device: live graphs, file
manager, configuration, light and dark themes. Reachable at
simut.local on your LAN.
Any mix of DS18B20, DHT22, BME280 and BMP280 across GPIO0–GPIO15. Slots are interchangeable — none is special, and calibration follows the sensor rather than the position.
SHA-256 with a random 8-byte salt per user and multiple HMAC rounds — never a bare hash. Login uses a server nonce so the password hash is not replayable, and failures back off per IP.
HTTP POST or MQTT, JSON, CSV or your own template, TLS on both. Readings are batched out of history behind a cursor, so an outage queues rather than loses — and retries escalate on an exponential backoff.
Every reading lands in a compact binary file on the device before anything is sent anywhere. Browse it on the display or in the browser, export it as CSV, and keep it if you never configure an endpoint at all.
Disconnections retry on a backoff that widens to two minutes rather than hammering the access point, and the buffer pool and send aborts are counted so a marginal link is visible instead of merely felt.
A persistent binary log with rotation and CSV export, recording configuration changes, security events and crash forensics captured through the watchdog.
Download the whole filesystem as a single .bkp, verified by CRC32
and bound to the chip ID so an image cannot be restored onto the wrong board.
English, Portuguese and Spanish — on the display, the web interface and the CLI help. All of it loads from language packs on the filesystem rather than being compiled in, so a translation is edited without a rebuild.
DHCP or a static address, your own DNS and NTP servers, and an mDNS name so you do not have to memorise an IP. That name costs 15,272 B of flash — measured, and removable in one flag.
In use
Every screen
Captured off a running device, one frame per screen. Not renderings — the framebuffer read back over SPI.
History graphs, statistics and the calendar are in the animation above — they need stored readings to draw, and this device had just been reflashed. Full map, including how each screen is reached: screens.md.
Under the hood
Every sensor bus and the buzzer are driven by the RP2040's PIO — programmable state machines that clock a protocol in hardware while both CPU cores get on with something else.
1-Wire, DHT22, I²C and the buzzer each have a hand-written PIO program rather than a bit-banged loop. They are separate open-source libraries by the same author, pinned by commit or tag in the build and still being updated.
A bit-banged 1-Wire read blocks a core for milliseconds at a time and breaks if an interrupt lands mid-bit. In PIO the timing is the state machine's problem, which is what lets one core serve the network while the other never drops a frame.
Erasing flash while the other core is fetching instructions from it hangs the chip. Every write is wrapped in a guard that parks Core 1 first — a rule the project learned by debugging the reboots that came from breaking it.
If a core stops answering, the device reboots itself and writes down what it was doing: which core, which module, and for how long. The next boot reports the autopsy instead of coming up blank.
The PIO libraries: OneWirePIO · DHT22PIO · TwoWirePIO · BMx280PIO · BuzzerPIO
The direction
SIMUT is being generalised release over release, and the work is mostly deletion: every version removes a special case that only existed because something was hardcoded once.
There is no ambient sensor, no privileged pin and no reserved slot. Sixteen positions on GPIO0–GPIO15 each take any supported part, in any combination, and each is identified by the sensor's own hardware ID — so calibration, alarms and history follow the device you actually wired, not the position you happened to wire it into.
The capture below is a real device: two DS18B20 probes, two DHT22s and a BMP280, reporting temperature, humidity and pressure through one model. Adding a part is a driver and an entry in a type list. It is not a new special case, and that is the whole design goal.
Hardware
Roughly the cost of a takeaway meal, and none of it is proprietary.
| Part | Specification |
|---|---|
| Microcontroller | Raspberry Pi Pico W — RP2040, dual-core Cortex-M0+, 2 MB flash |
| Display | ILI9341 320×240 TFT over SPI |
| Touch | XPT2046 resistive panel |
| Sensors | 16 slots on GPIO0–GPIO15: DS18B20 (1-Wire), DHT22, BME280 and BMP280 (I²C) |
| Buzzer | Passive piezo, driven from PIO |
| Storage | On-chip flash — 1 MB filesystem, 1020 KB application slot |
| Firmware size | 1,011,244 B — ~97% of the application slot |
Get started
Wire the display, touch panel and sensors to the Pico W following the wiring guide. A breadboard is enough to start.
Take simut_v2.3.4.uf2 from the latest release. Arduino IDE and PlatformIO source trees are published alongside it.
Hold BOOTSEL while connecting the Pico, then drop the .uf2 onto the RPI-RP2 drive that appears. The board reboots into SIMUT on its own.
Configure Wi-Fi from the touch display. The admin password is printed once over USB serial on first boot — write it down, and change it at first web login.
Browse to http://simut.local — or https:// once you upload a certificate — add your sensors to slots, set alarm thresholds, and calibrate against a reference if the readings matter.
Documentation
Hardware setup, the display, the web interface, the serial console, and troubleshooting.
Pinout, assembly notes and the reference breadboard layout.
How to stage and apply a firmware update from the web interface or with curl.
Getting a board back after a failed update, and what BOOTSEL rescue involves.
The terms used across the interface and the documentation, defined once.
Threat model, how credentials are handled, and how to report a vulnerability.
Contributing
Which is a good combination if you like finding things. Bug reports from real deployments are the most useful thing you can send — especially the ones with a log attached.