The idea
A three-sensor kit and a small piece of software that logs temperature and humidity in a rented home all winter, then prints a report. Not a dashboard — a document. It says how many hours the bedroom sat below 18°C, how often the bathroom wall was cold enough for condensation, and how all of that compares to the outdoor temperature on the same days. The hardware is commodity; the product is the report and the arithmetic behind it.
Why build this
Tenants arguing about damp, cold, or a broken heating system have no record. The landlord says the flat is fine, the tenant says it is 14°C in the morning, and the dispute collapses into opinion. Housing officers, environmental health teams, and small-claims adjudicators want dated measurements, and nobody has them because logging a whole winter by hand is unrealistic.
Two things make this buildable now. BLE temperature-humidity sensors cost under £10 and run a year on a coin cell, with open firmware that broadcasts readings in the clear. And damp enforcement has teeth — the UK's Awaab's Law and similar rules elsewhere put deadlines on landlords once a hazard is reported, which only matters if the tenant can show the hazard existed.
Stack sketch
- Sensors: Xiaomi LYWSD03MMC units reflashed with pvvx/ATC firmware, which broadcasts temperature, humidity, battery, and a packet counter over BLE advertisements — no pairing, no app.
- Gateway: a Raspberry Pi Zero 2 W running Theengs Gateway, publishing decoded readings to a local Mosquitto broker.
- Store: SQLite via a small Python subscriber. One row per reading, sensor id, UTC timestamp, raw values. Append-only, never edited.
- Analysis: pandas for resampling and gap handling; dew point by the Magnus formula; surface-condensation risk from indoor dew point against an estimated wall temperature.
- Outdoor baseline: Open-Meteo's historical hourly API, pulled by latitude and longitude, so indoor readings are judged against the actual weather.
- Report: Jinja2 to HTML, WeasyPrint to PDF, matplotlib for the per-room charts.
- Local UI: a single FastAPI page showing sensors online, battery level, and gap warnings.
Scope for v1
In: flashing instructions for one sensor model, a gateway image, a log daemon, and a report --from --to command that writes a PDF with a methodology page, per-room charts, an hours-below-threshold table, a condensation-risk count, and an outdoor comparison. Data-gap handling is explicit — missing hours are shown as gaps, not interpolated.
Out: cloud accounts, multi-property support, mobile apps, push alerts, any claim about mould species or health outcomes, and sensor models beyond the one you tested.
Where it could go
The obvious second audience is the other side of the dispute. Housing associations already get complaints they cannot triage; a fleet version that puts sensors in the fifty worst-reported flats and ranks them by measured risk is a procurement conversation rather than a side project. Same codebase, different front end.
A tenant union is the other direction. Aggregate reports across a single block turn individual complaints into a building-level pattern, which is the thing that actually moves a landlord. That needs consent handling and address-level anonymisation, so treat it as a deliberate second product rather than a feature flag. A mail-out rental kit — pre-flashed sensors, a prepaid return box, a report at the end — is the version that reaches people who will never flash firmware.
Watch out for
The evidentiary weight is the whole product, and uncalibrated consumer sensors undermine it: publish the sensor's stated accuracy, log clock sync, and ship a one-page placement guide, because a probe above a radiator or in afternoon sun invalidates the dataset. Be careful never to state a causal link between the readings and anyone's health — report the measurements and the recognised thresholds, and let the professionals draw conclusions.