OCPP 1.6
Sentinel uses capabilities exposed through verified OCPP 1.6 integrations. Availability and meaning vary by implementation, model, firmware, configuration and message support.
Mixed estates
One estate. Many evidence profiles.
Sentinel works with the signals each verified charger and integration can provide—without pretending every model, firmware version or protocol behaves the same.
Sentinel estate intelligence
Health
Understand what the available evidence says about operational condition.
State · change · trends
Observability
See the coverage, freshness and provenance behind the operational view.
Coverage · freshness · provenance
Evidence stays attached to findings, so teams can see what changed and why it matters.
Uneven evidence
Standardised status does not mean standardised visibility
A mixed estate can include several manufacturers, model generations, firmware versions, network configurations, and integration routes. A common dashboard makes the estate easier to navigate, but it can also flatten meaningful differences.
Sentinel normalises useful concepts while preserving the evidence boundary: where the data came from, what it means, when it was observed, and where coverage stops.
Integration routes
Use verified capability, not protocol assumptions
Relevant OCPP 2.x variants
Where implemented and verified, later OCPP capabilities provide additional structure or evidence. A version label alone does not establish coverage.
Vendor APIs
Approved vendor APIs add evidence that is not available through the configured OCPP path when permissions, cadence, semantics and limitations are verified.
PlugStream Native
Native device evidence is represented separately from third-party integration assurance and follows the implemented PlugStream firmware and platform capability.
Discover, map, preserve
Canonical telemetry without losing the source story
Discover capabilities
Identify which signals and behaviours are genuinely available for the applicable model, firmware, configuration, and integration.
Map meaning
Translate relevant source data into consistent operational concepts.
Preserve provenance
Keep the original source, units, timestamp, quality, mapping version, and applicability attached.
Represent the gaps
Distinguish unsupported, unobserved, stale, reported-but-unverified, and unknown evidence.
Chargers and integration sources
Verified OCPP 1.6 capabilities, verified relevant OCPP 2.x capabilities, approved vendor APIs, and separate PlugStream Native device evidence.
Capability discovery
Identify what the applicable model, firmware, configuration, and integration can actually provide.
Canonical telemetry with provenance
Map comparable concepts without erasing source meaning, timestamp, units, quality, or mapping context.
Freshness, gaps, relationships, and trends
Assess what is present, missing, stale, contradictory, or changing.
Explainable evidence
Show what supports a finding, what weakens it, and what remains unknown before presenting separate Health and Observability views.
Connection-aware collection
Collect with the capability and connection in mind
Sentinel uses available evidence efficiently: discover what a device can provide, avoid assuming unavailable signals, and preserve timestamps and gaps when cadence changes.
Comparability
Make comparisons only where the evidence supports them
Two chargers are not automatically comparable because they share a connector type or top-level status. Model, firmware, configuration, operating context, integration path, evidence coverage, and freshness can all affect the conclusion.
A useful cohort should show why its members belong together and what limitations remain.
FAQ
Mixed-estate questions
Does Sentinel support every OCPP charger?
Support and evidence depth are verified for the specific charger, firmware, configuration, protocol behaviour and integration path.
Does OCPP 2.x always provide better Observability than OCPP 1.6?
No automatic conclusion should be drawn from the version alone. What matters is which capabilities are implemented, configured, mapped, timely, and verified.
What happens when a signal is unavailable?
Sentinel represents it explicitly as unsupported, unobserved, stale, reported but unverified, or unknown rather than assuming a favourable value.
Can vendor API and OCPP data be combined?
Yes, when both integrations are supported and their semantics, timing, identity and provenance can be reconciled for the estate.
Find out what your estate can actually evidence
Start with the chargers, integrations, and signals already in your estate. We will help you map what is visible, where evidence is limited, and which questions need a better data source.