A charging map can have accurate coordinates and still give a driver poor advice. A green marker might describe a charger that was available twenty minutes ago, a connector that shares equipment with another plug, or a location whose entrance has closed. Availability becomes useful only when an application explains what the reported state covers and how confidently it describes the present.
This article develops a practical interpretation layer between a provider feed and the screen. The examples are illustrative design choices, not universal freshness thresholds. For the wider discovery workflow, start with the charging station API overview.
Count charging opportunities at the right level
The official OCPI Locations documentation separates locations, EVSEs, and connectors. An EVSE serves one vehicle at a time and can have multiple alternative connectors. Its status vocabulary distinguishes available, charging, blocked, reserved, and unknown conditions. Unknown includes situations in which the status cannot be obtained because equipment is offline.
Consider a fictional site with three EVSEs. Each offers two connector types, but only one connector on each EVSE can be used at a time. A database may contain six connector records while the site supports three simultaneous charging sessions. Counting available connector rows would exaggerate capacity. First match the driver's connector requirements, then count distinct usable EVSEs.
Keep the original provider hierarchy alongside your normalized identifiers. If a feed supplies connector status without a clear relationship to shared equipment, record that limitation instead of inventing independent capacity. The charging station data model guide explains how these identifiers support consistent joins and summaries.
Separate equipment status from confidence in the data
Use two fields in your presentation model: the reported operational state and the quality of the evidence supporting it. For example, an EVSE can have a last known state of available while its freshness classification is stale. Another can have a recent report explicitly saying unknown. Both require qualified messaging, but they describe different problems.
Do not translate every unsuccessful response into occupied. Occupancy concerns use of the equipment; a timeout concerns your ability to obtain information. Likewise, a successful HTTP response may contain cached information. Transport success alone cannot establish that a driver can begin charging.
A practical internal representation
Store the provider's raw status, a normalized status, a freshness label, and a reason code. Suggested reason codes include missing timestamp, delayed delivery, unsupported status, and incomplete site coverage. Keep these codes stable for application logic while allowing reader messages to change. A new provider value should fall into a visible unknown category until its meaning has been reviewed.
Record the clocks that answer different questions
A single updated timestamp is rarely enough for diagnosis. Record when the source says an observation occurred, when your system received the record, and when the record became available to readers. When a source provides only an object modification time, label it accordingly. In OCPI, an EVSE's last_updated can reflect changes to that EVSE or its connectors; it is not automatically a dedicated status observation timestamp.
Imagine a status observed at 14:00, received at 14:04, and displayed at 14:05. The delivery lag is four minutes, and the observation is five minutes old when read. Saying updated one minute ago would describe your receipt time while concealing the delay that matters to the driver.
Now imagine a connector description changes at 14:05 without a new operational observation. That edit should not reset your status confidence. Store timestamp semantics with the adapter configuration, and preserve a missing observation time as missing. A believable invented timestamp is harder to diagnose than an explicit gap.
Use a consistent time basis for comparisons and retain the original offset when useful for investigation. Flag timestamps implausibly far in the future. Do not silently make them current, because that can hide clock errors and keep a stale state looking fresh.
Choose freshness rules for the decision being made
A planning page and a turn by turn charging recommendation need different evidence. Establish the intended decision first, then choose a freshness policy using the provider's observed update behavior and the consequences of error. A development example might classify observations under two minutes as recent, older observations as aging, and those over ten minutes as stale. These numbers are sample product settings, not an industry standard.
Validate those settings against actual feed behavior. If an integration sends only changes, silence is ambiguous unless there is a separate confirmation mechanism or a documented freshness guarantee. A charger could remain available for hours, or its connection could have failed immediately after the last message. Your application should be able to express that uncertainty without changing the underlying reported state.
Keep operational polling policy separate from display policy. Refreshing your database more frequently cannot manufacture observations that the upstream source never made.
Make ingestion resilient to ordinary delivery problems
Build the consumer around stable provider and equipment identifiers. Make repeated delivery harmless, and decide how to handle older events before they arrive. In a fictional sequence, a charging event observed at 09:02 arrives before an available event observed at 09:01. Applying arrival order blindly would move the display backward.
Where the source contract supports ordering by observation time or version, use that evidence. If two updates conflict without a trustworthy ordering signal, preserve the conflict for investigation rather than assuming that the latest network packet describes the latest equipment state. Keep enough event history to explain the decision.
Also distinguish partial updates from replacement snapshots. A missing EVSE in an incomplete page of results is not evidence of removal. Complete pagination, verify snapshot scope, and apply the provider's documented lifecycle rules before changing the inventory. For the relationship between station messaging and roaming exchange, see OCPP versus OCPI.
Write messages that preserve the useful distinctions
A location summary should reveal uncertainty in its denominator. Suppose four compatible EVSEs include two recent available reports, one charging report, and one stale available report. A useful summary is “2 reported available; status uncertain for 1.” Showing “3 available” would quietly promote the stale observation into a present fact.
- Recent available report: “Reported available two minutes ago.”
- Recent charging report: “In use when last reported.”
- Explicit unknown report: “Current status unavailable.”
- Old available report: “Last reported available; status may have changed.”
- Incomplete coverage: “Live status covers three of five compatible charging points.”
Keep opening hours, access restrictions, and compatibility beside the status rather than folding everything into a green or red dot. Availability is one input to a charging decision. It does not reserve the equipment or establish that every access requirement is satisfied.
Measure whether your interpretation stays trustworthy
Track observation age, ingestion delay, unknown status share, and the proportion of the inventory covered by usable status data. Break these measures down by provider so that a strong feed does not conceal a weak one. Review distribution tails as well as averages: a small set of persistently delayed sites can create repeated bad experiences.
Test the reader experience with duplicate events, reversed event order, missing timestamps, partial snapshots, and provider outages. Ask whether each case produces a defensible message, not merely whether the endpoint responds. The developer resources provide a starting point for organizing integration requirements.
Make uncertainty part of the answer
Useful availability data connects a reported state to the equipment it describes, the time it represents, and the confidence your application can justify. Preserve those distinctions through ingestion, storage, aggregation, and display. When evidence becomes weak, let the message become more qualified. That approach gives drivers information they can interpret and gives engineering teams a clear explanation when the display and the parking space disagree.
