EVSE Load Balancer: A Universal Load Balancer for your EV Chargers

Share your Projects! Custom Integrations
1

Hey everyone,

I wanted to share a custom integration I’m been working on to simplify EV charging for Home Assistant users, specifically (but not limited) at this stage: Load Balancing.

Like many EV Charger owners there’s a need to balance the EV’s charging with household power usage to avoid overloading the main fuse. I personally don’t like having an endless number of P1 devices in my cabin, especially not if there’s already a stable Home Assistant service running.
Instead of going down the road of harder-to-maintain automations I decided to build Hass EVSE Load Balancer: a lightweight, native component that turns Home Assistant into a smart, self-adjusting EV load balancer.

The idea is simple: if you already have energy sensors (like grid consumption, production, and voltage, or a DSMR smart-meter) and a charger that can be controlled via Home Assistant, you shouldn’t need vendor-specific dongles, extra P1 meters, or fragile automations. This component monitors your live power usage and dynamically adjusts the charging current or phase configuration of your EVSE — helping you protect your connection and maximize charging speeds when possible.

It’s designed to be easily extendable, supporting all kinds of different meters and chargers. It depends on other integrations to make sure the actual communication with the chargers or meters is properly maintained as well, for example easee_hass and DSMR Smart Meter.

More information on how it works and how it can be extended can be found in the repository:
:link: GitHub - dirkgroenen/hass-evse-load-balancer: Adjusts your EV Charger's current using existing sensors - no vendor lock-in, no extra devices.

Note that I’m releasing this quite early in its testing - so consider yourself a beta tester. I have it up and running at home (DSMR + Easee Charger), but I’m very interested in getting more adoption info and feedback. Definitely keep an eye out on what it’s doing at first and let me know if it’s behaving weirdly.

I’d love for others to give it a spin and let me know how it works in your setup. I’m keen to hear your feedback, edge cases, ideas, and real-world experiences. If it turns out useful to more people, I’m happy to continue building it out.

The current “load balancing algorithm” tries to find a balance between a) not being to hysteric, b) getting as much as of a charge as possible, and c) obviously not overloading the fuse. It does therefore for example allow for short periods of small overcurrents, like your circuit breaker also does.

Other features I have in mind to include are:

  • Add an input field to manually override the charger’s current
  • Add a toggle to force the charger to only use PV surplus

Eventually I have some other things in mind to make this an all-in-one package, allowing to also:

  • smart scheduling based on Dynamic Tarrifs
  • control and balancing amongst with other loads. Being either other chargers, or e.g. water heaters

Thanks for checking it out! Looking forward to any form of early feedback and input :slight_smile:
– Dirk

1 Like
2

Hello,

This seem to be awesome! I’ve just bought an Amina S which connects to HA through Zigbee2MQTT. I’m not a programmer but I’ll have a go at implementing the charger.

I’m using SlimmeLezer+ with ESPHome for energy meter. Would you suggest to use the custom configuration or should I give it a go to implement the ESPHome? I’ve not used the DSMR but after a quick look it seems to have a lot in common.

Jon

2 Likes
3

Sorry - bit late of a reply. I noticed your PR coming through and will try to have a look at it in the next few days! Thanks already for taking the effort :slight_smile:

I’m currently doing a bit of a rework of the coordinator and power balancer. Especially as I noticed a bug in the code which causes the chargers to be increased way too late after a decrease. The change also makes the code a bit more future proof. I’ll see if I can merge your PR first, but if not I’ll do it after these changes are done and merged. Hopefully this weekend :crossed_fingers:

As for the SlimmeLezer+ implementation, you can definitely use the custom sensors - which will just do the job. The DSMR implementation (or other Meter implementations) are simply there to make life a bit easier.

I have no practical experience with ESPhome and the SlimmeLezer+ device, but as long as they expose a unique device, identifiable named entities, and a domain that’s equal for all SlimmeLezer+ devices the implementation could be straightforward.

The only problem I might see, but you’ll know this better then me from experience, is that you’re dependent on user configurable ESPhome device configuration files, which name the device and expose sensors? If that’s the case it might be hard to provide a “one-fit-for-everyone” implementation.

4

This is very cool and I was actually looking for a generic version of this. I think the main challenge here is that if the server fails or the charger is unreachable what happens? The risk is that other loads could increase during this time but without the server telling the charger to curtail the main breaker could get tripped. If this isn’t a big deal to you on the super rare chance it happens then great you can ignore the rest :slightly_smiling_face:

Most of the commercial ways to do this either use a direct serial connection to a CT to measure the current (Siemens/span/most do this) and then activate a contactor from the same device that is measuring the current or they use a master/slave pattern where if the master fails to communicate with the slave then the slave won’t function (Tesla does this with their car chargers).

Afaik the only way to truly do a decoupled software based system is the second option but I think that requires extra software on each client device to essentially require a keep alive ping to the server. Unfortunately I don’t have firmware access to most of the loads in my house so this feels like a dead end to me.

5

I might have misunderstood “Enable offline mode”. But isn’t this what you want?

Enable offline (binary)

Enable offline mode when connection to the network is lost. Value can be found in the published state on the enable_offline property. To read (/get) the value publish a message to topic zigbee2mqtt/FRIENDLY_NAME/get with payload {"enable_offline": ""}. To write (/set) a value publish a message to topic zigbee2mqtt/FRIENDLY_NAME/set with payload {"enable_offline": NEW_VALUE}. If value equals enable enable offline is ON, if disable OFF.
Time to offline (numeric)

Time until charger will behave as offline after connection has been lost. Value can be found in the published state on the time_to_offline property. To read (/get) the value publish a message to topic zigbee2mqtt/FRIENDLY_NAME/get with payload {"time_to_offline": ""}. To write (/set) a value publish a message to topic zigbee2mqtt/FRIENDLY_NAME/set with payload {"time_to_offline": NEW_VALUE}. The minimal value is 0 and the maximum value is 60. The unit of this value is s.
Offline current (numeric)

Maximum allowed amperage draw when device is offline. Value can be found in the published state on the offline_current property. To read (/get) the value publish a message to topic zigbee2mqtt/FRIENDLY_NAME/get with payload {"offline_current": ""}. To write (/set) a value publish a message to topic zigbee2mqtt/FRIENDLY_NAME/set with payload {"offline_current": NEW_VALUE}. The minimal value is 6 and the maximum value is 32. The unit of this value is A.
Offline single phase (binary)

Use single phase charging when device is offline. Value can be found in the published state on the offline_single_phase property. To read (/get) the value publish a message to topic zigbee2mqtt/FRIENDLY_NAME/get with payload {"offline_single_phase": ""}. To write (/set) a value publish a message to topic zigbee2mqtt/FRIENDLY_NAME/set with payload {"offline_single_phase": NEW_VALUE}. If value equals enable offline single phase is ON, if disable OFF.