The first thing to report to the telemetry service is not a sensor in a room. It is a program on the desk. Before any board is flashed, a synthetic device stands up, onboards through the same provisioning flow as hardware, and posts readings on an interval — so the service has a producer to receive, the readout has something to show, and the failure modes are rehearsed where they are cheap to fix.
Unit
sim-01 is a software producer — the simdev emulator — running on the laptop. It is not a
mock: it authenticates with a real key, validates TLS against the local root, and posts over
the same Authorization: Bearer path a microcontroller will use. The only difference from
hardware is that nothing rusts when it fails. It reports two measures — temperature in °C
and relative humidity in % — on a short interval.
Why synthetic first
A device debugged in the field is debugged at the worst possible time. A synthetic one is debugged on demand, at the desk, against the live service — the auth handshake, the key rotation, the reconnect after a dropped link — so the first physical unit is the second time each of those paths has run, not the first. Directive 01 holds that the record does not run ahead of the facts; the synthetic subject is the first fact.
Readout
The unit reports continuously, and the panel below reads it live: each new sample reaches the browser in under two seconds over a Server-Sent Events stream. The page carries no credential — the edge injects the site read key on the keyless read (Directive 01a §B.5).
The stream emits three signals: temperature (°C), humidity (%), and updated
(last-contact time). A physical producer joins later by onboarding the same way and pointing
a readout at its device id.