Enable local API via native OCPP for smart home systems

[leomwa]

Summary

We've received consistent community feedback asking for local control of the Easee charger – most recently in this feedback post. The request is to allow direct, local control for use cases like Home Assistant integrations, dynamic load management, solar charging, etc., without going through the Easee Cloud APIs.

This post outlines a proposal to enable a native OCPP-based local API, giving smart home systems a standards-based way to communicate directly with the charger.

---

Original request (from community)

“Currently I have an Easee Charger Lite. I love it, it has a great design, is easily installed and has a ton of possibilities.

I'm currently running my own load balancing setup via Home Assistant... For this I send a request to the Easee cloud every 5 seconds... This must incur quite a bill for Easee if more consumers are using your API.

My request is: implement a limited local API that allows some very basic use cases like turning the charger on/off, setting the dynamic circuit limit and maybe RFID authentication?

This would one: reduce costs for Easee's cloud, and two: provide Easee owners with a fallback should the charger ever become unsupported.”

---

Proposal: use native OCPP for local integration

We propose allowing activation of local OCPP (Open Charge Point Protocol) on Easee chargers. This would:

• Allow standards-based communication with systems like Home Assistant, Homey, EVCC
• Enable high performance integrations and thus reduce outbound internet traffic
• Provide a "fallback mode" for local-only control

Key constraints:

• Feature is experimental and optional (support is community based via issues submitted to this repository)
• Activation happens via a documented Commissioning API
• Local OCPP uses Wi-Fi (no mobile connectivity)

These constraints are primarily to optimise for speed and engagement. The engineering team prioritises important feedback and balances it with other business goals. The first beta incarnation of the software is provided as-is, and we can explore together whether it could be a good match for home automation systems.

---

Example use cases

• Enable or disable charging based on solar production
• Use third-party apps like Home Assistant to schedule charging

---

Questions for discussion

1. Would local OCPP support solve your problem?
2. Should we consider shipping this as a container/integration (e.g. for Home Assistant)?
3. What’s the best way to make this visible and usable for power users, but not confusing for casual users?
4. Which OCPP features are essential for your use case?
5. If not OCPP, and no standards to guide local API development, what would be the ideal local API look like for you?

Also use the discussion to express your interest to sign up and test this. Here's the form.

---

Links and references

• Community feedback thread
  This is the original thread, but best to continue discussions via Easee-connect.

• Commissioning / Activating OCPP for users
  Instructions on activating OCPP on your charger.

---

We’re listening – and we’re keen to hear from you if you run integrations, DIY setups, or just want to help shape the local API roadmap. Let us know below 👇

[sgoelz]

Thanks for your proposal and the feedback to this change requests.
My answers to your questions:

1. Would local OCPP support solve your problem?

Yes it would solve the Problem, If this allows evcc or Home Assistent tonget local Access tonthe charger

2. Should we consider shipping this as a container/integration (e.g. for Home Assistant)?

This would be a great binus and maybe for some people a game changer .

3. What’s the best way to make this visible and usable for power users, but not confusing for casual users?

Maybe a checkbox to enable OCPP in the charger settings

4. Which OCPP features are essential for your use case?

• Start/Stop charging
• Switch the Ampere from 6A to 16A(32A)

5. If not OCPP, and no standards to guide local API development, what would be the ideal local API look like for you?

A default REST API or MQTT API would do it

[ArthurStocker]

I personally would like to see OCPP and MQTT

[skela]

Made an OCPP service implementation in next to no time in a docker container, that's super simple. Also made a REST API service that you can call, translating that into OCPP messages that are transmitted to the charger. All packaged in a neat little docker image. Might look into getting the same service to send out MQTT events, if anyone would be interested in something like that.

[leomwa]

Feedback form
We’d like to highlight the form you can use to sign up to test this idea with us. Once we’ve gathered some interest, we’ll send you updates via mentions or email with any initial documentation we have.

Here's the form.

[1rishj]

Another function that is also very useful is switching the phases. 1 Phase/3 Phase, also local authentication would be awesome.
E.g. EVCC handles the authentication based on if the car is known to the system or not. The data wouldn't need to come from the charger, to authenticate a car (even if ISO 15118 implemented would be even better).

Edit, sorry, just saw your form consider it filled out.

[osulivanDE]

First of all thanks for listening on your community.

i personally would prefer a dedicated API but OCCP with smart charging features also is welcome. Please stick to secure web socket (WSS) and OCCP 2.0

A Home Assistant Addon would be nice but i personally would prefer EASEE to look into the best possible cooperation with the EVCC community since most of us want the local controllability for solar surplus charging and EVCC is (afaik) the largest community when it comes to this topic.
Please consider to sponsor them and keep a close relationship to this community.

[stefanriegel]

OCCP and/or local RestAPI will be awesome. local API/OCCP is essentially for easee home wallboxes

EVCC is the main reason to have a local APi for me

[svedaker]

Make sure you can access the data from the equalizer. Preferred as a stream of data like secure web socket or mqtt. How much power/current is export/imported from the power grid. How much going to the charger.

[stfgnt]

First of all I'm really glad you're adressing this topic. Thanks for that!

1. Would local OCPP support solve your problem?
   Totally! Easee charger is the only component in my PV/smart home setup which is not accessible via local API. Besides achieving better availability/reliability I'd be thrilled about the improved latency and performance.

2. Should we consider shipping this as a container/integration (e.g. for Home Assistant)?
   Yes, please! I'm using Home Assistant a lot. However I wouldn't consider this highest priority. Teaming up with EVCC would be fantastic and more important from my point of view.

3. What’s the best way to make this visible and usable for power users, but not confusing for casual users
   Some kind of feature toggle in the Easee portal?

4. Which OCPP features are essential for your use case?
   Remote start/stop, setting dynamic charging parameters, selecting the number of phases for charging
   EDIT: Trigger reset would be handy because my e-Golf annoys me with overcurrent errors at times.

5. If not OCPP, and no standards to guide local API development, what would be the ideal local API look like for you?
   REST API and/or MQTT

[scspijker]

Original feedback reporter here, stunned that you are picking this up and greatly increases my trust in the Easee brand!

1. Would local OCPP support solve your problem?

Yes, faster and more reliable control with less cloud/internet dependency.

2. Should we consider shipping this as a container/integration (e.g. for Home Assistant)?

As a bonus, but with a local OCCP API I would encourage you to test against existing (opensource) OCCP libraries / add-ons. If you build your own add-on, don’t only test/support that.

4. What’s the best way to make this visible and usable for power users, but not confusing for casual users?

Other chargers I know enable local API’s only when you check a box somewhere hidden in advanced settings. There you could also implement security / credentials for the API.

5. Which OCPP features are essential for your use case?

Essential is start / stop and current control for load balancing or solar integration purposes. The newest OCCP standards also allow for vehicle identification, this would be a biiiiiiiiiiiiiiiiiig bonus for me.

6. If not OCPP, and no standards to guide local API development, what would be the ideal local API look like for you?

No opinion as I fully recommend following open standards.

[schweiger2]

OCPP is fine because it offers a standard protocol solution.

Keep in mind that there are different community solutions which may prefer a local API for further development such as Home Assistant (as suggested) and evcc and iobroker and other.

[TheFreaker86]

Thank you for adressing this topic (some say it's rather an issue and I'm inclined to agree). I hope to see it implemented soon. The dysfuntional Cloud API has messed with me more than once. The functionality of the cloud API is fine, like dynamic charging current and phase switching. The things I need from the local API is:

• Home Assistant integration. As I said the functionality of the API is good. One little thing is missing: You don't have the option to put in a dynamic electricity price e.g. from Tibber.
  There is a third party integration already out there, but it only passes the cloud API through to HA. It works, but a 1st party integration is of higher quality I assume. I don't mean to belittle the integrations dev work by the way!
• Make things easy for the devs of EVCC. I already had an Easee Home when I came across EVCC. So I was forced to pay quite some money to EVCC for a sponsor token. If I had known EVCC before Easee I would have chosen some other EV charger which was free to use with EVCC. I'd gladly have donated to EVCC voluntarily instead of being forced because of a subpar cloud API. Voluntarily donating to EVCC is quite a different feeling then being forced. And I'm pretty sure I'm not alone in that regard.

Both things implemented would be a huge selling point for the Easee EV chargers. But with the unreliable cloud API that right now costs an additional mandatory fee to get it working with EVCC makes it rather meh. The EVCC devs once said they don't like Easee because the cloud API is so finnicky. If you (the Easee team) would rectify that you surely would turn this from a deal breaker to a selling point. Home Assistant and EVCC are so hugely popular and important projects, you can't afford to not be compatible with them.

[leomwa]

Thank you for taking the time to share these insights.

the option to put in a dynamic electricity price...

This was also requested and is picking up in speed in rollout. Stay tuned! (I wouldn't want to steal the thunder from the team releasing this so, I will stay short here) 😉

We’re going to dig into the EVCC implementation and community to better our understanding for exactly what is needed to offer first‑party support (over native OCPP).
Please stay tuned for an update on our progress. In the meantime, if there are specific EVCC features or workflows you’d like us to prioritize, let us know—we want to make this as smooth and friction‑free as possible.

Thanks again for pushing this forward!

[TheFreaker86]

Thank you for the reply! For me the dynamic charging is by far the most important feature that I need to maximise the use of my PV installation while charging. Is there a roadmap/schedule you can share when you release the firmware including local API for the chargers?

[BlueAndi]

Thank you that the topic is taken up again, I honestly didn't expect it anymore.

Would local OCPP support solve your problem?

Yes, it would solve it, because local smart charging is my main focus. Following a standard is in general a good way.

Should we consider shipping this as a container/integration (e.g. for Home Assistant)?

This would be great for the eassee wallbox owners and may be another good point for others to decide to choose a eassee wallbox.
On other hand this should not postpone the local API, because of the additional effort.

What’s the best way to make this visible and usable for power users, but not confusing for casual users?

You could add e.g. an expert mode checkbox to show/hide the complexity in the UI.
Inform about the feature roll-out via usual ways.

Which OCPP features are essential for your use case?

The smart charging feature.

If not OCPP, and no standards to guide local API development, what would be the ideal local API look like for you?

RESTful with swagger and MQTT (incl. HA automatic discovery).

[d-bugger]

Will this solution be compatible with an "external" operator configured in the cloud? (Since that one uses OCPP as well if I understand correctly)
Many of us use an non-easee operator (company car, tax puposes, ...)

[leomwa]

Hi. No, not at this time.

We’ve already run specific programmes to test our native implementation with some of our biggest operators (CPOs) and test participants at OCA events.

At this stage, we want to narrow the scope (significantly) and specifically focus on exercising this implementation with home automation use cases, over WiFi and so on (see constraints above).

Therefore, I’m hesitant to include external operators in this scope. We ultimately want a design that works best with local first, rather than the traditional general use case of OCPP operating outside one’s local network. That has been tested and we’re happy with the scenarios.

Of course, if you see it differently, I’d be happy to discuss it further.

[leomwa]

OCPP Commissioning API

As previously communicated, we aim to enable users to activate OCPP on their charging stations. We will use the provided documentation as a guide.

We have now created some rough endpoints under our general Commissioning API and would like to invite testing. Please refer to Commissioning for users for instructions on activating OCPP on your charger.

To reiterate a key prerequisite: ensure that the charger is paired with Easee for this to work.

To manage expectations, I would like to reiterate the earlier communicated key constraints:

• The feature is experimental and optional (support is community-based via issues submitted to this repository).
• Activation occurs via a documented Commissioning API.
• Local OCPP uses Wi-Fi (no mobile/cellular connectivity).

Please give it a try and let us know how it goes. We value your feedback and contributions. We would like to improve the documentation and the initial experience you have. Be sure to file a technical issue (bug) if something is not working for you.

Thank you for your comments and contributions so far.

---

Up next, while the native implementation is under testing, we plan to explore a path where a local HTTP server can be used in conjunction with this to enable more home automation scenarios. We aim to engage systems (e.g EVCC, HA, Homey) and gain insights.

[allcoolusernamesaregone]

This still works for me:

curl --request POST \
     --url https://api.easee.com/local-ocpp/v1/connection-details/CHARGERID \
     --header 'Authorization: Bearer xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' \
     --header 'accept: application/json' \
     --header 'content-type: application/*+json' \
     --data '
{
    "connectivityMode": "DualProtocol",
    "websocketConnectionArgs": {
        "url": "ws://ip:port"
    }
}
'

CHARGERID = something like EX1SZSZX

[BlueAndi]

@allcoolusernamesaregone

Thanks, already did it like you mention in the code fragment.

Problem was that first I tried to get the configuration-details, but it failed. It is necessary to set the connection-details once, to be able to read them via GET operation back. Now it works. Might be a bug?

[leomwa]

Yes its necessary to store them first before attempting to read them.
I have updated the docs to reflect your inputs thus far.
In addition to the prereqs, where I have now added the mentions to the auth bearer token and base URL, I've added:

Three main steps:

1. Store OCPP configuration
2. Apply OCPP configuration
3. Get configuration details (to verify/query stored configuration)

[iseeberg79]

What about the "SmartCharging feature profile"? Do we need to file more interest? As far as I've understood it's important to control the power. Because I am interested in using as much as PV surplus power for charging, I am missing this as an important feature?
I am unsure about, because I did not yet try to charge using the new API. I realized from docs and logs that the profile is not implemented yet. If it's required but already planned we need not to file interest, right?

[skela]

This isn't implemented yet. But your comments and activity in here, plus interactions with our partners will help us prioritize and focus on the next steps. I think your comment is probably enough ❤️ , but if you haven't already, you can fill in this form.

[TheFreaker86]

There is another thing I'd like to pose as a feature request: determine the energy and the associated costs depending on the RFID-chip used to start the charging session. AFAIK this isn't possible right now. How about that?

[leomwa]

Typically, this functionality is achievable through the OCPP server software side - because it can monitor charging sessions and the RFID keys (Authorise, StartTransaction) and consumption data (MeterValues). Subsequently, an endpoint (local) could be established to expose this data and perform post-processing with relevant tariff information.
I like this thought 🤔 Is this what you are thinking?

Maybe this has been solved with HA or EVCC -- will explore.

[BlueAndi]

I created a python script for easier playing around with it. If someone is interested in, you will find it here:
https://gist.github.com/BlueAndi/e887c33f854659f99a98cb03cf825246

The script uses requests, therefore install it first: pip install requests
Start the script with python like python easee_configure_local_ocpp.py <user_name> <password> with your user name and password.

It will show all of your chargers and whether local OCPP is enabled or disabled. Select then the appropriate action like enabling local OCPP and etc.

[BlueAndi]

First results with Home Assistant and the OCPP integration:

1. Install the OCPP integration in HA via HACS.
2. Add the OCPP integration with the central system.
3. Enable easee local ocpp with the charger id as charger point id, e.g. Exxxxxxx and ws://<my_homeassistant>:9000
4. The easee wallbox will be automatically detected in HA after some seconds.
5. Add it ... attention ... the charger point id comes up with "charger", change it to your charger id Exxxxxxx.

The easee wallbox will be shown:

But all of the sensors, configuration, diagnostic and controls are not available, except the maximum current control.

Both of my wallboxes (one with v330 and one with v333) connected to the ocpp integration.

Log:

2025-05-24 21:39:20.820 INFO (MainThread) [ocpp] Exxxxxxx: receive message [2,"42","BootNotification",{"chargePointModel":"Easee Home","chargePointVendor":"Easee ASA","firmwareVersion":"333","chargePointSerialNumber":"Exxxxxxx"}]
2025-05-24 21:39:20.826 INFO (MainThread) [ocpp] Exxxxxxx: send [3,"42",{"currentTime":"2025-05-24T19:39:20Z","interval":3600,"status":"Accepted"}]
2025-05-24 21:39:20.829 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"1c10fab2-ccc2-4437-8885-fb7910ccde47","GetConfiguration",{"key":["SupportedFeatureProfiles"]}]
2025-05-24 21:39:20.923 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"1c10fab2-ccc2-4437-8885-fb7910ccde47",{"configurationKey":[{"key":"SupportedFeatureProfiles","readonly":true,"value":"Core"}]}]
2025-05-24 21:39:20.935 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"54d46396-4866-4075-bfae-f04a05cc28a2","GetConfiguration",{"key":["NumberOfConnectors"]}]
2025-05-24 21:39:20.943 INFO (MainThread) [ocpp] Exxxxxxx: receive message [2,"43","StatusNotification",{"connectorId":1,"errorCode":"NoError","status":"Available"}]
2025-05-24 21:39:20.965 INFO (MainThread) [ocpp] Exxxxxxx: send [3,"43",{}]
2025-05-24 21:39:21.027 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"54d46396-4866-4075-bfae-f04a05cc28a2",{"configurationKey":[{"key":"NumberOfConnectors","readonly":true,"value":"1"}]}]
2025-05-24 21:39:21.039 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"cdb290b6-ce82-41f2-a6a8-92f5c774f0aa","GetConfiguration",{"key":["HeartbeatInterval"]}]
2025-05-24 21:39:21.127 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"cdb290b6-ce82-41f2-a6a8-92f5c774f0aa",{"configurationKey":[{"key":"HeartbeatInterval","readonly":false,"value":"3600"}]}]
2025-05-24 21:39:21.130 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"f4f5feaf-c72f-4299-b344-d822837bbf6b","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Current.Export"}]
2025-05-24 21:39:21.235 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"f4f5feaf-c72f-4299-b344-d822837bbf6b",{"status":"Accepted"}]
2025-05-24 21:39:21.245 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"cb736deb-9dac-4ad9-9f4b-10a69d0bbccc","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Current.Import"}]
2025-05-24 21:39:21.332 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"cb736deb-9dac-4ad9-9f4b-10a69d0bbccc",{"status":"Accepted"}]
2025-05-24 21:39:21.337 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"90c609c7-ff16-48d9-8242-4b2beef3f05b","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Current.Offered"}]
2025-05-24 21:39:21.435 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"90c609c7-ff16-48d9-8242-4b2beef3f05b",{"status":"Accepted"}]
2025-05-24 21:39:21.438 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"f8307472-9bfe-4b42-b2d9-0238f26954ec","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Energy.Active.Export.Interval"}]
2025-05-24 21:39:21.554 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"f8307472-9bfe-4b42-b2d9-0238f26954ec",{"status":"Accepted"}]
2025-05-24 21:39:21.557 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"a3f6a4fa-2e4a-40ae-b3d0-645e5617d6d6","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Energy.Active.Export.Register"}]
2025-05-24 21:39:21.639 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"a3f6a4fa-2e4a-40ae-b3d0-645e5617d6d6",{"status":"Accepted"}]
2025-05-24 21:39:21.643 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"ba6a3949-1691-44a3-8426-a272067b634c","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Energy.Active.Import.Interval"}]
2025-05-24 21:39:21.741 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"ba6a3949-1691-44a3-8426-a272067b634c",{"status":"Accepted"}]
2025-05-24 21:39:21.745 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"42ea4e17-6ea0-47cb-a757-d8a1ab8aad5d","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Energy.Active.Import.Register"}]
2025-05-24 21:39:21.844 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"42ea4e17-6ea0-47cb-a757-d8a1ab8aad5d",{"status":"Accepted"}]
2025-05-24 21:39:21.848 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"4dd3fd6c-6307-44c8-afe3-956bf546f8af","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Energy.Reactive.Export.Interval"}]
2025-05-24 21:39:21.949 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"4dd3fd6c-6307-44c8-afe3-956bf546f8af",{"status":"Accepted"}]
2025-05-24 21:39:21.956 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"0a4311ed-1b3f-4fbd-becd-3f6b74b1f6e2","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Energy.Reactive.Export.Register"}]
2025-05-24 21:39:22.049 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"0a4311ed-1b3f-4fbd-becd-3f6b74b1f6e2",{"status":"Accepted"}]
2025-05-24 21:39:22.052 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"74a9494a-7803-4835-9b03-c872d8323501","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Energy.Reactive.Import.Interval"}]
2025-05-24 21:39:22.157 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"74a9494a-7803-4835-9b03-c872d8323501",{"status":"Accepted"}]
2025-05-24 21:39:22.161 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"9170461c-95ce-41ea-8ac7-4a8a0fea0701","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Energy.Reactive.Import.Register"}]
2025-05-24 21:39:22.356 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"9170461c-95ce-41ea-8ac7-4a8a0fea0701",{"status":"Accepted"}]
2025-05-24 21:39:22.360 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"9abb3d6e-122e-4f99-ac0a-558e9064f29e","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Frequency"}]
2025-05-24 21:39:22.561 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"9abb3d6e-122e-4f99-ac0a-558e9064f29e",{"status":"Accepted"}]
2025-05-24 21:39:22.570 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"df0fccb1-0de7-4d12-ae93-22a43a45d762","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Power.Active.Export"}]
2025-05-24 21:39:22.663 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"df0fccb1-0de7-4d12-ae93-22a43a45d762",{"status":"Accepted"}]
2025-05-24 21:39:22.669 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"b8d75211-d0fe-4476-9bc6-e9dd8e09cd41","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Power.Active.Import"}]
2025-05-24 21:39:22.786 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"b8d75211-d0fe-4476-9bc6-e9dd8e09cd41",{"status":"Accepted"}]
2025-05-24 21:39:22.791 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"17518e5b-8e06-4703-a819-8c76ffd2bb9b","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Power.Factor"}]
2025-05-24 21:39:22.868 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"17518e5b-8e06-4703-a819-8c76ffd2bb9b",{"status":"Accepted"}]
2025-05-24 21:39:22.872 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"9b75a2c8-9781-4b1e-977e-e734d4bfd127","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Power.Offered"}]
2025-05-24 21:39:22.970 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"9b75a2c8-9781-4b1e-977e-e734d4bfd127",{"status":"Accepted"}]
2025-05-24 21:39:22.974 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"aed47a2a-d8a4-47c2-b7de-901a1e44c578","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Power.Reactive.Export"}]
2025-05-24 21:39:23.072 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"aed47a2a-d8a4-47c2-b7de-901a1e44c578",{"status":"Accepted"}]
2025-05-24 21:39:23.081 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"409fb1ad-50a5-4514-bd06-5e60f3e5dbd3","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Power.Reactive.Import"}]
2025-05-24 21:39:23.175 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"409fb1ad-50a5-4514-bd06-5e60f3e5dbd3",{"status":"Accepted"}]
2025-05-24 21:39:23.181 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"a4a224f8-95a6-4216-a63d-5753f67958fc","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"RPM"}]
2025-05-24 21:39:23.283 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"a4a224f8-95a6-4216-a63d-5753f67958fc",{"status":"Accepted"}]
2025-05-24 21:39:23.289 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"fb615e0e-1043-4cf3-919d-0fa86195bbc5","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"SoC"}]
2025-05-24 21:39:23.380 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"fb615e0e-1043-4cf3-919d-0fa86195bbc5",{"status":"Accepted"}]
2025-05-24 21:39:23.386 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"78010733-77cc-48aa-934f-4748e201300c","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Temperature"}]
2025-05-24 21:39:23.482 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"78010733-77cc-48aa-934f-4748e201300c",{"status":"Accepted"}]
2025-05-24 21:39:23.487 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"25e8dbb9-42c4-4f51-b8f5-a275675777e8","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Voltage"}]
2025-05-24 21:39:23.600 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"25e8dbb9-42c4-4f51-b8f5-a275675777e8",{"status":"Accepted"}]
2025-05-24 21:39:23.605 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"af4fcfa1-6864-4e6e-a59d-313f5c4d93fe","GetConfiguration",{"key":["MeterValuesSampledData"]}]
2025-05-24 21:39:23.687 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"af4fcfa1-6864-4e6e-a59d-313f5c4d93fe",{"configurationKey":[{"key":"MeterValuesSampledData","readonly":false,"value":"Energy.Active.Import.Register"}]}]
2025-05-24 21:39:23.693 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"a6122ae3-9cf0-4dad-ae0e-2e98a4b2e61f","GetConfiguration",{"key":["MeterValuesSampledData"]}]
2025-05-24 21:39:23.892 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"a6122ae3-9cf0-4dad-ae0e-2e98a4b2e61f",{"configurationKey":[{"key":"MeterValuesSampledData","readonly":false,"value":"Energy.Active.Import.Register"}]}]
2025-05-24 21:39:23.897 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"cd7f23f5-da60-48ed-9b38-ce8ee68a6918","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Current.Export,Current.Import,Current.Offered,Energy.Active.Export.Interval,Energy.Active.Export.Register,Energy.Active.Import.Interval,Energy.Active.Import.Register,Energy.Reactive.Export.Interval,Energy.Reactive.Export.Register,Energy.Reactive.Import.Interval,Energy.Reactive.Import.Register,Frequency,Power.Active.Export,Power.Active.Import,Power.Factor,Power.Offered,Power.Reactive.Export,Power.Reactive.Import,RPM,SoC,Temperature,Voltage"}]
2025-05-24 21:39:33.901 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"24f09590-3d88-46c0-838b-d05a69685105","GetConfiguration",{"key":["SupportedFeatureProfiles"]}]
2025-05-24 21:39:34.040 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"24f09590-3d88-46c0-838b-d05a69685105",{"configurationKey":[{"key":"SupportedFeatureProfiles","readonly":true,"value":"Core"}]}]
2025-05-24 21:39:34.045 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"dfce1f7e-e275-4201-9464-78a912b4c8a3","GetConfiguration",{"key":["NumberOfConnectors"]}]
2025-05-24 21:39:34.167 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"dfce1f7e-e275-4201-9464-78a912b4c8a3",{"configurationKey":[{"key":"NumberOfConnectors","readonly":true,"value":"1"}]}]
2025-05-24 21:39:34.171 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"67c70320-3c8a-453a-ba73-68a800c11965","GetConfiguration",{"key":["HeartbeatInterval"]}]
2025-05-24 21:39:34.349 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"67c70320-3c8a-453a-ba73-68a800c11965",{"configurationKey":[{"key":"HeartbeatInterval","readonly":false,"value":"3600"}]}]
2025-05-24 21:39:34.354 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"2519a064-ffc0-4998-a0f5-d1c241769953","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Current.Export"}]
2025-05-24 21:39:34.449 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"2519a064-ffc0-4998-a0f5-d1c241769953",{"status":"Accepted"}]
2025-05-24 21:39:34.454 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"5d5a8624-e10d-4546-9e5d-2d828ba9e180","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Current.Import"}]
2025-05-24 21:39:34.552 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"5d5a8624-e10d-4546-9e5d-2d828ba9e180",{"status":"Accepted"}]
2025-05-24 21:39:34.556 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"49c5224d-873c-4e9e-b1e9-945626f72370","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Current.Offered"}]
2025-05-24 21:39:34.654 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"49c5224d-873c-4e9e-b1e9-945626f72370",{"status":"Accepted"}]
2025-05-24 21:39:34.659 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"1db97b36-b7fa-4e07-b944-cac548bf06be","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Energy.Active.Export.Interval"}]
2025-05-24 21:39:34.757 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"1db97b36-b7fa-4e07-b944-cac548bf06be",{"status":"Accepted"}]
2025-05-24 21:39:34.761 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"a09a8873-c9dc-45b5-a365-8f3ee3a7d2ef","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Energy.Active.Export.Register"}]
2025-05-24 21:39:34.859 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"a09a8873-c9dc-45b5-a365-8f3ee3a7d2ef",{"status":"Accepted"}]
2025-05-24 21:39:34.863 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"348d9b7a-767f-47d9-80e8-b5884d746adb","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Energy.Active.Import.Interval"}]
2025-05-24 21:39:34.961 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"348d9b7a-767f-47d9-80e8-b5884d746adb",{"status":"Accepted"}]
2025-05-24 21:39:34.965 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"9ee79741-770f-4bf9-bd9f-75476358c735","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Energy.Active.Import.Register"}]
2025-05-24 21:39:35.064 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"9ee79741-770f-4bf9-bd9f-75476358c735",{"status":"Accepted"}]
2025-05-24 21:39:35.068 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"6232b3c8-40c4-4d12-a247-7955425f2ecb","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Energy.Reactive.Export.Interval"}]
2025-05-24 21:39:35.166 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"6232b3c8-40c4-4d12-a247-7955425f2ecb",{"status":"Accepted"}]
2025-05-24 21:39:35.170 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"0d6b5842-305b-4f7f-bfcd-79dfb6500064","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Energy.Reactive.Export.Register"}]
2025-05-24 21:39:35.269 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"0d6b5842-305b-4f7f-bfcd-79dfb6500064",{"status":"Accepted"}]
2025-05-24 21:39:35.276 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"21594fa2-02ba-4b19-991c-7d0fc4f68421","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Energy.Reactive.Import.Interval"}]
2025-05-24 21:39:35.371 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"21594fa2-02ba-4b19-991c-7d0fc4f68421",{"status":"Accepted"}]
2025-05-24 21:39:35.378 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"0e8d89e4-eb3f-4f71-8fb2-7fe80aae6446","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Energy.Reactive.Import.Register"}]
2025-05-24 21:39:35.380 WARNING (Thread-1 (_monitor)) [homeassistant.util.logging] Module ocpp is logging too frequently. 200 messages since last count
2025-05-24 21:39:35.474 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"0e8d89e4-eb3f-4f71-8fb2-7fe80aae6446",{"status":"Accepted"}]
2025-05-24 21:39:35.478 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"4a3d9216-9499-498f-a54e-887071368d3d","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Frequency"}]
2025-05-24 21:39:35.575 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"4a3d9216-9499-498f-a54e-887071368d3d",{"status":"Accepted"}]
2025-05-24 21:39:35.580 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"c6785f5e-a5ad-4165-a38a-80ced4c6f605","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Power.Active.Export"}]
2025-05-24 21:39:35.678 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"c6785f5e-a5ad-4165-a38a-80ced4c6f605",{"status":"Accepted"}]
2025-05-24 21:39:35.682 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"83012fa9-cd7c-4ce4-8234-c9b5adb7f0f3","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Power.Active.Import"}]
2025-05-24 21:39:35.780 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"83012fa9-cd7c-4ce4-8234-c9b5adb7f0f3",{"status":"Accepted"}]
2025-05-24 21:39:35.785 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"2973c5a8-c0cb-42e7-81be-d63d50bb43a0","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Power.Factor"}]
2025-05-24 21:39:35.883 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"2973c5a8-c0cb-42e7-81be-d63d50bb43a0",{"status":"Accepted"}]
2025-05-24 21:39:35.886 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"2b6db7b7-9328-4ab0-a3be-e2c16c750daf","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Power.Offered"}]
2025-05-24 21:39:35.985 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"2b6db7b7-9328-4ab0-a3be-e2c16c750daf",{"status":"Accepted"}]
2025-05-24 21:39:35.990 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"6bd0e4a1-b723-4c89-8191-2fd8ab0d08f3","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Power.Reactive.Export"}]
2025-05-24 21:39:36.088 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"6bd0e4a1-b723-4c89-8191-2fd8ab0d08f3",{"status":"Accepted"}]
2025-05-24 21:39:36.092 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"b067ee6c-4fe3-4ad6-865a-3ce31b17de56","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Power.Reactive.Import"}]
2025-05-24 21:39:36.190 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"b067ee6c-4fe3-4ad6-865a-3ce31b17de56",{"status":"Accepted"}]
2025-05-24 21:39:36.194 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"a42bb4cc-16df-4836-8333-7d941b26e532","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"RPM"}]
2025-05-24 21:39:36.292 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"a42bb4cc-16df-4836-8333-7d941b26e532",{"status":"Accepted"}]
2025-05-24 21:39:36.296 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"ff46517f-ae0f-4d48-8e66-380304e38ad4","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"SoC"}]
2025-05-24 21:39:36.395 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"ff46517f-ae0f-4d48-8e66-380304e38ad4",{"status":"Accepted"}]
2025-05-24 21:39:36.399 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"cc388d1e-daaa-498e-97a8-dbca9b63784e","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Temperature"}]
2025-05-24 21:39:36.497 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"cc388d1e-daaa-498e-97a8-dbca9b63784e",{"status":"Accepted"}]
2025-05-24 21:39:36.501 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"8c85b85c-15b1-4c83-a6ef-4a8b43380a3c","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Voltage"}]
2025-05-24 21:39:36.600 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"8c85b85c-15b1-4c83-a6ef-4a8b43380a3c",{"status":"Accepted"}]
2025-05-24 21:39:36.608 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"fdf9f33c-b0ce-4f94-92a8-5e9c06abff32","GetConfiguration",{"key":["MeterValuesSampledData"]}]
2025-05-24 21:39:36.702 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"fdf9f33c-b0ce-4f94-92a8-5e9c06abff32",{"configurationKey":[{"key":"MeterValuesSampledData","readonly":false,"value":"Energy.Active.Import.Register"}]}]
2025-05-24 21:39:36.709 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"2cf247b6-d8ca-4bba-8314-634fc9a9ffb2","GetConfiguration",{"key":["MeterValuesSampledData"]}]
2025-05-24 21:39:36.805 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"2cf247b6-d8ca-4bba-8314-634fc9a9ffb2",{"configurationKey":[{"key":"MeterValuesSampledData","readonly":false,"value":"Energy.Active.Import.Register"}]}]
2025-05-24 21:39:36.810 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"6d773701-0346-40dd-b5a5-6cd11f02ff54","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Current.Export,Current.Import,Current.Offered,Energy.Active.Export.Interval,Energy.Active.Export.Register,Energy.Active.Import.Interval,Energy.Active.Import.Register,Energy.Reactive.Export.Interval,Energy.Reactive.Export.Register,Energy.Reactive.Import.Interval,Energy.Reactive.Import.Register,Frequency,Power.Active.Export,Power.Active.Import,Power.Factor,Power.Offered,Power.Reactive.Export,Power.Reactive.Import,RPM,SoC,Temperature,Voltage"}]

The last send() routine was never answered and therefore ended in a timeout.

[BlueAndi]

Update to installation step 3:
3.1 Disable the "Automatic detection of OCPP Measurands" and choose in the next dialog the currently supported ones:

Log:

2025-05-29 18:04:32.358 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"099ee8e9-8acb-41f5-8b5a-3e7658fc61c6","GetConfiguration",{"key":["SupportedFeatureProfiles"]}]
2025-05-29 18:04:32.479 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"099ee8e9-8acb-41f5-8b5a-3e7658fc61c6",{"configurationKey":[{"key":"SupportedFeatureProfiles","readonly":true,"value":"Core"}]}]
2025-05-29 18:04:32.486 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"f814ee7d-795e-4bf4-8d57-d9e706431fd4","GetConfiguration",{"key":["NumberOfConnectors"]}]
2025-05-29 18:04:32.581 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"f814ee7d-795e-4bf4-8d57-d9e706431fd4",{"configurationKey":[{"key":"NumberOfConnectors","readonly":true,"value":"1"}]}]
2025-05-29 18:04:32.591 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"1518a705-9a7d-4365-8c85-a762a595cba6","GetConfiguration",{"key":["HeartbeatInterval"]}]
2025-05-29 18:04:32.683 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"1518a705-9a7d-4365-8c85-a762a595cba6",{"configurationKey":[{"key":"HeartbeatInterval","readonly":false,"value":"18000"}]}]
2025-05-29 18:04:32.690 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"bdb6d6b0-3e7e-44c6-845e-251d963ee9ee","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Current.Import,Energy.Active.Import.Register,Power.Active.Import"}]
2025-05-29 18:04:32.786 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"bdb6d6b0-3e7e-44c6-845e-251d963ee9ee",{"status":"Accepted"}]
2025-05-29 18:04:32.792 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"90a0a5cf-0d32-47de-a757-a1536a3c1a94","GetConfiguration",{"key":["MeterValuesSampledData"]}]
2025-05-29 18:04:32.891 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"90a0a5cf-0d32-47de-a757-a1536a3c1a94",{"configurationKey":[{"key":"MeterValuesSampledData","readonly":false,"value":"Current.Import,Energy.Active.Import.Register,Power.Active.Import"}]}]
2025-05-29 18:04:32.897 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"b8fe4a51-1676-4785-9d95-5a4dffa7a7fc","GetConfiguration",{"key":["MeterValuesSampledData"]}]
2025-05-29 18:04:32.990 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"b8fe4a51-1676-4785-9d95-5a4dffa7a7fc",{"configurationKey":[{"key":"MeterValuesSampledData","readonly":false,"value":"Current.Import,Energy.Active.Import.Register,Power.Active.Import"}]}]
2025-05-29 18:04:32.996 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"2ca758b7-5733-46f0-a067-3b5882a52141","GetConfiguration",{"key":["MeterValueSampleInterval"]}]
2025-05-29 18:04:33.402 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"2ca758b7-5733-46f0-a067-3b5882a52141",{"configurationKey":[{"key":"MeterValueSampleInterval","readonly":false,"value":"45"}]}]
2025-05-29 18:04:33.412 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"27f29fe8-391f-419f-9880-3dc9b070e0aa","ChangeConfiguration",{"key":"MeterValueSampleInterval","value":"60"}]
2025-05-29 18:04:33.502 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"27f29fe8-391f-419f-9880-3dc9b070e0aa",{"status":"Accepted"}]
2025-05-29 18:04:33.510 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"489a08a9-3fdf-4723-94c3-5bd2b2dc715f","GetConfiguration",{"key":["ClockAlignedDataInterval"]}]
2025-05-29 18:04:33.609 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"489a08a9-3fdf-4723-94c3-5bd2b2dc715f",{"configurationKey":[{"key":"ClockAlignedDataInterval","readonly":false,"value":"0"}]}]
2025-05-29 18:04:33.624 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"ab665cef-b215-444f-8644-2de86c6050b9","ChangeConfiguration",{"key":"ClockAlignedDataInterval","value":"900"}]
2025-05-29 18:04:33.707 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"ab665cef-b215-444f-8644-2de86c6050b9",{"status":"Accepted"}]
2025-05-29 18:04:33.719 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"bf00d0ea-5a72-466c-b0f8-c9940b356556","ChangeAvailability",{"connectorId":0,"type":"Operative"}]
2025-05-29 18:04:33.809 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"bf00d0ea-5a72-466c-b0f8-c9940b356556",{"status":"Accepted"}]
2025-05-29 18:04:59.313 INFO (MainThread) [ocpp] Exxxxxxx: receive message [2,"42","BootNotification",{"chargePointModel":"Easee Home","chargePointVendor":"Easee ASA","firmwareVersion":"333","chargePointSerialNumber":"Exxxxxxx"}]
2025-05-29 18:04:59.327 INFO (MainThread) [ocpp] Exxxxxxx: send [3,"42",{"currentTime":"2025-05-29T16:04:59Z","interval":3600,"status":"Accepted"}]
2025-05-29 18:04:59.513 INFO (MainThread) [ocpp] Exxxxxxx: receive message [2,"43","StatusNotification",{"connectorId":1,"errorCode":"NoError","status":"Available"}]
2025-05-29 18:04:59.530 INFO (MainThread) [ocpp] Exxxxxxx: send [3,"43",{}]

The last ocpp message is not answered, but I am not sure whether the message itself is valid.
Any idea?

[mamunjo]

Exxxxxxx: receive message [2,"43","StatusNotification",{"connectorId":1,"errorCode":"NoError","status":"Available"}]
Exxxxxxx: send [3,"43",{}]

This is the Chargepoint sending a status notification, and the CPMS sends back an ack. I don't see any problems here.

Next things to try would be to connect an EV. You should get a new updated StatusNotification.

If status == Preparing you should be able to start charging (start an OCPP transaction), either by presenting a RFID or by sending a RemoteStartTransaction.req.

[BlueAndi]

I connected the EV and the status is "preparing".

2025-06-02 23:44:59.920 INFO (MainThread) [ocpp] Exxxxxxx: receive message [2,"44","MeterValues",{"connectorId":1,"meterValue":[{"timestamp":"2025-06-02T21:45:00.000Z","sampledValue":[{"value":"0.011","context":"Sample.Clock","format":"Raw","measurand":"Current.Import","phase":"L1","location":"Inlet","unit":"A"},{"value":"0.010","context":"Sample.Clock","format":"Raw","measurand":"Current.Import","phase":"L2","location":"Inlet","unit":"A"},{"value":"0.010","context":"Sample.Clock","format":"Raw","measurand":"Current.Import","phase":"L3","location":"Inlet","unit":"A"},{"value":"2064.208","context":"Sample.Clock","format":"Raw","measurand":"Energy.Active.Import.Register","location":"Outlet","unit":"kWh"},{"value":"0.000","context":"Sample.Clock","format":"Raw","measurand":"Power.Active.Import","location":"Inlet","unit":"W"}]}]}]
2025-06-02 23:44:59.990 INFO (MainThread) [ocpp] Exxxxxxx: send [3,"44",{}]
2025-06-02 23:45:02.035 INFO (MainThread) [ocpp] Exxxxxxx: receive message [2,"45","StatusNotification",{"connectorId":1,"errorCode":"NoError","status":"Preparing"}]
2025-06-02 23:45:02.052 INFO (MainThread) [ocpp] Exxxxxxx: send [3,"45",{}]

I enabled in HA OCPP the charge control and the ev is charging. 🥳

2025-06-02 23:57:32.269 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"b5fa6426-64bc-49b5-a652-f2b3f155a9ec","RemoteStartTransaction",{"idTag":"1XY53J2CG1YELCVYPOIT","connectorId":1}]
2025-06-02 23:57:32.533 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"b5fa6426-64bc-49b5-a652-f2b3f155a9ec",{"status":"Accepted"}]
2025-06-02 23:57:32.540 INFO (MainThread) [ocpp] Exxxxxxx: receive message [2,"59","StartTransaction",{"connectorId":1,"idTag":"1XY53J2CG1YELCVYPOIT","meterStart":2064208,"timestamp":"2025-06-02T21:57:32.000Z"}]
2025-06-02 23:57:32.569 INFO (MainThread) [ocpp] Exxxxxxx: send [3,"59",{"transactionId":1748901452,"idTagInfo":{"status":"Accepted"}}]
2025-06-02 23:57:32.649 INFO (MainThread) [ocpp] Exxxxxxx: receive message [2,"60","StatusNotification",{"connectorId":1,"errorCode":"NoError","status":"SuspendedEVSE"}]
2025-06-02 23:57:32.663 INFO (MainThread) [ocpp] Exxxxxxx: send [3,"60",{}]
2025-06-02 23:57:54.252 INFO (MainThread) [ocpp] Exxxxxxx: receive message [2,"61","StatusNotification",{"connectorId":1,"errorCode":"NoError","status":"Charging"}]
2025-06-02 23:57:54.268 INFO (MainThread) [ocpp] Exxxxxxx: send [3,"61",{}]
2025-06-02 23:58:31.946 INFO (MainThread) [ocpp] Exxxxxxx: receive message [2,"62","MeterValues",{"connectorId":1,"transactionId":1748901452,"meterValue":[{"timestamp":"2025-06-02T21:58:32.000Z","sampledValue":[{"value":"15.393","context":"Sample.Periodic","format":"Raw","measurand":"Current.Import","phase":"L1","location":"Inlet","unit":"A"},{"value":"15.571","context":"Sample.Periodic","format":"Raw","measurand":"Current.Import","phase":"L2","location":"Inlet","unit":"A"},{"value":"15.631","context":"Sample.Periodic","format":"Raw","measurand":"Current.Import","phase":"L3","location":"Inlet","unit":"A"},{"value":"2064.211","context":"Sample.Periodic","format":"Raw","measurand":"Energy.Active.Import.Register","location":"Outlet","unit":"kWh"},{"value":"10843.000","context":"Sample.Periodic","format":"Raw","measurand":"Power.Active.Import","location":"Inlet","unit":"W"}]}]}]
2025-06-02 23:58:31.971 INFO (MainThread) [ocpp] Exxxxxxx: send [3,"62",{}]

I recognized that if a time schedule is set, it will be considered by the easee chargepoint. Without time schedule, charging will start immediately.

[olalid]

If I try to call the GET /v1/connection-details/{serialNumber} endpoint with the same headers as we use in the pyeasee lib/Home Assistant integration the call fails with a 400 error:
Bad request (400: {'type': 'https://www.rfc-editor.org/rfc/rfc7231#section-6.5.1', 'title': 'Bad Request', 'status': 400, 'instance': '/v1/connection-details/XXXXXX', 'traceId': '0HNCO8QSDANUM:00000001', 'errors': [{'name': 'serializerErrors', 'reason': 'The input does not contain any JSON tokens. Expected the input to start with a valid JSON token, when isFinalBlock is true. LineNumber: 0 | BytePositionInLine: 0.'}]} https://api.easee.com/local-ocpp/v1/connection-details/XXXXX)

If I remove the 'Content-Type': 'application/json;charset=UTF-8' header it works as expected and returns 404 when no OCPP config exists.
I have not seen this behaviour on any of the other APIs we use.

[BlueAndi]

Because the content-type header is related to the body data, I guess the JSON deserializer is called with empty message body data and causes "The input does not contain any JSON tokens. Expected the input to start with a valid JSON token, when isFinalBlock is true."

[olalid]

Yes, probably. In any case, I can work around it by using different headers with the get method. That header is redundant when doing get anyway.
Just wanted to point out that it is not consistent with the other APIs.

[olalid]

Seeing the same timeout here as mentioned above by BlueAndi.
TimeoutError: Waited 10s for response on [2,"94261b18-1c69-4af4-98cf-96d5db9abde2","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"Current.Export,Current.Import,Current.Offered,Energy.Active.Export.Interval,Energy.
Active.Export.Register,Energy.Active.Import.Interval,Energy.Active.Import.Register,Energy.Reactive.Export.Interval,Energy.Reactive.Export.Register,Energy.Reactive.Import.Interval,Energy.Reactive.Import.Register,Frequency,Power.Ac
tive.Export,Power.Active.Import,Power.Factor,Power.Offered,Power.Reactive.Export,Power.Reactive.Import,RPM,SoC,Temperature,Voltage"}].
So there is something that the HA OCPP integration and Easee charger does not agree on...

[mamunjo]

• Multiple key-value pairs is not supported for ChangeConfiguration.req in OCPP 1.6
• Too long json messages will be treated as corrupted messages, hence no reply.

[olalid]

So manually configuring the measurands seems to work better as described by BlueAndi above.
But is it not kind of strange that the charger responds "Accepted" to all of the possible measurands?
I.e. the OCPP integration tests which measurands the charger accepts by sending a ChangeConfiguration request for each possible measurand according to the standard, like this:

2025-05-24 21:39:36.194 INFO (MainThread) [ocpp] Exxxxxxx: send [2,"a42bb4cc-16df-4836-8333-7d941b26e532","ChangeConfiguration",{"key":"MeterValuesSampledData","value":"RPM"}]

And the charger responds "Accepted" on all of them:

2025-05-24 21:39:36.292 INFO (MainThread) [ocpp] Exxxxxxx: receive message [3,"a42bb4cc-16df-4836-8333-7d941b26e532",{"status":"Accepted"}]

I would assume not all of them are actually supported, right? RPM as in my example here is fan speed and since there is no fan...?

The standard states:
If "key" does not correspond to a configuration setting supported by Charge Point, it SHALL respond with
a status 'NotSupported'.

[mamunjo]

"key" is MeterValuesSampledData in this case, it is supported and accepted.

How to handle unsupported (or mix of supported and unsupported) elements in a CSL is not well defined. Our implementation will filter the measurands provided in the CSL with a list of supported measurands and apply those. You can see which measurands are enabled with a GetConfiguration.req.

We recommend users to stick to the supported subset of measurands.

However, it seems the OCPP integration has two ways of 'probing' for supported measurands:

1. Enable all of them and check which ones got enabled by sending a GetConfiguration
2. Enable one at a time, and check the ChangeConfiguration response (Accepted/Rejected)

We will look into fixing the issue where the charger does not respond to the ChangeConfiguration to enable all defined measurands and also change the response to Rejected if all of the requested measurands are not supported. This should allow both probing strategies to work.

[olalid]

Right, I misunderstood that about the key.
Sounds like a sound strategy and to me that fits more with how I understand the intention of the standard.

[muggel042]

After enabling DualProtocol connectivity mode, my Wallbox suddenly started to require authentication. This was a bit unexpected.

I could change access mode via app, but it looked like setting did get ignored (or just me being impatient)

For the moment I disabled OCPP again.

Anyways: Thanks a lot for really starting to work on a local implementation.

[skela]

Once you enable local OCPP, the OCPP server is responsible for these kinds of settings. The app should reflect this, disabling the ability to adjust the access levels (but there is no real time messaging from the system when you do change it so you would probably only see these limitations + banner explaining the situation if you were to refresh the app).

Depending on your choice of OCPP server, you might be able to add RFID keys, or enable free flow, which will remove the need for RFID keys.

[BlueAndi]

@leomwa The local OCPP provides now the possibility to start/stop charging. What will be the next step on easee side or what can we expect next?

[osulivanDE]

remember when local OCPP was required due to constant cloud API problems?

[developerfromjokela]

Hey @BlueAndi.

We are actively engaged in internal discussions and compiling a list of the most significant feature requests and bugs that require our attention. Planning for the third quarter is underway and we have taken the input - for example TxProfile being very important.

While the implementation of additional features may take some time, we are also considering implementing a bridge over Easee Cloud APIs. This would involve suggestions such as allowing higher rate limits for clients identified as hobbyists or smart home users.

We will rally internally and we will update the community when we've aligned the business priorities.

Please, no cloud bridges, when users want local, it must be local and work indefinitely.

[TheFreaker86]

The request by for sure the most of your customers is to have a fully locally controllable API with no cloud whatsoever. If I had known that the Easee Home works only with the cloud and is not locally controllable I would have chosen some other EV charger instead of trusting the recommendation of my electrician. So please (!!!) give an option for fully local control which works indefinetely.

[TheFreaker86]

We are actively engaged in internal discussions and compiling a list of the most significant feature requests and bugs that require our attention. Planning for the third quarter is underway and we have taken the input - for example TxProfile being very important.
While the implementation of additional features may take some time, we are also considering implementing a bridge over Easee Cloud APIs.
We will rally internally and we will update the community when we've aligned the business priorities.

@leomwa

And right now the Easee cloud backend doesn't work once again. I can't control the Easee Home which results in drawing more power that my PV provides, emptying my home battery and totally unnecessarily pulling energy from the grid which costs right now 4x as much as from my PV. This clearly shows in my Home Assistant Dashboards and log files. So I have to stop charging my car not to waste my money. And besides that, I run the risk that I maybe have to charge at a public charger while on the road which costs insanely much more! I'm slightly angry! So you - Easee - again prove your paying customers point of demand of a local API. I implore (!!!) you - as a company - to stop internally discussing about IF you will provide a local API at last? Instead just do it, and be transparent about your decision and roadmap in a timely manner.

If this goes on, I'll buy some other EV charger that does not bother me with those troubles. Almost needless to say that I won't recommend an Easee charger to anyone, even if they don't run something like Home Assistant or IObroker. Just because the Cloud API is needed in any case, not only for those who run some Smart Home platform.

EDIT: And I add some other thoughts that came across my mind since I originally posted: I just don't unterstand why a local API is not a no-brainer for Easee. You surely save a not insignificant amount of money and effort for not having to maintain the cloud service as it is right now. I'm not suggesting you should can the cloud service entirely. But if there is some option to opt out of cloud services in each Easee charger you can add a notification sent to your cloud that there has been an opt out. And then you have a metric that you can plan your cloud hard- and software maintaining expenditures accordingly.

And finally the question I wan't to ask: Why are you apparently still discussing the IF of the local API, not the when and how? I reckon many others are interested in the answer too. (I put the question in bold letters for better visibility in my post)

[osulivanDE]

Just for fun because of this discussion. Take a look at the current Cloud API status:
https://status.easee.com/incidents/xf72jqz8l203

[developerfromjokela]

I propose for final release to have local API toggle available via bluetooth, so you don't have to enable local API using the cloud.

[1onar]

We want to control and monitor our Wallbox in a secure and reliable way, especially when surplus solar power is available.

Yes, I’m aware of AMP and Equalizer – but I already have components in my photovoltaic system that provide all the necessary data. I don’t want to rely on another device that connects to the cloud again.

If you release a new device that still depends on the cloud, many people (including myself) won’t buy it – and I won’t recommend Easee anymore.

On the other hand, introducing a local API would have a huge positive impact – especially in smart home communities. People would gladly recommend Easee, and I, for example, would buy a second charger without hesitation.

Please consider this seriously.

[cschlipf]

Amp and Equalizer also are depending on the cloud service.

[developerfromjokela]

Amp and Equalizer also are depending on the cloud service.

I recall seeing a claim that equalizer can run locally if in same wifi with charger. But local API for all products is what we're looking for.

[cschlipf]

Well - if that would be true it means that they have a fully functional working local API that allows surplus charging. Then just release it.

[skela]

Amp / Equalizers communicate with the chargers locally once they are setup, but any configuration has to happen for those products via the cloud.

You should already be able to monitor an Easee wallbox using local OCPP.
As @leomwa mentioned earlier Local / Native / Direct OCPP is actively being developed, and we hope to have additional features available later this year.

[agrauballe]

Highly a supporter of local API.
My only use case is basically only to set dynamic_circuit_limit where 0A means no charge. 6A for minimal charge and 16A for full.

Also I will highlight the option being able to control this via the local API while an external operator is set for the charger. I do see in the docs that Easee should be set as operator, is it not possible to do both?
At least in Denmark this is used to get tax exemption. Basically they only need to obtain metering values. Today we can still control the charger via cloud (at least stopping/starting and setting dynamic currents) while an external operator is set. This must still be possible via the local API as the charge settings via the operator often leaves us with cloud and not a whole lot of options. Much better to control this ourselves from e.g. Home Assistant.

Also in favour of a Home assistant integration unless somebody in that community is willing to do that either native or via HACS.

[cschlipf]

More than 5 hours downtime.

Guys, no one can recommend your chargers anymore without a local API. And if no one recommends you anymore, what happens to the company and finally to the cloud in the end? It can't be in your own will to not give us a local API that allows to control the charger for surplus charging.

[cschlipf]

We are investigating surge in traffic home automation systems originating from certain countries and are gradually allowing / disallowing traffic to try to narrow down specific clients that we have to permanently block.

If there only could be a solution to this traffic surge. Ideas anyone? ;-)

[1onar]

Suggestion: Monetize the cloud – but give users their local API!

Why not offer the cloud features as a paid subscription? That way, only those who actually want or need cloud functionality cover its cost.

But please, give people a proper local API!

Ignoring the smart home community could seriously harm your business in the long run. This is a growing, passionate user base that influences purchasing decisions far beyond tech-savvy circles.

Even AI tools like ChatGPT warn users against choosing Easee, precisely because there’s no local API and only unreliable workarounds exist. If even an average consumer sees this, you’re already losing trust – and future customers.

[developerfromjokela]

also consider this, you're gonna pay a subscribtion to locally access your device that you own, what happens when easee goes bankrupt? your expensive charging box becomes a expensive decoration on your wall. Is that whay you really want?

Like I wrote:

👉 I want a FREE LOCAL API.

👉 The CLOUD API could be a paid premium service.

That’s my whole point.

The idea is: Easee can only monetize the cloud API if the local API is free. Otherwise, there’s no justification for charging customers to access their own devices – especially not locally.

If some managers only react when they see dollar signs, then maybe this is a way to make the local API happen – by showing that the cloud can still be a revenue source without locking users in.

Because as you said: if Easee goes bankrupt, the cloud dies with it – and then we’re left with a useless charger on the wall.

A free local API would guarantee long-term usability.

They can do whatever the like with their future models but devices already purchased and installed should work like advertised. If cloud was advertised as a free service, it should stay.

Local API was promised by easee and many people bought on that promise. So they better do it soon or else the community will just reverse engineer its way to easee products. Patience can't be 4 years, what kind of development team can't push a local API in 4 years?

I think easee does care about their image, but tried to stash this local API away until we and a lot of other users got very upset. Not gonna lie, this already left a bad taste on easee. That's not gonna go away anytime soon if they're not willing to do a 360 with their cloud-centric approach.

[scspijker]

Suggestion: Monetize the cloud – but give users their local API!

Why not offer the cloud features as a paid subscription? That way, only those who actually want or need cloud functionality cover its cost.

But please, give people a proper local API!

Ignoring the smart home community could seriously harm your business in the long run. This is a growing, passionate user base that influences purchasing decisions far beyond tech-savvy circles.

Even AI tools like ChatGPT warn users against choosing Easee, precisely because there’s no local API and only unreliable workarounds exist. If even an average consumer sees this, you’re already losing trust – and future customers.

Can you please put suggestions on https://feedback.easee.com/ and keep this issue clean for development? You are spamming all developers helping/assisting on this issue.
Thanks!

[developerfromjokela]

Suggestion: Monetize the cloud – but give users their local API!

Why not offer the cloud features as a paid subscription? That way, only those who actually want or need cloud functionality cover its cost.

But please, give people a proper local API!

Ignoring the smart home community could seriously harm your business in the long run. This is a growing, passionate user base that influences purchasing decisions far beyond tech-savvy circles.

Even AI tools like ChatGPT warn users against choosing Easee, precisely because there’s no local API and only unreliable workarounds exist. If even an average consumer sees this, you’re already losing trust – and future customers.

Can you please put suggestions on https://feedback.easee.com/ and keep this issue clean for development? You are spamming all developers helping/assisting on this issue.

Thanks!

We're discussing here local API, where should we discuss then if not here? Don't see any easee devs here chatting past original post and few replies. Maybe time to do an update on your progress?

[GrimmiMeloni]

Note that EVCC does not charge for a sponsor token because of difficulties maintaining an API. They charge for a sponsor token because the vendor does not sponsor the project.

Yes, it's both. I am pretty sure that one of the EVCC devs said that the Easee API is a difficult one.

Given I’m the primary maintainer on EVCC side that statement probably stems from me. The main reason why I think like this, is that the API is asynchronous. There’s nothing specifically bad about the cloud itself, apart from of course it being off-line, but it’s more that we have different channels for sending and receiving.

Technically what we do as we send commands to the cloud API, but we never get actual responses, onlz confirmations about commands being received. What happens physically is then later signalled by the charger itself via a different channel.

in simple terms, think about you want to tell Bob to do something, but instead of being allowed to talk to Bob directly you always have to tell Alice to tell Bob what to do. And Alice will always just reply positive and say something like “OK I will tell Bob”. But if she ever told Bob or not, you don’t know until the point where Bob at some point replies to you and says “I did what you asked me to do”. This indirection is what makes things error prone.

Easee would not even need to build OCPP, they simply need to expose the interface that their cloud backend uses to talk to the chargers. But I guess that will be wishful thinking for the foreseeable future.

[skela]

Work on direct OCPP is underway, we can't wait to share more information once we have it.

[developerfromjokela]

@leomwa With direct ocpp, what's chargebox behavior when OCPP server is unreachable or becomes unavailable? Can it be configured to allow charging regardless? Please make this configurable on user side if it's not already.

[skela]

Our chargers have settings that already allow that. Slightly unsure whether these apply when connected to a local OCPP server, but I think so.

[TheFreaker86]

Any updates on the local API? A quick web search yielded nothing new or promising. EVCC only has still the cloud API in their documentation as well, most likely because the lack of it.

[developerfromjokela]

Apologies for the lack of updates @TheFreaker86.

We are dogfooding TxProfiles and Clock-aligned metering. We believe this enables a lot of more options especially for smart home systems. We will update more on the rollout plan when we are closer with an RC.

Are there any plans to allow local interfacing with the Equalizer?

[leomwa]

Not yet. 🤔

[olalid]

The equalizer seems to already broadcast some data packet over WiFi after each measurement data is output from the meter, but it is encrypted. Is there any chance we can get a setting where the user can choose to disable the encryption so we can read the contents of that packet? Or add an additional non-encrypted packet?

[mdb-mdb]

Hi any update on the local api yet?

My electricity company charges for peak usage and I had a massive usage peak yesterday. It was because home assistant/evcc couldn't reach the easee cloud and the charger just did its own thing.

[dvdkrtz]

Hi any update on the local api yet?

My electricity company charges for peak usage and I had a massive usage peak yesterday. It was because home assistant/evcc couldn't reach the easee cloud and the charger just did its own thing.

Welcome to the easee club.