Why smart energy device integration never gets cheaper

Ask a firmware engineer at an EV charger manufacturer what they thought they would be working on when they took the job.

They’ll probably say power electronics, thermal behaviour, and control logic that has to hold under load. Anything with a physical result at the end of it.

Then ask what last week actually contained. They’ll probably describe a mapping document for how one utility reads a field that another reads differently, a regression that turned up because a partner upgraded their backend on a Thursday, and a call about why telemetry arrives every thirty seconds when this particular programme was built expecting it every ten seconds.

All of that work is necessary. It is also the work nobody joined to do. Integration glue is the per-partner code that translates between what a device does and how one specific utility interprets a shared protocol. Every device manufacturer selling into more than one market is maintaining some.

Why does a compliant device still need a new integration for every utility?

Many protocols define how a device and a utility platform exchange messages. They do not define how the device behaves: how quickly it responds to a signal, what it reports and how often, or what it does when the connection drops. Each utility specifies those behaviours for its own programme. A device that has passed protocol conformance testing still needs a separate integration for every utility it connects to.

Which is why the work never converges. The second integration teaches a team very little about the third. The tenth teaches them almost nothing about the eleventh.

It also does not end when it ships. It becomes something to keep alive. By year three, a device team is maintaining a set of relationships that can each break independently, on somebody else's release schedule, for reasons that will not appear in any changelog they can read.

What does integration work cost beyond engineering hours?

Per-utility integration carries a direct cost in engineering time and an indirect cost in retention. The work is invisible, because no customer notices an integration that worked. It never reaches a finished state, because each one becomes a maintenance obligation. And the expertise does not transfer, since knowing how one utility interprets one field is valuable to that single relationship and worth nothing in the next market or at the next employer.

Engineering leaders can price the first cost. Sprints, headcount, the two features that did not get built this year. The second arrives later and is harder to see coming.

This is a phase, not a failure

None of this is a criticism of manufacturers or of utilities. Every party is behaving rationally. A utility specifies what its programme actually needs. A manufacturer builds to the specification in front of it, because that is the available market entry. Without a recognised standard that both sides already trust, custom work is the only route available. Nobody owns the cost, so everybody pays it, privately, in engineering hours.

Markets tend to pass through a version of this. It ends when enough participants agree to pin the behaviour down somewhere shared, underneath all of them, rather than renegotiating it deal by deal.

Mercury Consortium is a nonprofit certification body for the grid-facing performance of smart energy devices. We certify how quickly a device responds, what it reports, and how it behaves when the connection drops. Our certification sits on top of the protocols a team already runs, so an existing implementation carries forward rather than being rebuilt.

If you want to learn more about getting certified, get in touch.

‍

‍