Palm — connected smart waste bin with cloud fleet ops
Constraint
The box they were trapped in
Palm wanted a connected countertop appliance that holds food waste at controlled temperatures, runs unattended in a kitchen, and can be managed across a fleet of devices from a single dashboard. The hard parts: keep the Peltier (TEC) thermal loop stable while the lid opens and closes, route 12V power around mains-adjacent electronics safely, and ship over-the-air updates without bricking units in the field.
Approach
How we attacked it
ESP32 running a state-machine firmware in C++ on the Arduino framework — driver, service, and application layers kept separate so the thermal loop, the lid sensing, the load-cell weighing, and the MQTT uplink can each fail and recover without taking the others down. Three-board PCB: a main control board for sensors and actuation, a dedicated 12V power board with overcurrent and overvoltage protection, and a daughter board carrying the hall-effect lid sensor. Cloud side is Nest.js (device registry, telemetry processing, command APIs) feeding a Next.js admin portal for fleet ops and a Flutter app for end users. TLS, JWT, and RBAC throughout.
Decisions
What we picked, and what we rejected
Three-board PCB (main + power + daughter)
Single-board would have been cheaper to assemble but mixed the noisy 12V switching rail with the analog sensor frontends and pinned the lid hall sensor far from the magnet. Splitting the boards isolates the rails, keeps the lid sensor on a short trace, and lets us re-spin the power board without re-touching the main board.
Arduino framework over bare ESP-IDF
The Peltier and PWM fan loops are seconds-scale, not hard real-time. Arduino on PlatformIO got us to first thermal regulation faster, and the layered driver/service/application split gave us most of the discipline an RTOS would have without the scheduler overhead.
Nest.js for the cloud, Next.js for the portals
Same TypeScript across device registry, telemetry processing, admin portal, and organization dashboard. Shared types from the MQTT topic schema into the React components — no parallel Python or Go service to keep in sync with the device firmware.
Hall sensor for lid detection over a microswitch
Microswitches wear out, debounce noise leaks into the thermal loop, and the mechanical layout would have forced an awkward bracket. A hall sensor on the daughter board reads a magnet on the lid contactlessly and integrates cleanly into the enclosure.
MQTT over TLS for telemetry, HTTPS for OTA
MQTT keeps the device-side connection lightweight and lets the broker fan messages out to the admin portal without polling. OTA happens infrequently and benefits from HTTPS's straightforward chunked download and resume semantics over a same-protocol MQTT push.
Trade-off
What we didn't build
Three boards instead of one means more harnessing and a longer DFM cycle, but it isolates the noisy 12V rail from the digital control, keeps the lid daughter board close to the magnet without long analog runs, and lets us re-spin the power section without touching the main board. We picked Arduino on top of ESP-IDF over a pure ESP-IDF or Zephyr build — the Peltier loop runs on seconds-scale time constants, so we traded fine-grained RTOS scheduling for faster firmware iteration.
Outcome
What changed after we shipped
Live and shipping at meetpalm.co. Palm runs a fleet of devices through the admin portal; end customers control units from the Flutter app. Production firmware ships OTA over HTTPS, with heartbeat reporting and persistent config so a unit can drop off the network and recover its state on reconnect.
Talk to us
Have a similar project in mind?
Tell us what you're working on. We'll let you know whether it's a fit.