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
dev-00 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 on a short interval: temperature in °C and relative humidity in %.
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. The first physical unit is the second time each of those paths runs, not the first. Directive 01 holds that the record does not run ahead of the facts. The synthetic instrument 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.