Server Dashboard

What’s new

Put together a live demo mode so anyone reviewing the project doesn’t have
to set up Mosquitto or flash a Pico just to click around. The whole thing
runs on Render’s free tier. Every visitor gets their own isolated in-memory
SQLite seeded with demo MCUs, a DHT11 sensor, 24 hours of backfilled
readings, and a per-session ticker that generates simulated data every 10
seconds. MQTT, Wake-on-LAN and shell command execution are all mocked.

The session isolation was the part I was most worried about. The db module
is imported from 15+ files and I really didn’t want to refactor all of
them. Ended up wrapping everything in AsyncLocalStorage and putting a Proxy
over the db export, so every request transparently hits its own session’s
database without any of the callers knowing. Socket.io broadcasts are
scoped to per-session rooms so visitors never see each other’s data.

Got bitten by Linux case sensitivity on the first deploy (mcuRepository.js
vs MCURepository imports). Worked fine on Windows, crashed immediately
on Render. Also ran into a template literal syntax bug where \" inside a
${} interpolation silently broke the whole MCU detail page, but only in
production. That one took a while to find.

Added an English landing page at / that explains what the project does
and embeds a YouTube link for the hardware demo video. Included a
render.yaml blueprint so forking and deploying is basically one click.

Used Claude Code a lot for the AsyncLocalStorage architecture and the
Render-specific gotchas I wouldn’t have known to look for. Wiring and
testing was still on me, which is where most of the time went anyway.

Devlog — v1.1.0

Spent some time this sprint polishing things that were bugging me for a while.

Biggest addition is the multilingual UI — the app now supports Czech and English,
switchable from settings. Took some work to get event logs and server-side error
messages translating properly since those come from the DB and backend, not just
the frontend templates.

Also shipped the Linux server agent startup script (StartLinuxScript.sh) —
it handles venv creation, dependency install and launches the executor
automatically. Debugging WSL networking was a pain.

Fixed some sneaky JS syntax errors (mixing || and ?? without parens) that crept
in with the i18n commit and broke the frontend silently.

Used Claude Code pretty heavily for the i18n architecture and debugging — good for
bouncing ideas and catching things I’d miss at 1am. Still had to do all the
actual wiring and testing myself, which is where most of the time went.

Small things: data/ directory now committed via .gitkeep, docs updated in both
languages.

This update focuses on making the project easier to test without physical hardware. I added startup scripts for both Windows and Linux that automatically handle dependencies and launch the dashboard. The virtual Pico simulator now has a configurable .env file so the broker IP, API key, and MAC address can be set without touching the code. The README was rewritten with a Quick Start section and reviewer notes explaining what can and can’t be tested without hardware. Released as v1.0.1.

Devlog #3 – Flavortown shipped

Since the last devlog, the project went from a dashboard and a database to a full IoT management platform. My teammate didn’t end up touching the web side, so I built everything myself — with help from Claude Haiku in my IDE early on, and Claude Opus via Claude Code for the later features.

The core is MQTT. Sensor MCUs publish readings to sensor/data with an API key, the server routes values to the right channels, buffers them in memory, and aggregates per-minute AVG/MIN/MAX into SQLite. Channels have configurable thresholds — breach fires an alert event, recovery fires another, no spam.

There are two MCU roles: sensor MCUs collect data and report status (online/passive/offline), deck MCUs are physical Pico W displays that receive config and live values over MQTT and can trigger server commands.

Servers are Linux machines with defined shell commands. A Python agent (debian_executor.py) runs on each, subscribes to its MQTT topic, executes whitelisted commands, and reports back. Wake-on-LAN routes through a Pico on the LAN which sends the UDP magic packet.

MicroPython flashing is handled client-side via the Web Serial API. The server renders a template with placeholders (API key, WiFi, broker IP) and returns the final .py — the browser flashes it directly. Windows + Chrome only.

Rounding it out: session auth with forced password change on first login, per-MCU event log, notifications, and a settings page (timezone, dark mode, ping interval, broker IP with live reconnect).

I spent way more time on this than planned. Shipping it.
Translated with Claude Sonnet 4.6

I have generated a dashboard page for the main content using Gemini PRO. Since then, I have added frontend JavaScript for a simple form that sends a POST request to the server with basic information about the MCU to be added. I have also created a database and further structured my MVC architecture. Regarding models, I added a database entity, a repository to interact directly with the DB, and a service to format and validate the data.

Translated with Gemini

I’ve created my project before knowing about HackClub so I created it here and made basic description. For now its just a basic web created as a middle ware for server script, MCU for collecting user input or data from sensors. For now its just a simple page and I am trying to make communication between all the parts working so I can move to the data collection and their visualisation and storing.