Frequently Asked Questions

This usually involves status sync delays or "soft faults". OCPP 1.6 relies on StatusNotification to report connector status; with network jitter or interrupted heartbeats, the platform may still show a stale status. OCPP 2.0.1 improves this with TransactionEvent and finer-grained monitoring, but if the charger detects a fault (emergency stop pressed, gun-lock failure) without reporting NotifyEvent in time, the app may still wrongly treat it as available. We recommend showing a "last status update time" hint on the app detail page.

The startup delay typically occurs during the round trip of Authorize and StartTransaction (1.6) or TransactionEvent(Started) (2.0.1). If the WebSocket heartbeat between platform and charger is unstable, or the charger signal is weak, command delivery is retried. OCPP 1.6 requires waiting for the platform to return a transaction ID before energizing, while the 2.0.1 event-driven model is theoretically faster — but poor handling of TransactionEvent in charger firmware can still cause lag.

This is a classic state desynchronization. Under OCPP 1.6, if a charger stops due to over-temperature, leakage protection or an unplugged gun (without a proper StopTransaction), the platform may keep the "charging" status because it never received StatusNotification(Faulted/Available). OCPP 2.0.1's TransactionEvent(Ended) is more rigorous but requires correct implementation on the charger side. The platform can also apply a fallback rule of "auto-close local orders on heartbeat timeout".

Plug & Charge (PnC / ISO 15118) is a native OCPP 2.0.1 capability; OCPP 1.6 does not support standard PnC. If the platform manages chargers on both protocols, the app should display feature tags dynamically based on each charger's actual protocol version and configuration. If the 2.0.1 certificate chain is not configured correctly, PnC fails and the app should fall back to "please scan to start".

Troubleshoot in the order: network layer → WebSocket layer → OCPP layer. ① Check whether the charger can reach the platform's wss:// address (DNS, firewall, port 443); ② Check that the Charge Point Identity matches the URL path exactly (e.g. wrong case or suffix of the ID in /ocpp/CP001); ③ For OCPP 1.6 check whether Heartbeat is normal; for 2.0.1 check Heartbeat after BootNotification and security event logs. If the local screen works but OCPP is offline, the OCPP module is usually frozen or the SIM card is out of data.

Yes, but it can be abstracted. Their messages are incompatible: 1.6 uses StartTransaction/StopTransaction while 2.0.1 uses TransactionEvent; 1.6 configuration relies on ChangeConfiguration key-value pairs while 2.0.1 uses the structured SetVariables/GetVariables device model. We recommend building a unified "charging session" model above the protocol layer, mapping messages from both protocols to the same business object to avoid duplicated development.

OCPP 1.6's RemoteStartTransaction requires the charger to perform local authentication (e.g. Authorize) first; an expired local whitelist cache or misconfigured AuthorizeRemoteTxRequests will cause rejection. OCPP 2.0.1's RequestStartTransaction is stricter — the platform must ensure the EVSE and Connector AvailabilityState is Operative. Also, if the WebSocket connection is half-dead (TCP open but application layer unresponsive), commands time out; use TriggerMessage or heartbeat timeout detection to reset the connection.

OCPP 2.0.1 firmware management is safer and traceable. In 1.6, UpdateFirmware is typically "send URL → charger downloads → charger reboots", leaving the platform unaware of download progress and verification results. In 2.0.1, PublishFirmware with UpdateFirmware supports chunked download, security verification and status reporting — better for large-scale operations. If your platform is still mainly 1.6, add a "verify firmware version via post-update BootNotification" step to the process.

"Supports OCPP 1.6" does not mean "plug and play". Common breakpoints: WebSocket address format (trailing slash, path case, wss vs ws), mismatched Charge Point Identity, un-negotiated message subprotocol (ocpp1.6), and TLS certificates not trusted by the charger (old firmware not recognizing new CAs). OCPP 2.0.1 additionally requires matching Security Profiles — if the platform enforces TLS while the charger only supports basic auth, the handshake fails outright.

No. The OCPP version is determined at WebSocket handshake time via the subprotocol (ocpp1.6, ocpp2.0.1), and charger firmware usually implements only one. The platform routes to the corresponding protocol handler based on the charger's BootNotification or the identity in the connection URL. A physical charger cannot "upgrade" from 1.6 to 2.0.1 at runtime without replacing firmware and reconfiguring.

Under 1.6, learning what a charger supports often means pulling a pile of vendor-specific keys via GetConfiguration. The 2.0.1 device model standardizes EVSE → Connector → Component → Variable in a tree structure, so the platform can precisely read or write e.g. a gun's temperature threshold or a relay's state. This is a qualitative leap for fine-grained O&M and remote diagnostics — but it requires rebuilding the configuration management module on the platform backend instead of the flat key-value store used for 1.6.

1.6 supports basic SetChargingProfile (static or simple time-based curves) but lacks grid coordination and dynamic adjustment. 2.0.1 smart charging is more complete: ChargingStationExternalConstraints, dynamic power caps and multi-charger cluster scheduling, and it works with ISO 15118's ChargeParameterDiscovery. For "ordered charging" or demand control, 2.0.1 chargers are the better choice — but the platform's charging-plan engine needs a corresponding upgrade.

We offer four cooperation models — franchise, equipment purchasing, site operation and enterprise customization — covering agents, property managers & developers, fleet operators and more. Submit Inquiry with your site details and cooperation intent; our business team will contact you within 24 hours with revenue estimates and on-site survey support. You can also email us directly via the Contact page.