A charger can boot, connect, authorise and complete a transaction while still being difficult to operate. The platform sees that the unit is online. It may see energy delivered and a final status. But when behaviour changes, the evidence needed to explain the change can be missing, ambiguous or detached from the component that produced it.
That distinction matters. Protocol compatibility answers whether two systems can exchange supported messages. Observability answers whether those messages provide enough credible evidence for an operator to understand what is happening.
Both are valuable. They are not the same claim.
Connection is binary; evidence is layered
The first operational view of a charger is usually simple: connected or disconnected, available or unavailable, charging or not charging. Those states are useful, but they compress a complicated device into a few labels.
Consider a connector that delivers materially less current across several comparable sessions. A platform may be able to see the change without knowing its cause. Useful firmware can help retain the surrounding facts:
- the model, hardware revision, running firmware and active configuration;
- which connector, component and transaction the evidence belongs to;
- the requested, commanded and observed state, where the device can distinguish them;
- measurements with units, location, phase, timestamp and sampling behaviour;
- any relevant warning, protection event or recovery state;
- whether a value is fresh, cached, derived, unavailable or unsupported.
Without that context, an unexplained number risks becoming an unexplained alarm. With it, the platform can present a narrower and more defensible question for an operator or engineer to investigate.
Start with identity and capability
Every useful evidence interface begins by saying what product is actually running.
Model-family labels are rarely enough. Capabilities can change with hardware revision, firmware version, configured feature set, regional variant and integration route. Firmware should expose stable identifiers for those boundaries and declare supported capabilities wherever the protocol or approved interface allows it.
This avoids a familiar integration mistake: assuming that every charger advertising the same protocol version implements the same messages, fields, measurands, monitoring behaviour or optional features.
Capability discovery should also describe absence. There is an important difference between:
- unsupported by this product;
- supported but disabled by configuration;
- supported but not available in the current operating state;
- expected but stale or delayed;
- temporarily suppressed;
- not yet verified through this integration.
If those conditions collapse into silence, the receiving platform cannot tell an evidence gap from a favourable result.
Preserve state transitions, not just the latest label
A current state says where the charger appears to be now. A transition record shows how it got there.
Operations-ready firmware should make meaningful transitions observable with device time and component context. That can include connection state, connector state, transaction boundaries, update progress, restart and recovery. Where the architecture distinguishes a command from an observed output or result, preserve that distinction.
The aim is not to stream every internal variable. It is to expose the transitions that help another system reconstruct a useful operational sequence without inventing missing steps.
Measurements need meaning
A number without context is not strong evidence.
For each exposed measurement, document and retain the applicable:
- unit and scaling;
- connector, component or phase;
- measurement location;
- source timestamp;
- sampling and reporting cadence;
- trigger or threshold behaviour;
- quality, precision or known limitation;
- raw or derived status where relevant.
The same discipline applies to thermal evidence. A temperature may describe an ambient sensor, power-module sensor, connector sensor or an internal estimate. Treating all four as interchangeable would create a misleading comparison.
Use structured events for investigation
Free text is helpful to a person, but difficult to correlate reliably across a fleet. Stable event and fault structures make change easier to group, trend and investigate.
A useful event record identifies the affected component, stable code, severity, occurrence time, state and recovery or clearance condition. Additional text can explain the event, but it should not be the only machine-readable description.
Firmware should also report what happened after an intervention. A reset request being accepted is different from the charger restarting successfully. A firmware image being downloaded is different from the expected version running after reboot. A fault disappearing from the current display is different from a confirmed recovery.
These distinctions help the platform show evidence rather than convert every accepted command into a successful outcome.
OCPP version is not an evidence score
OCPP creates the common route that makes mixed estates possible. Newer versions add richer ways to describe device capability, monitoring and security, but a version label still does not say which optional capabilities are implemented, configured, accessible or useful for a particular product.
The Open Charge Alliance's OCPP certification programme verifies conformance to the applicable specification. Its OCPP 2.0.1 certification profiles distinguish mandatory Core functionality from optional profiles such as Advanced Device Management. That official certification is important and should remain distinct from an operational evidence assessment.
Sentinel asks a complementary question: for this manufacturer, model, firmware, configuration and integration route, what evidence can an operator actually use—and what remains unavailable or unverified?
Proprietary interfaces can add evidence without hiding its source
Some devices expose useful component, diagnostic or thermal context through an approved vendor API that is not present through the configured OCPP route. That evidence can strengthen an integration if its provenance remains visible.
The mapping should retain the source field, meaning, units, timestamps, access conditions, mapping version and known limitations. A canonical platform concept can make evidence comparable without pretending the sources were identical.
This is also why an integration should not quietly merge manufacturer-derived, protocol-derived and platform-derived values into one unexplained field.
More visibility does not move safety into the cloud
Firmware observability must preserve a clear device boundary.
Local protection and control remain authoritative at the charger. Cloud evidence can show that a protection event occurred, attach context and support a proportionate operational response. It must not be presented as a replacement for device protection, manufacturer safety design, qualified inspection, applicable standards or statutory obligations.
Similarly, a change in measurements may justify investigation without proving an electrical diagnosis. Good observability makes that limitation easier to see.
Better evidence has a commercial return
Improving the evidence interface is not only a platform concern. It can help manufacturers:
- shorten integration and support investigations;
- distinguish device, configuration, communication and platform questions earlier;
- reduce unnecessary escalation and site attendance;
- give operators clearer model and firmware applicability;
- make capability easier to evidence in tenders;
- maintain a stronger change record across firmware releases;
- demonstrate where a product provides more than basic connectivity.
The benefit comes from specificity, not volume. A smaller set of well-defined, fresh and scoped signals is more useful than a large stream whose meaning changes between versions.
A practical improvement path
Start with the product that exists today:
- Scope the model, hardware revision, firmware, configuration and integration route.
- Inventory current state, measurement, event, diagnostic and update evidence.
- Record units, timestamps, cadence, provenance and known gaps.
- Prioritise additions that support real operational decisions.
- Test normal, degraded, restart, update and recovery paths.
- Publish the verified scope and review it after material change.
Our public firmware-readiness guide turns those steps into an engineering checklist. Manufacturers can then start an integration review to map the evidence into a maintained hardware profile and, where the review supports it, the Sentinel Integration Assurance Programme.
The objective is straightforward: make charger behaviour easier to understand without claiming more than the evidence can support.