OpenEVSE charger with loadbalancing?

I’m using emonTx to monitor energyusage with import/export in a house fitted with solarpanels.

Now we are about to buy our first all electric car and are planning to install a charger at our home. In Sweden we use three phases and I think we have 20A, so … up to 13-14 kW ?

My electrician says though that we really need to have load-balancing on the charger to limit the power to it based on other usage in the house.

Does the charger from OpenEnergyMonitor offer this function ?

No, I’m afraid the OpenEVSE does not have load balancing. This is a feature which is being discussed and may be implemented in the future:

Currently, you can set the current manually via the OpenEVSE web interface,

I’m probably going to implement this externally for now using a python script using mqtt to receive the house load and openevse current and then based on some parameters, potentially ramp down the charge current.

I can already limit my Eddi but with the new heat pump, I might potentially need to limit the car charger.

I could also limit my battery stack; that would be a fairly minor change to how I control it now anyway but I’ll get the car one working first.

FYI we recently added a new feature to OpenEVSE called current shaper thanks to a contribution from KipK. You should be able to use this to implement load balancing.

2 Likes

When is this likely to be available?

I’m currently on the latest firmware (8.2.0EU/4.1.4).

I don’t think this is part of a release yet, but definitely is part of the latest pre-release if you want to test.

I downloaded it earlier and have set it up using the same MQTT topic for Eco/ PV divert.

When I get time I’ll set the threshold very low and see what happens.

Unfortunately the car didn’t charge on timed last night so back to the release version I think otherwise the wife will get cross.

Seems MQTT disconnected and I’m guessing that had something to do with it. House limit was set to 23000W but didn’t get anywhere near that.

Looking at the code at it seems that there is a 6 minute time limit at which it’ll halt the charge if no power received. It’s really frustrating how poor the aerial is on the ESP32; it’s the only item of kit I have that routinely drops out yet my phone gets an excellent strength right next to the unit.

I don’t understand the code adequately enough to understand if the shaper is enabled, it overrides the timed charge. I’ve reverted back to 4.1.4 for now as the car has to charge tonight else I’m in trouble.

All the various features are intended to work with each other, so the current shaper will place upper limits on what the timer/divert can do but otherwise will let them operate as before.

The WiFi management code is next on the list to rework, I think there are many improvements that can be made and can see that with the current shaper this would make it more annoying, but one of the key differences between what the current shaper does and the divert is that the current shaper is more for safety situations rather than efficient use of power.

OK, so installed the released 4.1.5 today which went ok and enabled the Current Shaper with a limit of 23000 W and using the same feed for the Solar PV divert panel.

My charger is predominantly on a timed charge 00:30 to 04:30 for Octopus Go.

Monitored the system when it went past 00.30 and it failed to start charging. The house power feed was indicating around 12kW so nowhere near the limit. After three minutes of refusing to charge, I disabled the Current Shaper via the web interface and lo and behold, charging commenced.

I don’t think I’ve configured wrong. Seems the current shaper doesn’t work with timed charge.

@greentangerine ,
Why are you duplicating to the Divert mode the Mqtt feed dedicated to shaper?

The problem could comes from there. Have you disabled Divert while doing this?

Also if you were using the +I/-E divert, it expect negative values , but shaper needs positive one

I’m using Shaper with timers only without any issue for months now, so I don’t get why it wouldn’t work.

Please post those status value from openecvse mqtt or /status http endpoint when charge is activated with shaper but doesn’t start shaper_live_pwr
shaper_max_pwr
shaper_cur
shaper

I haven’t got the DemandShaper app enabled - it’s set to off.

My unit is generally only set to Normal with a timed schedule also set.

I will manually override occasionally if I have to get a charge and will use Eco when appropriate (but always enable and then disable later in the day plus that won’t be a thing until next year now).

I’ll put some screenshots below. When I enabled the Current Shaper, I used the same MQTT topic as I use for Eco/PV Divert as that is the house load - negative when exporting and positive when importing.

On the occasion I mentioned in my last post, it was just gone 00:30, the car should have started charging as the house load was circa 12-13 kW (as shown using the same MQTT feed) but it didn’t.

It stayed in ‘Waiting - EV Connected’ when it would normally switch to ‘EV Connected’ dead on 00:30 and then switch to ‘Charging’ about 10 or 11 seconds later.

When I disabled Current Shaper a couple of minutes later, the unit immediately started charging.

I haven’t had the time to look at your code yet. My guess is the claim somehow stops timed charging.

I’m only enabling it because I theoretically need to control my house load overnight during the Go period and total load could exceed 100A now I have an ASHP that can draw 36A. I can control the Eddi diverter (which is also used to boost the thermal stores if necessary) so have set the limit on that to 100A and by doing the same on the OpenEVSE would prevent the house ever going over the main fuse limit.

I see you have just posted again whilst I have been typing this so will see if I can get those values.



So your problem comes from there. Shaper expect positive value not negative.
It’s logical it didn’t start the charge, it thought there was no current available then

I’m not logging those values to a feed so I’ll do so now and get the values when I next try it - possibly tonight. If there are any other OpenEVSE topics I’m not logging but would be useful let me know - the ones currently logged are shown below.

Not sure I understand what you’ve said.

The house values would have been positive at that time i.e around +13000 - the screenshot I’ve just posted was now.

Looking at your code, even if the house is exporting (which possible, as the battery system will try and maintain a slight export i.e. the feed would show around -10W) then your available current calculation would reflect that i.e round(((23000 - - 10) / 240) + (0)) i.e 95A

I’ll log the values from tonight and see what that shows.

I thought on what you said you were publishing it negative.

Also the Divert related data would be interesting to have.
You can just publish here the http://openevseip/status when it’s not working

I think I’ve resolved it.

Seems the Current Shaper isn’t picking up the topic value entered (despite it being the same one used for Eco/Divert and that bit works fine).

I’ve explicitly published the input to MQTT and used that topic name which is now showing in the shaper_live_pwr input.

We’ll see what happens later tonight but hopefully the car will charge.

Car charged fine. shaper_cur got down to 71A but no lower i.e a headroom of 39A but the ASHP wasn’t running and only one of the two dishwashers and neither washing machine so the current limiting capability might well be need over Winter.

The only issue I have is the poor WiFi signal the ESP32 unit has which might lose MQTT and hence current shaper will shut the charging down. Everything else in my house (and we’re looking at circa 50 WiFi clients across 4 meshed TP-Link units) has a great signal strength.

I’m looking at one of the external antennae hacks as a solution to that.