01The problem
Wallbox chargers reported 1,147 telemetry signals: phase currents, voltages, temperatures, configuration parameters and software-service observability.
There was little control over what was transmitted, how often and with which definitions. Units and naming were inconsistent, and parameters changed between software versions without notice — harder to use, and more expensive to move, process and store.
02The solution
I coordinated software, service, backend and data engineering around one platform to register and configure signals: a sensor registry with naming and unit conventions, validation ranges, versioning and visualisation tools.
Telemetry modes and aggregation reconciled teams who wanted every measurement with a platform that had to reduce volume. Deprecation rules, access restrictions and user training completed the governance.
The telemetry path
Backend and data engineering also weighed streaming and storage options, such as Kafka versus SQS/SNS/Kinesis and Timestream versus Druid.
Key decisions
- 01
Modes, not all-or-nothing.
Low-volume, high-volume and debugging modes kept detailed telemetry for the use cases that justified it.
- 02
Define before you collect.
Every signal got a name, unit, valid range and version, so downstream teams could interpret it.
- 03
Plan the end of a signal.
Deprecation and data-deletion rules stopped volume from only ever growing.
03Where AI fits
No AI component. The leverage came from governing the data itself: clear definitions and deliberate collection.
04Results
- Consistent naming, units and versioning for every team that consumes telemetry.
- Users trained on the platform, with access restrictions in place.
Details have been abstracted to respect confidentiality: internal identifiers, names and non-public figures are omitted.