An interface for radio waves
Two people need to know whether a sensor is working. One is at a desk in another state. One is standing next to it in a basement with no laptop.
They will never be in the same room. If they disagree, you get a support ticket that looks like a hardware fault.
So I built one state model and drew it twice. A dashboard for the desk, and a language of blinking lights for the basement.
How it breaks
A sensor sits on a pipe and reports through a line of battery-powered relays to a box in the basement.
Nothing is plugged in. It has to run for ten years untouched.
When a relay dies it doesn’t say so. Six sensors go quiet in six apartments. It looks like six problems and it’s one.
My role
I designed the network screens and the on-device behavior, and wrote front-end code for parts of the dashboard.
Not mine: the radio protocol, the battery scheduling, the hardware. The efficiency numbers this network is known for internally belong to firmware.
The dashboard
I ordered the device list by what depends on what, not by type of device.
Why not group like with like? A list of every relay reads like a parts bin, and a parts bin doesn’t tell you where to look first.
Dependency order puts the basement box on top. If that is down, nothing under it means anything.
Each device shows:
- signal strength
- the route it takes home
- how many of its messages arrive
Then a diagram of the whole path, so you can see who hands off to whom.
That is what turns six mysteries into one relay. The six quiet sensors share a parent, and six phone calls become one truck.
On a phone it shows one relay at a time, with its history. The question is almost never “is this bad.” It is “is this worse than last week.”
The light language
None of that helps in a stairwell. The technician has one LED. That is the whole interface, and honestly it’s the most fun constraint I’ve had.
So I designed four network states in color and blink rhythm, readable at arm’s length in the dark.
I agreed all four with firmware in writing before either of us built anything, because a color that means two things is worse than no color.
Then the part I’d point at. Press LINK and the light gives you signal strength as a color, right where you are about to mount the sensor.
Hold it up, press, read it, then mount it or move a foot left.
That takes about three seconds.
Before it, placement was a guess graded weeks later by somebody reading a dashboard.
A tech would do everything right, drive away, and find out in October that one sensor had been fighting for signal since July.
Fixing that means a return trip. A truck roll costs more than the original two-hour install. Bad placement also means constant retries, and retries are what kill a ten-year battery.
Field ops and I printed both mappings as cards for the truck. Che, one of our techs, is why they are laminated.
A card in a glovebox gets read. A help page doesn’t.
Agree the states, then draw them
“Connected” has to mean the same thing on an LED and in a dashboard row.
So we wrote the vocabulary down with firmware first and drew both surfaces from it. Not the screens first and the list after.
Every multi-surface thing I have worked on since came down to that, and none of them involved radio.
What I got wrong
I never tested the color scale against color-vision deficiency. Red to blue is exactly where that matters.
Roughly one in twelve men has some form of it, and field techs are mostly men.
The fix was already in the design. I had used blink rate as a second channel for network state and knew it worked.
I did not use it for signal, and I do not have a reason.
I’d also push the path diagram further. It draws the topology and still makes you find the shared relay yourself.
The system knows which one it is. I’d rather it just said so.