How it works
A water loop, a heat pump, and a strict division of labour.
Water runs through a thin mat on your mattress. A thermal module next to the bed cools or warms it with Peltier modules. A small control board keeps it within fixed limits, and a hub runs your schedule and talks to Home Assistant. Everything is designed and tested in software; nothing has been built yet.
Overview
The water loop
- Mat. A thin water mat lies on your mattress, one zone per side.
- Thermal module. Peltier modules move heat into or out of the water. A pump circulates it.
- Control board. A Raspberry Pi Pico 2 runs the temperature loop and the safety limits, with a 43 °C ceiling, flow and leak interlocks, and a watchdog.
- Hub. An ESP32 running ESPHome runs your night schedule and connects to Home Assistant. It can only request temperatures.
Thermal module
Peltier modules move heat, both ways.
A Peltier (thermo-electric) module pumps heat from one face to the other when current flows. Clamped between a cold plate that the water runs through and a heatsink with a fan, it cools the water. Reverse the current and it warms the water instead. There is no compressor and no refrigerant: just solid-state modules, a pump and PC-watercooling parts.
Each zone has its own module, so each side of the bed has its own temperature. The kits use three or four standard modules per zone; the thermal model in software/opod sizes them and checks every kit's claims.
- Setpoint range
- 13–43 °C
- Reachable cooling
- depends on the kit and the room: see kits
- Heating to
- 43 °C, the safety cap, for every kit
- Polarity change
- only at zero current, with a dead time
Control vs. hub
The networked part is never the safety part.
Temperature control and limits run on a separate small control MCU, a Raspberry Pi Pico 2 running the project's own Rust firmware. It clamps every setpoint to 13–43 °C, refuses Peltier current without water flow, shuts down on a leak and goes to a safe state when the hub stops sending heartbeats.
The hub (an ESP32 with ESPHome, or a Raspberry Pi) has Wi-Fi, Home Assistant and your schedules. It can only request a temperature. Independent hardware cutoffs back up the firmware even if all software fails.
Protocol
OPL: Open Peltier Link
Hub and control board talk over a small framed serial protocol. The same golden frames test the Python reference, the Rust firmware and the C++ hub component, so all three agree byte for byte. The protocol is ours and open; it is not derived from any vendor's.
Sensing options
Three ways to sense the sleeper
- Load cells under the bed legs: presence and movement, cheapest.
- Pneumatic: an air tube with a pressure sensor under the cover.
- Piezo grid: a 3×3 grid of piezo strips, the best signal for the planned heart-rate and breathing estimates.
All biometrics are planned, not built.
Software
Local-first. No account, no cloud, no subscription.
Your schedule runs on the hub in your home. Biometric data, once it exists, never leaves the house unless you export it.
Home Assistant, natively
The hub is an ESPHome external component. Home Assistant sees a climate entity per zone, water temperature and other sensors, problem and link status, and buttons to prime the loop and clear faults. The hub can also act as a Bluetooth proxy for adjustable bed bases with community integrations.
Status: compiles for ESP32-S3; protocol and schedule host-tested; not yet run on hardware.
Night schedules on the hub
A schedule is a curve: temperatures at minutes after bedtime, with a warm ramp before the wake time. Each side has its own program, the curve lives in your YAML, and a manual change ends the program for the night.
Reference model (Python)
The thermal model, control and safety logic, protocol and schedules, all tested. Every number on this site comes from it or from the repository files.
Firmware (Rust, embassy)
The control firmware core replays the reference model's golden vectors; the Pico 2 build compiles to about 50 KB. Not yet run on hardware: that's a first bring-up waiting for you.
Run it in two minutes, no hardware needed
cd software/opod && uv run pytest -q # reference model, safety logic, kit checks
cd firmware && cargo test # firmware core vs. golden vectorsModules
How the parts fit together
Further reading
The design documents
System architecture
Goals, non-goals, the block diagram and who is responsible for what.
Thermal and fluidics
Peltier sizing, heatsinks, pumps, the mat and the thermal model.
Electrical safety
Power chain, cutoffs, interlocks and why builders never wire mains.
Sensing and biometrics
Load cells, pneumatic and piezo options; BCG on the hub.
Firmware and protocol
The control loop, the TEC driver state machine and OPL frames.
Bed software
Schedules, Home Assistant entities, presets and data ownership.