Replies: 26 comments 73 replies
-
|
Thanks for your proposal and the feedback to this change requests.
Yes it would solve the Problem, If this allows evcc or Home Assistent tonget local Access tonthe charger
This would be a great binus and maybe for some people a game changer .
Maybe a checkbox to enable OCPP in the charger settings
A default REST API or MQTT API would do it |
Beta Was this translation helpful? Give feedback.
-
|
Feedback form Here's the form. |
Beta Was this translation helpful? Give feedback.
-
|
Another function that is also very useful is switching the phases. 1 Phase/3 Phase, also local authentication would be awesome. Edit, sorry, just saw your form consider it filled out. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
First of all I'm really glad you're adressing this topic. Thanks for that!
|
Beta Was this translation helpful? Give feedback.
-
|
Original feedback reporter here, stunned that you are picking this up and greatly increases my trust in the Easee brand!
Yes, faster and more reliable control with less cloud/internet dependency.
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.
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.
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.
No opinion as I fully recommend following open standards. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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:
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. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you that the topic is taken up again, I honestly didn't expect it anymore.
Yes, it would solve it, because local smart charging is my main focus. Following a standard is in general a good way.
This would be great for the eassee wallbox owners and may be another good point for others to decide to choose a eassee wallbox.
You could add e.g. an expert mode checkbox to show/hide the complexity in the UI.
The smart charging feature.
RESTful with swagger and MQTT (incl. HA automatic discovery). |
Beta Was this translation helpful? Give feedback.
-
|
Will this solution be compatible with an "external" operator configured in the cloud? (Since that one uses OCPP as well if I understand correctly) |
Beta Was this translation helpful? Give feedback.
-
|
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:
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. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
I created a python script for easier playing around with it. If someone is interested in, you will find it here: The script uses 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. |
Beta Was this translation helpful? Give feedback.
-
|
First results with Home Assistant and the OCPP integration:
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: The last send() routine was never answered and therefore ended in a timeout. |
Beta Was this translation helpful? Give feedback.
-
|
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: If I remove the 'Content-Type': 'application/json;charset=UTF-8' header it works as expected and returns 404 when no OCPP config exists. |
Beta Was this translation helpful? Give feedback.
-
|
Seeing the same timeout here as mentioned above by BlueAndi. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@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? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Highly a supporter of local API. 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? Also in favour of a Home assistant integration unless somebody in that community is willing to do that either native or via HACS. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.




Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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)
Proposal: use native OCPP for local integration
We propose allowing activation of local OCPP (Open Charge Point Protocol) on Easee chargers. This would:
Key constraints:
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
Questions for discussion
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 👇
Beta Was this translation helpful? Give feedback.
All reactions