Hi Guys, Looks good (just had a quick play with it)
For testing and for more advanced users it would be good to have the output to not just be a charger but an entity or local device too so we can use it to drive other integrations ?
Also metering, again it would be good to have it as an entity. I have RS485 metering connected directly to my solar but the figures are distributed via an entity value to a number of other templates and devices.
Courty
Thanks for the feedback @Courty.
As for the metering: I think this should already be the case, depending a bit on your exact use case. When selecting the “meter” there’s also the option to provide “advanced options”, which allow you to provide any entity as long as it represents a power state class. (I use this personally for manual testing as well)
As for the charger: noted. Am I correct to understand that you would like to be able to do something like the following:
Am I understanding you correct here? Just out of curiosity, what benefit would you see here in comparison to just natively implementing the chargers like we do now?
hi @dirkgroenen I’ve tried your project and did my best to see if I could make it work with GitHub - firstof9/openevse: OpenEVSE Integration for Home Assistant
I have an OpenEVSE charger (one of the few which are real open hardware).
Unfortunately I think I am stuck to the best of my capacity. I was wondering if you are interested to see if this platform could be supported too!
I can most certainly have a look at that! Can’t promise an ETA a this point, but I’ll make sure to open an issue in the Github Repo so I can put it on my backlog list.
Hi @dirkgroenen . Would it be possible to add the hass-AMS-reader integration as a meter. I think you get all the sensors you need from there. I got a HAN-port reader on my meter and send the data to hass-AMS-Reader and i get like 14 entities, current by Phase for example.
Nice project with big potential. Thanks
Fredrik
Hi Fredrik! Are you talking about this (MQTT) integration? Home Assistant configuration | amsleser.no Wiki
I can probably add it (haven’t checked the docs and therefore exposed entities yet), but in the meantime you can also use the “manual meter” approach to select the right entities already exposed by your integration.
If you can confirm the integration I’ll have a look at the docs and see what I can do.
Hi.
No, I use this one, hass-AMS-reader.
It’s a HACS integration. I read values from the HAN-port into a M-BUS → Serial converter ->HA.
Got a lot of sensors.
Gotcha. Someone else has done some work on creating a PR for the MQTT version of this reader already, which is pending over here: https://github.com/dirkgroenen/hass-evse-load-balancer/pull/59.
I’ll see what we can do to get that merged, as well as possibly the other. In the meantime I would suggest to use the custom meter support to get going.
Problem I think we have we this meter, as well as some others, is that there’s no distinctive power measurement per phase which indicates if we’re consuming or producing power. That might require some additional work to get things going.
Sweet. I tried the custom meter option but the problem is that I can’t get a voltage by phase sensor, since EVSE don’t pick hass-AMS-reader, and by that I assume the integration will get a hard time calulating the current. I have another power meter ,that came with the PV, and that one presents active power by phase. (+) values when exporting and (-) while importing. EVSE-load-balanser reads this one but the problem is that this powermeter don’t have a by phase voltage sensor:-(.
So I’m stuck 
//Fredrik
problem is that I can’t get a voltage by phase sensor, since EVSE don’t pick hass-AMS-reader
Not sure if I get what you’re saying here. Are you saying the the integration doesn’t allow you to pick the Voltage Sensors exported by your HASS-AMS-READER integration?
i would expect you to be able to select the three Phase Voltage sensors as shown in your first screenshot. If not, please go to HASS’ “Developer Tools → States” and show me the attributes for those sensors. An example:
With the active power provided by your other sensor you could consider combining the two. Using power from one and voltage from the other (assuming they both have the same’ish intervals on which they output data).
Hi again.
No, the integration dont´t pick the hass-AMS-voltage sensor. Picks up a lot of other voltage sensors but not them.
States like this
Thank you for your efforts
//Fredrik
s
Your screenshot is actually showing the 3 voltages, one for each phase (Lx).
Using the “Advanced Energy Meter” approach (during setup of the load balancer) you can select these sensors for each phase.
Screenshot below is a single-phase setup, where you’ll need to provide the power consumpion, production and voltage sensors.
The extension expects a separate power consumption and production sensor. Not the most ideal design I’ve realised, but for now we’ll have to work with it.
If you’re sure that your “active power” produces a negative value when it’s consuming power and a positive value you could create HASS Helpers to turn those into separate entities. For example using a “value template” which normalises the values:
# Consumption Phase 1/A
{% set power = states('sensor.power_balance') | float %}
{{ power | abs if power < 0 else 0 }}
# Production Phase 1/A
{% set power = states('sensor.power_balance') | float %}
{{ power if power > 0 else 0 }} # returns
Hi.
Think I got a solution. The voltage sensors I got lacked device class, and because of that they didn’t show up in the dropdown in the loadbalancer integration. I created helpers for them with device class voltage and now they are visible. Also created helpers for power consumption so I think I’m good to go😁
// Fredrik
Hi,
Just installed the 1.0.5 version. Using a HomeWizard P1 energy meter and a Easee EV charger. In general it works well and the “Available current” for each phases are always displayed correctly. Charger limits are updated fine when reduced (lowering charger “Output limit”). However, when there is more available current again the load balancer sometimes fails to restore the limits to give the EV charger more power. I have tried to look at the debug logs and can see “Charger settings was updated too recently …” entries but then nothing happens when you would expect a call to be made to raise the limitation. (I have reduced the configurable delay to 2 minutes). I can see a log entry: “WARNING (MainThread) [pysignalr.client] No client method with the name ‘CommandResponse’ found.” but don’t know if it is related to the problem seen.
Any idea what could be wrong? Perhaps the somewhat shaky Wi-Fi connection to my charger is to blame? But it appears it always succeed in reducing available current but not restoring it (and I do not see any log of ever an attempt being made).
Let me know if there is anything I can do to understand this problem.
Thanks for testing @kajott! Would you mind sharing the logs with me so I can have a look at them? I was recently working on this as part of [#60] Resolve non-increasing charger current by dirkgroenen · Pull Request #63 · dirkgroenen/hass-evse-load-balancer · GitHub and from my own testing (as well as some testing from a community member) it now worked properly. Would be curious to see what’s happening in your logs.
@dirkgroenen I don’t find anything strange in the logs. Will share logs once I experience the problem again. In the debug logs it would be great to see also the available current (not just the previous and new limitation).
Hi again @dirkgroenen !
Tonight when charging my car EVSE correctly reduced loading speed down to 12-13 A / phase as the house heat pump was running (using about 6 A per phase out of the available 20 A). However, EVSE did not raise the allowed current when the heat pump stopped at 4 AM. In Hass GUI I can see that the “Available current” for all phases goes from 1-2 A to 7-8 A at 4 AM and as I have tuned the timing to 2 minutes I would expect it to raise the allowed charge current at 4:02 but that didn’t happen. As can be seen in the logs below there is a “manual override” at 01:16 but I can ensure there were no manual override made. Did EVSE fail to set the 12 A limit and then thought the 13 A limit was a “manual override” and then stopped to set new limits?
2025-10-10 01:15:56.463 DEBUG (MainThread) [custom_components.evse_load_balancer.coordinator] Charger settings was updated too recently (minimum delay). Last update: 1760051739.444288, current time: 1760051756.460609. Minimum delay: 20 seconds
2025-10-10 01:15:57.463 DEBUG (MainThread) [custom_components.evse_load_balancer.coordinator] Charger settings was updated too recently (minimum delay). Last update: 1760051739.444288, current time: 1760051757.462664. Minimum delay: 20 seconds
2025-10-10 01:15:58.466 DEBUG (MainThread) [custom_components.evse_load_balancer.coordinator] Charger settings was updated too recently (minimum delay). Last update: 1760051739.444288, current time: 1760051758.463934. Minimum delay: 20 seconds
2025-10-10 01:15:59.468 DEBUG (MainThread) [custom_components.evse_load_balancer.coordinator] New charger settings are lower, apply immediately for safety. Current settings: {<Phase.L1: 'l1'>: 13, <Phase.L2: 'l2'>: 13, <Phase.L3: 'l3'>: 13}, new settings: {<Phase.L1: 'l1'>: 12, <Phase.L2: 'l2'>: 12, <Phase.L3: 'l3'>: 12}
2025-10-10 01:15:59.468 DEBUG (MainThread) [custom_components.evse_load_balancer.coordinator] New charger settings: {<Phase.L1: 'l1'>: 12, <Phase.L2: 'l2'>: 12, <Phase.L3: 'l3'>: 12}
2025-10-10 01:15:59.469 INFO (MainThread) [custom_components.evse_load_balancer.coordinator] Emitted charger event: action=new_charger_limits, new_limits={<Phase.L1: 'l1'>: 12, <Phase.L2: 'l2'>: 12, <Phase.L3: 'l3'>: 12}
2025-10-10 01:15:59.473 DEBUG (MainThread) [custom_components.evse_load_balancer.power_allocator] Updated applied current for charger 01K6N04GK25TPZECC7Y3DWC153: {<Phase.L1: 'l1'>: 12, <Phase.L2: 'l2'>: 12, <Phase.L3: 'l3'>: 12}
2025-10-10 01:16:00.782 WARNING (MainThread) [pysignalr.client] No client method with the name 'CommandResponse' found.
2025-10-10 01:16:01.284 WARNING (MainThread) [pysignalr.client] No client method with the name 'CommandResponse' found.
2025-10-10 01:16:07.112 WARNING (MainThread) [pysignalr.client] No client method with the name 'CommandResponse' found.
2025-10-10 01:16:11.142 WARNING (MainThread) [pysignalr.client] No client method with the name 'CommandResponse' found.
2025-10-10 01:16:15.488 INFO (MainThread) [custom_components.evse_load_balancer.power_allocator] Manual override detected for charger. New requested current: {<Phase.L1: 'l1'>: 13, <Phase.L2: 'l2'>: 13, <Phase.L3: 'l3'>: 13}
It indeed seems to have been thinking that 13A was a manual override, as it expected a charger limit of 12A. Thinking out loud it might be that your charger didn’t apply the request of lowering the limit to 12A wat 01:15:19. Causing a request verifying limits at 01:16:15 to still see 13A and thinking that the charger “manually overrided” the 12A.
Obviously that shouldn’t happen. It might be that the 15S is just to quick for the charger to apply the changes and report this back to HASS. Increasing this delay might be a solution here, assuming it does apply the charge current.y
Do you know if the charge was applied without any issues though? The No client method with the name 'CommandResponse' found. are not by any change related to a failure of the charger?
Can you have a look at the Easee dynamic_charger_limit sensor and show its changes during this timewindow? Did it correctly go to 12A?
Hi,
I have a wallbox charger (in fact I have 2)
But I need some help to add the definition of the py file
Hi @RienduPre! If you have experience with Python and Home Assistant Components the best starting point would be to have a look at:
The idea in essence is to get an understanding of the sensors and services exposed by Wallbox and tell EVSE about those. That’s what you’ll see in the easee_charger.py implementation.
You can give it a shot and open a PR. If this is out of your comfort zone open an Issue requesting the feature and I (or someone else) can have a look at it 