Reliability built into the chargers you ship
Most escalations that reach you are a fault code and a phone call, and the unit is fine by the time anyone looks at it. GridLink goes out with your units and reads every signal they produce in the field, separates a hardware fault from a vehicle handshake or a backend timeout, clears what can be cleared remotely, and hands your team the message sequence behind everything else.
What an escalation looks like with the stream attached
02:14:07 CP-4417 -> StatusNotification
{"connectorId":1,"status":"Faulted","errorCode":"OtherError",
"vendorErrorCode":"E-042","info":"contactor feedback mismatch"}
02:14:07 CP-4417 <- StatusNotification.conf {}
02:14:09 CP-4417 -> StopTransaction
{"transactionId":88213,"reason":"EVSEFailure","meterStop":1204}
02:14:41 CP-4417 -> StatusNotification {"connectorId":1,"status":"Available"}
02:15:02 CP-4417 -> StatusNotification {"connectorId":1,"status":"Faulted"}
- OtherError with a vendor code the management system does not decode. The pattern behind E-042 is learned from how this model behaves, not from a lookup table.
- The session stopped two seconds after the fault was raised and the reason came from the charger, so the vehicle is ruled out.
- The port cleared itself and faulted again in twenty seconds. A single snapshot would have shown it available.
Illustrative excerpt in OCPP 1.6 call format. Otto reads the same stream on 2.0.1, where the equivalent evidence arrives as NotifyEvent and TransactionEvent messages.
A charger that reports Faulted with OtherError has told you nothing. What it did in the ninety seconds around that message tells you almost everything, and that is the part nobody keeps.
Fewer escalations reach you
60% of tickets across deployments are resolved remotely, so they never become a field report against your unit.
Cause, not a code
Vendor error codes are read in context with session state and delivered power, then classified by what the unit actually did.
Derating made visible
Delivered power measured against the rating, so a unit charging at a third of spec stops passing as healthy.
The four failure modes that generate field traffic are offline units, connectors that stay locked after a session, authorizations that time out before charging starts, and derating. Otto resolves what it can through the operator's management system and escalates the rest with the diagnosis, the message evidence, and the part when there is one.
A share of what reaches you was never your unit. Tripped breakers, site power, and miswired installs come back as warranty escalations because nobody separated them at the site. GridLink walks whoever is standing at the charger through those over text and closes them where they belong, so your field reports narrow to the ones that are actually about the hardware.
Deployment starts with a month-long observation window. Otto reads traffic and builds workflows against how your hardware behaves in that operator's environment before it sends anything to a charger. Nothing goes on the unit itself. Across GridLink deployments, first-attempt charging success has moved from 91% to 97%, and the units running under it are the same ones that were generating the field reports before. What that looks like from the operator's side is on the public networks page.
Your units sit next to everyone else's in the same networks, read the same way.
Questions from hardware teams
Both. On 1.6 the evidence comes from StatusNotification, StopTransaction, MeterValues, and the vendor error codes attached to them. On 2.0.1 the same reasoning runs over NotifyEvent, TransactionEvent, and variable reporting. Units on either version can sit in the same fleet and be diagnosed the same way.
That is the question the message stream answers. Message ordering and timing separate a charger-side failure from a vehicle that walked away from the handshake and from a backend that never returned an authorization. The diagnosis arrives with the messages that support it, which is what makes it usable in a warranty conversation.
GridLink connects to the charge point management system the operator already runs, through its API. Deployments run on Monta, Ampeco, Ampcontrol, Driivz, and EV Connect, and any system with API access can be connected. Nothing has to be installed on the charger.
Bring the fault your field reports keep describing badly.
Thirty minutes on your models in the field, the OCPP versions they run, and what keeps coming back as OtherError. The reliability calculator shows what those failures cost the operator running them.