Quick Summary (TL;DR)
Choose a charger and a controller that have been tested together, rather than buying on an OCPP version number alone. OCPP 1.6J already supports the functions most home energy automations need: reporting charging sessions, meter values, remote start/stop where enabled, and smart-charging profiles on compatible chargers. OCPP 2.0.1 adds a structured device model, more comprehensive security and transaction handling, and further smart-charging features. It is not backward-compatible with OCPP 1.6. The Home Assistant OCPP integration is a community integration, not an official built-in Home Assistant integration, and a manufacturer’s implementation may expose only a subset of the advertised protocol.
For a single domestic 7–22 kW wallbox, a well-supported OCPP 1.6J charger with verified, persistent current limiting can be a better purchase than a theoretically newer OCPP 2.0.1 model with untested firmware, locked backend settings or no compatible local controller. If the installation needs more demanding security, fleet management, device monitoring or future extensibility, evaluate OCPP 2.0.1—but verify the exact implementation and back-office system first.
What is OCPP, and where does Home Assistant fit?
The Open Charge Point Protocol (OCPP) is a communications standard between a charging station (the charge point) and a charging station management system (CSMS), often called the backend. It is not a power-electronics standard, an electricity meterAliExpress price accuracy certificate, or an assurance of electrical installation compliance. Its job is to let a central system authenticate charging sessions, receive status and energy measurements, manage some configuration and, when supported, send charging commands.
A practical Home Assistant installation typically follows one of three architectures:
- Direct local OCPP server: the wallbox connects over the home LAN to a community OCPP server running as a Home Assistant integration. Home Assistant acts as the CSMS and can expose charger data and controls.
- Vendor CSMS plus Home Assistant API: the wallbox talks to a vendor or installer backend; Home Assistant reads or controls it through a different cloud API. The fact that the charger uses OCPP internally does not make OCPP local to Home Assistant.
- Separate charging controller or CSMS: a local OCPP server, energy management system or cloud CSMS owns the charger connection and publishes the useful information to Home Assistant by a documented integration, MQTT or API.
These systems should not all attempt to command the same charging schedule. Many wallboxes are configured for one active OCPP backend URL. Redirecting that URL to Home Assistant can disconnect a manufacturer app, roaming service, installer portal or tariff provider. Multi-backend proxies exist, but they add another compatibility and security layer and should never be assumed to work with every charger.
For the underlying hardware comparison, see our ESP32 Modbus Energy Meter with Home Assistant guide. An external import/export meter is often needed for solar-aware charging even if the EVSE reports its own delivered kWh.
OCPP 1.6J vs 2.0.1: capabilities that actually matter
| Requirement | OCPP 1.6J | OCPP 2.0.1 | Home automation implication |
|---|---|---|---|
| Typical protocol transport | JSON over WebSocket; OCPP 1.6 also defines SOAP | JSON over WebSocket | A controller and wallbox must negotiate a mutually supported version and transport |
| Device status | Status notifications and basic configuration | Structured device model with richer monitoring | 2.0.1 improves management but cannot create a sensor absent from the hardware |
| Energy and power readings | MeterValues when implemented/configured | Transaction and meter reporting with richer context | Confirm units, intervals and cumulative energy counters on the particular charger |
| Remote start/stop | RemoteStartTransaction / RemoteStopTransaction | RequestStartTransaction / RequestStopTransaction | Remote control can be disabled by policy, authorisation or local user settings |
| Charging current profiles | Smart Charging feature/profile, if implemented | More capable Smart Charging model | Test accepted and applied charging limits, not just command acknowledgement |
| Configuration | Flat GetConfiguration / ChangeConfiguration keys | Component/Variable device model | Automation and diagnostics commands are not interchangeable |
| Transactions | StartTransaction / StopTransaction and related messages | TransactionEvent model | Integration must implement the correct version-specific state machine |
| Security | Security extensions/profiles and firmware-dependent implementations | Stronger integrated security capabilities | Validate actual TLS, certificates, credentials and firmware policy |
| Plug & Charge | No equivalent native 2.0.1 framework | ISO 15118-related features | Neither OCPP alone guarantees vehicle, charger and PKI compatibility |
| Backwards compatibility | Not compatible with OCPP 2.0.1 | Not compatible with OCPP 1.6 | A dual-version product needs a tested selection process |
The Open Charge Alliance (OCA) explicitly states that 2.0.1 is not a backwards-compatible upgrade to 1.6. It also now lists OCPP 2.1 as a newer standard: 2.1 was designed so application logic for 2.0.1 can remain compatible and adds features including bidirectional charging. Do not infer OCPP 2.1/V2X capability from a 2.0.1 logo. Official OCA protocol overview.
Do not confuse mandatory protocol support with optional profiles
The label OCPP 1.6 compatible is insufficient to guarantee the charger’s Smart Charging functions. In the OCA’s revised 1.6 certification programme, Smart Charging remains optional. The 2025 revision expanded mandatory requirements for security and firmware management in the certification core, but it did not make every possible charging feature compulsory. Likewise, OCPP 2.0.1 certification is built around mandatory and optional profiles that can change between programme editions.
If a wallbox claims certification, request the exact OCA certificate, version, profiles, model and firmware scope. A third-party app describing a model as OCPP-capable is not equivalent to independent certification of that model. For the current distinctions, consult the OCA’s OCPP 1.6 certification update and OCPP 2.0.1 certification update.
What is the Home Assistant OCPP integration?
As of October 2026, the commonly used lbbrhzn/ocpp project is a community-maintained HACS custom integration. Its documentation describes OCPP 1.6J and 2.0.1, with OCPP 2.1 support labelled experimental. It provides a local OCPP endpoint, charger entities and actions; the exact exposure depends on the charger and the integration release. Another project, HA OCPP, is independently developed from the earlier codebase. Installation steps, integration domains, services and supported device profiles can differ across these projects and releases.
- Project and version support: lbbrhzn/ocpp.
- Current automation notes: Home Assistant OCPP charge automation documentation.
- Alternative project information: alex89rm/ha-ocpp.
Do not follow snippets from one fork against another without checking the installed integration’s actual action names. More importantly, Home Assistant does not enforce EVSE safety limits. The EVSE controller, vehicle, RCD/RCBO protection, supply design and installer-configured load management remain responsible for safe operation even when Home Assistant is offline.
Does an OCPP charger need an internet connection?
Not inherently. A charger supporting a configurable ws:// or wss:// backend on the LAN can connect to a local OCPP server, subject to the manufacturer’s firmware restrictions. However, a vendor can require cloud activation, a managed backend, a subscription, certificates or an installer password before exposing OCPP. Some cloud CSMS products will not accept a private LAN address. Conversely, a charger may continue operating autonomously through a network outage but stop exporting telemetry to Home Assistant.
The purchasing test is not ‘supports OCPP’; it is ‘can I configure this exact firmware to connect securely to my own local OCPP server, without disabling a feature I need?’
The five operations most homes actually need
| Home automation | Data/control path | Possible on 1.6J? | Possible on 2.0.1? | What to verify |
|---|---|---|---|---|
| See plugged-in/charging/fault states | Status and transaction messages | Usually, with supported implementation | Usually, with supported implementation | States are accurate during pauses and reconnections |
| Track session kWh | EVSE meter values | Yes, if reported | Yes, if reported | Cumulative vs session energy, units and reliable reset behaviour |
| Pause/resume charging | Remote transaction control or low-current profile | With compatible charger and settings | With compatible charger and settings | Whether pause is permitted, how authorisation resumes |
| Adjust current for solar | Smart-charging profile or supported vendor control | Optional feature | Depends on supported smart-charging functions | Current is physically applied within seconds and persists as expected |
| Schedule overnight charging | Charger schedule, CSMS profile or separate vendor function | Yes on suitable implementations | Yes on suitable implementations | Behaviour through network, HA or power outages |
For a home, current limiting is generally more important than the ability to display a firmware revision. A charger that exposes live current, energy and an adjustable safe charging limit may be fully adequate for solar and time-of-use optimisation. A charger exposing a hundred 2.0.1 device variables but no tested charging control may be less useful.
Solar-surplus charging is more than an OCPP command
A robust surplus-charging loop requires a bidirectional grid meter or reliable site-power calculation, a known EV charging phase configuration, and a controller that avoids oscillation. Suppose the household measures a steady 2.2 kW export and runs a single-phase EV charging point. At roughly 230 V, 2.2 kW corresponds to approximately 9.6 A before headroom and losses. A controller might request 8 A to leave a buffer, but this is a worked engineering example, not an installation setting.
If surplus falls below the vehicle’s minimum accepted charge current, the automation should pause or use a clearly defined grid allowance rather than continually demand impossible limits. The vehicle’s own onboard charger, the wallbox and the OCPP implementation set practical minima and response behaviour. IEC 61851 AC charging constraints and an installer’s approved protection/load-management design take priority over any app’s schedule. If three phases are active, an apparent ‘8 A’ command is not equivalent to 8 A of single-phase demand: roughly 230 V × 8 A × 3 ≈ 5.5 kW across three phases, whereas one phase is about 1.84 kW.
Read our existing ESP32 energy monitoring methods comparison for choosing a suitable site meter. Meter accuracy and phase direction are prerequisites, not cosmetic dashboard details.
Smart Charging profiles: accepted is not the same as applied
The most common integration failure is an apparently successful response to a charging-limit command while the vehicle continues at the old current. OCPP can convey a profile; only the real station firmware can enforce it. Common causes include charger support being disabled, the wrong connector ID, an unsupported profile purpose, stack-level conflicts, a conflicting vendor scheduler, or units and phases not matching the charger.
| Configuration issue | Typical symptom | Verification |
|---|---|---|
| Unsupported Smart Charging feature/profile | Charge limit is refused or ignored | Ask supplier to demonstrate profile support on exact firmware |
| Another backend owns the schedule | Your setting briefly applies, then changes | Inventory every scheduler and remove control conflicts |
| Charger expects watts, controller sends amps | Rejection, wrong result or minimum-current behaviour | Query advertised charging-rate units and conversion assumptions |
| Incorrect phase count | Surprising power ceiling | Check electrical topology and per-period phase field |
| Profile purpose or ID collision | Profile overwrites another profile | Reserve unique IDs and distinguish station, default and transaction limits |
| Profile stacking conflict | Profile accepted but does not win | Check maximum stack level and active priority |
| Connector or EVSE ID mismatch | Wrong connector controlled or no effect | Confirm version-specific connector addressing |
| Cached/offline behaviour | Limit disappears on reconnection | Test disconnect, power restoration and session restart |
The Home Assistant OCPP documentation includes an important implementation detail: for OCPP 1.6, its integration reserves certain profile IDs around the charger-wide and transaction functions; for 2.0.1, the charging-limit slider may use ID 1. Reusing reserved profile IDs or choosing an unsupported stack level can silently defeat an otherwise valid automation. Consult the current charge automation guidance and never copy a fixed profile ID without checking your installation.
A safe commissioning test, not a live-wiring procedure
Ask your qualified installer or the responsible systems integrator to demonstrate these steps with the vehicle connected in a safe, compliant installation:
- Record the charger make, exact SKU, firmware, OCPP version and negotiated backend transport.
- Confirm that status, session energy and active current are shown locally and update as expected.
- Apply a conservative, installer-approved test limit through the documented controller action, then independently observe the actual measured AC current or power.
- Change to another approved limit; ensure the EVSE obeys it and no external scheduler overrides it.
- Disconnect Home Assistant’s network connection and confirm the EVSE uses a documented safe fallback, without relying on the software automation for electrical safety.
- Reconnect and start a new session to verify that the correct charger and connector recover their settings.
- Restore the original approved installation parameters, documenting the results and firmware version.
These are operational acceptance checks. They are not instructions to modify mains wiring, bypass protective devices, defeat pilot-signal interlocks or override the charger’s safety thresholds.
Why 2.0.1 is more than ‘1.6 with extra sensors’
OCPP 2.0.1 changes protocol semantics in ways that matter to software and long-term support. Its device model organises components and variables rather than relying on a loosely named set of flat configuration keys; this can provide better visibility into installed hardware and settings. It uses an updated transaction event model and richer authorisation, security and certificate-management concepts. Its charging and display features target more capable stations and commercial infrastructures.
For Home Assistant, the distinction matters in two directions. On the positive side, a competent 2.0.1 integration can provide more structured diagnostics. On the negative side, the changed message models mean a controller written for 1.6 cannot simply send identical messages to a 2.0.1 charger. A 1.6 script using GetConfiguration is not the same as a 2.0.1 request for a Component/Variable value. Firmware updates can change which device variables are exposed.
What about OCPP 2.1 and bidirectional charging?
OCA released OCPP 2.1 in 2025. It adds features concerning bidirectional charging/V2X, distributed energy resources and ISO 15118-20, among others. But a 2.1-capable backend still does not make a car, EVSE and household installation V2H/V2G-capable: all equipment and grid permissions must support that use case. Neither OCPP 1.6J nor 2.0.1 should be sold as a guaranteed route to future bidirectional charging. Refer to the Open Charge Alliance protocol overview.
Security and privacy: your backend is part of the charging system
Moving OCPP from a managed cloud service to your local Home Assistant server can improve data control, but it also makes the homeowner responsible for updates, credentials, backups and network access. A poorly secured internet-facing OCPP endpoint is not safer merely because it is ‘local first’.
| Security question | Good practice | Failure to avoid |
|---|---|---|
| Is the OCPP connection encrypted? | Use wss:// with correctly managed TLS where supported, particularly across untrusted networks |
Exposing an unauthenticated ws:// endpoint publicly |
| Who can connect? | Use device identity, strong credentials/certificates and scoped network rules | Allowing arbitrary clients to impersonate the charger |
| What happens after certificates change? | Test renewal and failure recovery | Locking out the charging station without a recovery plan |
| Who can change limits? | Restrict controller actions and document ownership | Uncontrolled competing cloud and local schedulers |
| Does firmware remain supported? | Require a published update process and security maintenance | Buying old firmware based solely on an OCPP logo |
| Are data and logs needed? | Retain enough to debug failures, avoid unnecessary personal data | Uploading customer/vehicle identifiers to untrusted log services |
OCA’s updated 1.6 certification programme made Security Profile 2 part of the mandatory core from October 2025, and the updated 2.0.1 programme also specifies its security baseline. That is a statement about certification requirements, not proof that any existing charger labelled OCPP 1.6 is secure. Verify certification date, profile, firmware and the operational TLS configuration.
OCPP versus Modbus, MQTT and a vendor API
Not every smart EV charger needs an OCPP backend. For one residential unit, a documented local API may be simpler and easier to maintain. Modbus is particularly useful for power/energy measurement and sometimes charge limits; MQTT can be a convenient integration bus; a vendor cloud API can provide polished scheduling but depends on connectivity and account access. The right interface is the one that exposes the specific controls you need, reliably and with an acceptable support path.
| Interface | Typical role | Strength | Limitation |
|---|---|---|---|
| OCPP 1.6J | Charger-to-CSMS integration | Mature charging/session functions, possible smart charging | Optional features and vendor CSMS lock-in |
| OCPP 2.0.1 | Richer charger management | Device model, improved transactions and security | Version mismatch, inconsistent feature exposure |
| Native local API | Direct wallbox telemetry/control | Often simpler for one home, no external CSMS | Vendor-specific, may change in firmware |
| Modbus TCP/RTU | Metering and approved equipment control | Deterministic register access on supported devices | Register maps vary; not a substitute for EVSE protections |
| MQTT | Publishing energy and charger states | Integrates well with Home Assistant | No common EVSE control contract across brands |
| Vendor cloud API | App-linked remote functions | Easier remote monitoring and tariff integrations | Cloud/account dependence and possible service changes |
For commercial fleets, charging networks and multi-site estates, the standardisation benefits of OCPP are much more substantial than for a single standalone household charger. However, multi-station load balancing still needs a reliable site meter and a control system designed to enforce a whole-site current ceiling; OCPP message support alone cannot replace physical protection and the network operator’s connection rules.
How to evaluate a charger before buying
A specification sheet listing OCPP 1.6/2.0.1 does not answer whether your Home Assistant installation can connect. Ask the seller or installer to give written answers to the following:
| Buying checkpoint | Required evidence | Warning sign |
|---|---|---|
| Exact version and transport | Model/firmware support for OCPP 1.6J, 2.0.1 or both; WS/WSS | ‘OCPP ready’ without a version |
| Local custom backend | User/installer can set arbitrary backend URL and credentials | Fixed vendor URL only |
| Smart charging | Demonstrated accepted and applied charge-current limits | Only charging status shown in screenshots |
| Per-phase handling | Clear single/three-phase behaviour, measurement and current limits | Claims that kW and A are interchangeable |
| Backend coexistence | Documented effect on manufacturer app and cloud features | ‘Keep both’ with no technical explanation |
| Internet outage | Documented autonomous charging fallback | Requires cloud round-trip for every decision |
| Home Assistant support | Repository release, feature matrix and known firmware issues | Unsupported forum snippet from years ago |
| Certification and installation | Region-appropriate EVSE conformity and qualified installer acceptance | Treating OCPP certificate as electrical safety approval |
| Security | WSS/TLS, authentication, updates and recovery | Unauthenticated endpoint to the open internet |
| Warranty and lifecycle | Supported firmware, accessible logs, spare/support policy | Controller changes void equipment warranty |
Budget for the whole system, not just the charger. A local OCPP setup may need an always-on Home Assistant host, a reliable LAN, an external bidirectional meter, a suitable electricity distribution board, installation by a qualified electrician and, depending on the requirements, separate tariff or PV data. Do not invent savings based on a charger datasheet: actual benefit depends on energy prices, charge windows, mileage, export tariffs and the amount of controllable demand.
Worked charging-window economics
Consider a 40 kWh charging session measured at the wallbox and an illustrative tariff of £0.10/kWh off-peak versus £0.28/kWh peak. If all of that energy can move from peak to off-peak and other charges are unchanged, the gross difference is 40 × (£0.28 − £0.10) = £7.20 for that session. This is only a scenario, not a live tariff quotation or a guaranteed saving. Fixed charges, real vehicle energy requirement, household load, battery availability, charger efficiency and tariff eligibility can alter the answer.
The OCPP version does not determine the arithmetic. A charger with a reliable built-in schedule may capture the same benefit without any OCPP connection. OCPP is relevant when you need to coordinate charging with household demand, PV export, dynamic prices or multiple chargers—provided the required control interface has actually been tested.
Home Assistant configuration: a practical architecture
A maintainable local setup has four layers:
- Measurement: a reliable grid import/export energy meterAliExpress price and wallbox session measurement, with timestamps and correct signs.
- Control: one designated scheduling authority—either Home Assistant/OCPP, a vendor energy manager or the charger itself. Avoid overlapping controllers.
- Safety fallback: EVSE electrical protections and installer-configured limits that remain in force when the automation host fails.
- Observability: dashboards and logs showing the requested limit, measured charge current, network state and the source of any schedule changes.
A useful Home Assistant dashboard has separate entities for charging status, EVSE delivered power (kW), session energy (kWh), site import/export (kW) and last OCPP heartbeat/connection state. Do not mistake an instantaneous current sensor for a cumulative energy entity when setting up the Energy dashboard. Incorrect device class, unit, sign or reset logic can double-count EV charging. For troubleshooting, read our existing Home Assistant Energy Dashboard Troubleshooting for ESPHome article.
Why we are not publishing a universal set_current YAML snippet
The Home Assistant OCPP community projects change action names and parameters over time, and the request structure differs between OCPP versions. A canned automation could conflict with your charger-wide maximum-current profile or its vendor scheduler. For that reason, the safe reusable pattern is measure → calculate an installer-approved target → command via documented integration action → verify measured response → fail safely. Use the exact YAML examples from the maintainer’s current charge automation documentation, with the charger’s supported units, profile IDs and limits—not guessed service calls.
Troubleshooting: when the charger says connected but won’t obey
| Symptom | Likely cause | First safe check |
|---|---|---|
| Charger never connects | OCPP URL, incompatible version or TLS issue | Verify negotiated subprotocol, DNS, backend port and certificates |
| Connected but no energy readings | Reporting interval/settings or charger firmware | Check documented meter measurands and units |
| Remote start rejected | Local authorisation, car or charger state | Confirm status and user permission |
| Limit command accepted, EV power unchanged | Wrong profile purpose, stack, connector, conflicting schedule | Observe actual power and inspect active profiles |
| Solar automation oscillates | Meter latency, low threshold or multiple controllers | Increase filtering/hysteresis within approved settings |
| Home Assistant loses connection at night | Host sleep, router changes, firmware reset or cloud fallback | Review timestamped logs and DHCP/reservation |
| Vendor app stops working | Charger reassigned to local CSMS | Confirm vendor’s single-backend restrictions |
| Power values appear three times too high | Incorrect phase interpretation | Compare independent meter power and phase configuration |
| Charge limit works, then disappears | Transaction-scoped profile or reconnection reset | Review profile validity and supported persistence |
| OCPP 2.0.1 variable query fails | 1.6-style flat configuration key | Use documented Component/Variable path |
Keep logs for the charger and the chosen CSMS. When reporting a defect, include firmware, OCPP version, charger model, relevant timestamps and a redacted message trace; exclude API credentials, serialised authentication tokens and personal data.
FAQ
Is OCPP 2.0.1 always better for Home Assistant?
No. It provides richer protocol capabilities, but a proven 1.6J integration with functional Smart Charging can be more useful and less troublesome for a home. Match the charger, controller and firmware first.
Is OCPP 1.6 obsolete?
No. The Open Charge Alliance continues to support OCPP 1.6, including an updated certification programme introduced in October 2025. But verify ongoing firmware/security support from the specific manufacturer.
Does OCPP allow automatic solar-only EV charging?
Only if the charger exposes a usable charging-limit mechanism and the controller has accurate real-time site export data. A charger that reports OCPP status without Smart Charging control cannot deliver proportional surplus charging through OCPP alone.
Can I connect Home Assistant and the vendor backend simultaneously?
Not by default. Many chargers maintain one OCPP CSMS connection. Some vendors provide a separate API or supported multi-system arrangement. Ask what happens to billing, tariff scheduling, firmware updates and the warranty before changing the backend URL.
Will an OCPP 2.0.1 charger charge bidirectionally?
OCPP 2.0.1 support does not guarantee vehicle-to-home or vehicle-to-grid operation. OCPP 2.1 expands the protocol for bidirectional scenarios, but the car, inverter/EVSE equipment, grid approval and actual control system must all support the operation.
Can I use any OCPP charger in the UK or EU?
No. Protocol interoperability is separate from electrical conformity, earthing, protective devices, installation standards and connection requirements. Choose an appropriately approved model for your region and use a qualified installer. Never bypass protection or alter safety limits to make a home automation work.
Verdict: choose tested interoperability, not just a bigger version number
For most Home Assistant owners, a well-documented OCPP 1.6J charger with proven local server support and actual Smart Charging control is sufficient. OCPP 2.0.1 is attractive when its improved management, monitoring and security features are genuinely supported by both charger and controller. Where the charger already has an excellent local API, the simplest and most reliable answer may be not using OCPP at all.
Choose a complete, compliant installed system; confirm the exact firmware, backend ownership, profile support and safe fallback; and test measured charge current rather than trusting a successful message acknowledgement. That is the difference between a standards-compatible purchase and a working home energy automation.
Official specifications and practical sources
- Open Charge Alliance — OCPP protocol overview: version differences, Smart Charging, security and OCPP 2.1.
- OCA whitepaper — What is new in OCPP 2.0.1?: backwards incompatibility, transaction changes and device model.
- OCA — Updated OCPP 1.6 certification programme (2025): new core requirements and optional Smart Charging profile.
- OCA — Updated OCPP 2.0.1 certification programme (2025): revised profile requirements.
- OCPP specification portal: OCPP 2.0.1 introduction and terminology.
- Home Assistant community OCPP integration: supported versions and integration documentation.
- Home Assistant OCPP charge automation guide: charge limits, stack levels and profile IDs.
Related reading on esp32.co.uk
- ESP32 Modbus Energy Meter with Home Assistant — external power and energy measurement for charging automations.
- ESP32 Energy Monitoring Methods Compared — site metering methods and limitations.
- Home Assistant Energy Dashboard Troubleshooting for ESPHome — avoiding incorrect charger-energy measurements.
