Blog · August 7, 2026
Headless: diagnosing a device with no screen and no keyboard once it sits at the customer's site
Two of our series devices have neither a screen nor a keyboard. As long as everything runs, that is not a shortcoming but the right kind of economy. It gets interesting the day a customer calls: "The device stopped working." It sits hundreds of kilometres away, and the entire cockpit is one LED.
Diagnosability is a design decision
The most important lesson from series operation: what a device can tell about itself in the failure case is decided during development — not during the service case. A device designed mute stays mute when it matters. So from the start, the firmware carries the question: how does someone who is not sitting next to it find out what is going on?
Both of our series devices therefore carry all of it: documented LED patterns, the status report over the radio link, a service interface for on-site diagnosis — and the recorded restart cause.
The questions a device must answer remotely
Is it alive — and since when? A device that reports in regularly over the connection it has anyway turns the customer's "stopped working" into a measurement: the last report came three hours ago, and for weeks before that it came on schedule. That narrows the fault down before anyone gets into a car.
Why did it last restart? Microcontrollers know what woke them: a supply dip, the watchdog, power-on. Recording the restart cause and reporting it shows the difference between a power-supply problem, a stuck firmware and a user who switched the device off and on again — three fault patterns, three completely different responses.
How is its energy supply doing? For battery devices, the state of charge is half the diagnosis: a device that "fails sporadically" often simply fails as the battery empties — the radio operations give way first.
And if it cannot reach the network at all? Then the local path is needed: an LED signature with a few documented states — recognisable over the phone, describable by someone who is not a technician. "Does it blink once per second, or three times briefly?" is a question every caller can answer. Nobody can tell twenty blink patterns apart; four are often enough. And if someone qualified does hold it in their hands, there is the service interface: on site, the device tells what it could no longer deliver over the radio link.
What this changes in the service case
The difference is the same as with firmware updates over the air: every question the device answers remotely saves a technician visit or a return shipment — and in the best case it turns out the device is not the problem at all, but its surroundings: the radio coverage, the power supply, the location. That too is a diagnosis, and it cannot be had without measurements from the device.
What about you?
How do you find out today why a device restarted at the customer's site — is it in a report, or is that where the guessing starts? Write to us — we are curious which diagnostic question you missed most recently in the field.
Transparency note: This article was written with the help of artificial intelligence and reviewed by the author before publication. The review applies to the German original; this English version is a translation.