Skip to content

Stable v2.11.1 MIT RP2040 RP2350

Temperature monitoring that answers to nobody's cloud. Sistema Integrado de Monitoramento Universal e Telemetria

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.

Download firmware Read the manual View the source on GitHub
The SIMUT device dashboard: two sensor cards showing temperature and humidity, above a row of slot buttons.
Device dashboard · captured off a 320×240 panel
16
Sensor slots
4
Sensor types
2
CPU cores used
24/24
OTA updates verified
48.4s
Downtime per update
0
Cloud dependencies

Before you rely on it

  • SIMUT is stable since v2.7.0: the image published with it ran an 8.18 h soak with no reboot and six over-the-air updates with nothing lost. It is tested on real hardware, but it is not a certified metrological instrument. Do not make it the only control on regulated storage without validating it against your own reference. The Air build is still experimental.
  • Over-the-air updates work from v1.6.2-beta onward — and only from there. Every earlier build shipped an applier that reported success and changed nothing, so there is no over-the-air path onto this release. Flash it over USB once; updates work normally after that.
  • An update reformats the filesystem. Wi-Fi credentials, users and sensor slots are carried across automatically; language packs, calib.csv and stored history are not. The update page downloads a backup before it starts — restore it afterwards.
  • There is no second firmware slot to roll back to. The image is checked before it is committed and verified again on the next boot, but recovery from a bad flash is the BOOTSEL button and a USB cable.

This generation

What changed recently

The line left beta in September 2026, on measurements rather than a decision. Since then an update cut off halfway stopped costing the configuration, an update over the air takes only an image the project signed, telemetry no longer loses records when the clock goes back, and the Pico 2 W joined the Pico W, with updates that go back by themselves. Every number below was measured on real hardware.

v2.11.1
Oct 2026

Four high-severity fixes, and no PIN locked out by its own policy

The panel's forced PIN change can no longer be skipped, and its account editor grants only what the account at it holds. A stricter PIN minimum no longer locks shorter PINs out: on the bench, a 4-digit PIN under a minimum of 5 now identifies and goes straight to the change. "Adopt the probe" reads the probe on the slot's own GPIO and reloads: after adopting a swapped probe, 14 of 14 reads were valid in the next 90 s, where v2.11.0 read 0 of 15. The boot gesture's setup access point follows the 15-minute limit, and the Files page says why a Pico 2 W image is refused on a Pico W.

v2.11.0
Oct 2026

The Pico 2 W joins, with an update that comes back by itself

The Pico 2 W (RP2350) gets published images: a factory .uf2 with its partition table, and an update that goes into the slot the board did not boot from, leaving the file system alone. The update boots on trial and keeps itself after a healthy minute. On the bench, an image that never became healthy was back on the previous version 338 s after its install, with no hand on the board. A long upload no longer dies when a page of the device is open: the board itself was cutting it at 12 to 15 s, and now the same upload ends. On the alpha, saving the configuration no longer restarts the device: 0 of 30 rounds reset it, where v2.10.0 reset in 6.

v2.10.0
Oct 2026

Telemetry that loses nothing when the clock goes back, and accounts without a restart

The telemetry cursor is now where a record was written, not its timestamp: with the clock ahead and then put back, the code before sent 0 of 7 records written after the change, and this release sends all 7. Saving accounts no longer restarts the device, and a session ends with its account. The configuration page's dry run no longer mutes the device or changes its time zone, a restore cut off halfway keeps the files it finished, and an alarm limit that is not a number is refused instead of becoming 0. Text files open organized on the Files page, and the telemetry previews are built from the device itself.

Full changelog · Português

Capabilities

What the firmware does

Everything below runs on the device. Nothing phones home.

Dual-core by design

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.

Touch dashboard

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.

Its own web interface

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.

Sixteen universal slots

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.

Passwords done properly

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.

Telemetry that survives the network

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.

It records locally first

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.

Wi-Fi that reconnects itself

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.

Audit trail

A persistent binary log with rotation and CSV export, recording configuration changes, security events and crash forensics captured through the watchdog.

Backup and restore

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.

Three languages

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.

It can run on a battery

The Air build has no display and sleeps between readings: 9.31 s awake, 51 s asleep, the radio off unless there is a batch worth sending. The reading is written to flash first, so a network that is down costs nothing but a delay.

Network on your terms

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

The SIMUT web dashboard in a browser: system statistics, memory and flash usage, and a table of five live sensors of three different types.
Web dashboard · served by the device itself, no cloud in the path
The SIMUT touch interface cycling through its screens.
Device UI · frames read back off the panel
The SIMUT development bench: a Pico W, TFT display and sensors wired on a breadboard.
Development bench · running firmware

Every screen

The whole interface, on a 320×240 panel

Captured off a running device, one frame per screen. Not renderings — the framebuffer read back over SPI.

Dashboard
PIN entry
Settings
Themes
Alarm limits
Threshold editor
On-screen keyboard
Language
System status
Display alignment
Touch calibration
License

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

The sensors do not run on the processor

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.

Five PIO libraries, written for this

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.

Why it matters here

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.

Flash writes stop the display core

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.

A watchdog with forensics

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

Universal is the point, not a feature

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.

The sensor configuration page: a GP0 to GP15 pin map and a table of five slots holding DS18B20, DHT22 and BMP280 sensors.
Five slots · three sensor types · one model

Hardware

What you need

Roughly the cost of a takeaway meal, and none of it is proprietary.

PartSpecification
MicrocontrollerRaspberry Pi Pico W — RP2040, dual-core Cortex-M0+, 2 MB flash
DisplayILI9341 320×240 TFT over SPI
TouchXPT2046 resistive panel
Sensors16 slots on GPIO0–GPIO15: DS18B20 (1-Wire), DHT22, BME280 and BMP280 (I²C)
BuzzerPassive piezo, driven from PIO
StorageOn-chip flash — 1 MB filesystem, 1020 KB application slot
Firmware size1,011,244 B — ~97% of the application slot

Wiring diagram and pinout →

Get started

From parts to readings

Build the hardware

Wire the display, touch panel and sensors to the Pico W following the wiring guide. A breadboard is enough to start.

Download the firmware

Take the image for your board from the latest release: simut_vX.Y.Z_release.uf2 for the touch panel, _alpha.uf2 for the 16×2 LCD, _air.uf2 for the headless battery logger. The matching .bin files are for over-the-air updates. To leave a feature out, or add one, assemble your own in the build configurator.

Flash over USB

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.

Join it to your network

Open the setup access point, simut_SETUP, with ap on the USB console or from the panel's Settings → 8: it opens only when asked. Its key is in the reply to ap and on the panel, and the portal is at http://192.168.4.1. The admin password is printed once on the USB console at first boot — write it down; the first web login asks you to change it.

Open the interface

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

Read further

User manual

Hardware setup, the display, the web interface, the serial console, and troubleshooting.

Wiring guide

Pinout, assembly notes and the reference breadboard layout.

Updating over the air

How to stage and apply a firmware update from the web interface or with curl.

Recovery

Getting a board back after a failed update, and what BOOTSEL rescue involves.

Glossary

The terms used across the interface and the documentation, defined once.

Security policy

Threat model, how credentials are handled, and how to report a vulnerability.

Complete manual, in Portuguese

Thirty-one chapters for v2.11.1: installation, configuration, daily use and server integration. Screenshots are being recaptured.

Contributing

It is open source

Bug reports from real deployments are the most useful thing you can send — especially the ones with a log attached.

Report a bug Request a feature Read the contributing guide Report a vulnerability