Battery Charge Throttle

[chris01942]

Hi Dave, once again thanks. This is exactly what I've wanted for a while, especially for solar charging. I've just implemented the helpers, code & automation and seems to be working. Today is forecast to be a decent solar day, so can test it out. One question: Will the battery throttle work alongside Nathan's energy management during off-peak charging? I'm presuming if it does, to keep the EM custom charge profile toggled off?

Thanks, Chris

[Dave Foster]

Hi Dave, once again thanks. This is exactly what I've wanted for a while, especially for solar charging. I've just implemented the helpers, code & automation and seems to be working. Today is forecast to be a decent solar day, so can test it out. One question: Will the battery throttle work alongside Nathan's energy management during off-peak charging? I'm presuming if it does, to keep the EM custom charge profile toggled off?

Thanks, Chris

Hi Chris,
Yes it’ll work fine alongside Nathan’s code (I use it too) as long as you keep custom charge profile off.

You’ll have seen you can set your own charge profiles for night and day as to your preference, but as always if you can think of any ways to improve it, let me know.

[chris01942]

Hi Dave, everything seems to be working except the charge current is changing when SoC >80%. I have the two jinja files in a folder "config/custom_templates", but I notice in the comments section something about a script. Looking in automation>scripts I have no scripts to be run??

Thanks Chris

[Dave Foster]

Hi Dave, everything seems to be working except the charge current is changing when SoC >80%. I have the two jinja files in a folder "config/custom_templates", but I notice in the comments section something about a script. Looking in automation>scripts I have no scripts to be run??

Thanks Chris

Hi Chris,
The script was for an older version of this automation, the latest version talks directly to the inverter integration so it's not needed.

Can I double check is your HA connected to the inverter via RS485, and are you running the latest version of the integration https://github.com/nathanmarlor/foxess_modbus

If you are connected via LAN (rather than RS485), it doesn't expose the registers for setting the charge current, and if you are running an older version of the modbus integration, that didn't have the charge registers (the latest does).

You can see if the charge register is available by searching for 'number.max_charge_current' if that exists then it 'should' work, in which case i'll need to do some more digging - so will need your log files (System, Settings, Logs) around the time it would have been attempting to control the charge to see what errors are reported, and also if your look in your logbook can you copy what you see there that starts 'Charge Current', it will say something like Charge Current Setting Max Charge Current =2.5, SoC=95 , Night Mode=off triggered by state of Battery Charge Limit changed to 2.5

[chris01942]

Hi Dave, everything seems to be working except the charge current is changing when SoC >80%. I have the two jinja files in a folder "config/custom_templates", but I notice in the comments section something about a script. Looking in automation>scripts I have no scripts to be run??

Thanks Chris

Hi Chris,
The script was for an older version of this automation, the latest version talks directly to the inverter integration so it's not needed.

Can I double check is your HA connected to the inverter via RS485, and are you running the latest version of the integration https://github.com/nathanmarlor/foxess_modbus

If you are connected via LAN (rather than RS485), it doesn't expose the registers for setting the charge current, and if you are running an older version of the modbus integration, that didn't have the charge registers (the latest does).

You can see if the charge register is available by searching for 'number.max_charge_current' if that exists then it 'should' work, in which case i'll need to do some more digging - so will need your log files (System, Settings, Logs) around the time it would have been attempting to control the charge to see what errors are reported, and also if your look in your logbook can you copy what you see there that starts 'Charge Current', it will say something like Charge Current Setting Max Charge Current =2.5, SoC=95 , Night Mode=off triggered by state of Battery Charge Limit changed to 2.5

Hi Dave, I made an error. I'm gaining confidence in automating using helpers and scripts. I & others have encountered an issue with the inverter that discharges the battery when the max export limit is set at 3.7 kW and PV output falls with the inverter in work mode feed-in (FoxESS are looking into it). Sometimes, the inverter uses the battery to maintain the export limit, which causes a loss of SoC. I have basic automations to switch to feed in at N SoC%, which can result in a chunk of SoC being discharged due to the inverter maintaining export limit. To solve the feed-in issue, I was creating a script to change the charge current to 0.5 amps, & instead of switching to feed-in, leaving the inverter in self-use & exporting any excess minus the half amp. To cut the story short, it appears that the partially created script was interfering with your battery throttle. Once I deleted my script, the throttle began working.

Currently my system is at 89% & the current has been throttled to 3.4amps from a max charge limit of 10amps. So all is good.

Cheers, Chris.

[Dave Foster]

Hi Dave, I made an error. I'm gaining confidence in automating using helpers and scripts. I & others have encountered an issue with the inverter that discharges the battery when the max export limit is set at 3.7 kW and PV output falls with the inverter in work mode feed-in (FoxESS are looking into it). Sometimes, the inverter uses the battery to maintain the export limit, which causes a loss of SoC. I have basic automations to switch to feed in at N SoC%, which can result in a chunk of SoC being discharged due to the inverter maintaining export limit. To solve the feed-in issue, I was creating a script to change the charge current to 0.5 amps, & instead of switching to feed-in, leaving the inverter in self-use & exporting any excess minus the half amp. To cut the story short, it appears that the partially created script was interfering with your battery throttle. Once I deleted my script, the throttle began working.

Currently my system is at 89% & the current has been throttled to 3.4amps from a max charge limit of 10amps. So all is good.

Cheers, Chris.

Hi Chris, ok got it, no problem - i’ve seen that setting feed-in first reduces the grid pull by changing the bias and read about the battery being used to maintain the export limit - but i’ve never seen that myself, it does seem very weird behaviour, but then this is Foxess kit

If there’s anything I can do to help with that in code, just let me know.

[calum]

Just coming back to this now that we're firmly back in "charge battery every night" mode - especially now the weather is getting cooler and our heatpump is taking the strain.

As I speculated earlier in the thread, our 3.6kW inverter won't charge our battery bank (6*HV2600) from 10% SoC to full in a 4h Octopus Go off peak window, at least not with the Jinja night curve file as posted at the top of the thread. If you have a longer off peak window, or a more powerful inverter, you will probably be fine.

In my case I am experimenting with a later and slower rampdown, while still avoiding charging the battery hard at the end of the charge curve - I'm trying to gauge how hard I'm pushing the battery (or not) by how much the battery imbalance (the % difference between highest and lowest cell voltages) spikes when the battery approaches / reaches 100% SoC.

Separately I'm looking into the possibility of upgrading the inverter to a 6kW model, as part of upgrading some of the house circuits to work off EPS in the event of a power cut, but that's got bogged down in G99 approvals with ENWL...

[Dave Foster]

Just coming back to this now that we're firmly back in "charge battery every night" mode - especially now the weather is getting cooler and our heatpump is taking the strain.

As I speculated earlier in the thread, our 3.6kW inverter won't charge our battery bank (6*HV2600) from 10% SoC to full in a 4h Octopus Go off peak window, at least not with the Jinja night curve file as posted at the top of the thread. If you have a longer off peak window, or a more powerful inverter, you will probably be fine.

In my case I am experimenting with a later and slower rampdown, while still avoiding charging the battery hard at the end of the charge curve - I'm trying to gauge how hard I'm pushing the battery (or not) by how much the battery imbalance (the % difference between highest and lowest cell voltages) spikes when the battery approaches / reaches 100% SoC.

Separately I'm looking into the possibility of upgrading the inverter to a 6kW model, as part of upgrading some of the house circuits to work off EPS in the event of a power cut, but that's got bogged down in G99 approvals with ENWL...

I know your pain, I had the same charge issues until I changed the inverter, around 13.4kwh was the absolute best I could put in, in the 4 hours.

I changed to Octopus Intelligent 2 months ago, and having the 6 hours is a real game changer. Even on the 3.7kw inverter you'd get a full charge with the slow ramp - is your car/charger supported - it's worth looking at, not least as it's 7.5p vs 9p for GO.

The latest firmware is much better with SoC predictability, but i've noticed my pack seems to pause at 96% and have a think about it's capacity, that one % always elongates and is twice as big as what i'd expect (my pack ~200w per %), thereafter it plays catch up to hit 100% - perhaps 95% is the magic number to start ramping down at?

[calum]

The latest firmware is much better with SoC predictability,

Just wondering what you mean by "latest" in this context? I ask because I upgraded the system firmware (for all the components) at the end of April, but I've not looked at new versions since then (too much else going on). I still have the Agent Account and the alternative Wifi dongle so I can do the same process as last time, if things have improved again.

I've just checked the SoC history graph in HA and mine looks very similar to yours, with a "pause" at 96%, so I'll have a play with into the "ramp down from 95% SoC" idea, thanks for the suggestion.

is your car/charger supported - it's worth looking at, not least as it's 7.5p vs 9p for GO.

The car isn't, and the mfr (Hyundai) shows no signs of doing the necessary validation. The Zappi integration looks to be going through teething pains so I've left it for now. I do keep an eye on it though, will take a serious look once it comes out of Beta.

[Dave Foster]

Just wondering what you mean by "latest" in this context? I ask because I upgraded the system firmware (for all the components) at the end of April, but I've not looked at new versions since then (too much else going on). I still have the Agent Account and the alternative Wifi dongle so I can do the same process as last time, if things have improved again.

Lol, no the ‘latest’ hasn’t changed since late May, I suspect your on the same as me - Master 1.020 and Slave 1.06 it’s been very stable throughout summer, so i’m hoping for better things this winter

[calum]

I ended up with this for the night time charge curve:

Code: Select all

{% macro get_charge_limit(entity_id) %}

{% if states(entity_id)|int in [80] %}
  {{ 1 }}
{% elif states(entity_id)|int in [81] %}
  {{ 1 }}
{% elif states(entity_id)|int in [82] %}
  {{ 1 }}
{% elif states(entity_id)|int in [83] %}
  {{ 1 }}
{% elif states(entity_id)|int in [84] %}
  {{ 1 }}
{% elif states(entity_id)|int in [85] %}
  {{ 1 }}
{% elif states(entity_id)|int in [86] %}
  {{ 1 }}
{% elif states(entity_id)|int in [87] %}
  {{ 1 }}
{% elif states(entity_id)|int in [88] %}
  {{ 1 }}
{% elif states(entity_id)|int in [89] %}
  {{ 1 }}
{% elif states(entity_id)|int in [90] %}
  {{ 1 }}
{% elif states(entity_id)|int in [91] %}
  {{ 1 }}
{% elif states(entity_id)|int in [92] %}
  {{ 1 }}
{% elif states(entity_id)|int in [93] %}
  {{ 1 }}
{% elif states(entity_id)|int in [94] %}
  {{ 1 }}
{% elif states(entity_id)|int in [95] %}
  {{ 1 }}
{% elif states(entity_id)|int in [96] %}
  {{ 0.8 }}
{% elif states(entity_id)|int in [97] %}
  {{ 0.6 }}
{% elif states(entity_id)|int in [98] %}
  {{ 0.4 }}
{% elif states(entity_id)|int in [99] %}
  {{ 0.3 }}
{% elif states(entity_id)|int in [100] %}
  {{ 0.2 }}
{% else %}
  {{ 1 }}
{% endif %}

{% endmacro %}

With this profile my 3.6kW inverter will take a "flat" (ie 10% SoC) battery bank (6xHV2600) and get it to 98% SoC in the 4 hour Octopus Go off-peak window. Not quite fully charged, but close enough.

[Dave Foster]

With this profile my 3.6kW inverter will take a "flat" (ie 10% SoC) battery bank (6xHV2600) and get it to 98% SoC in the 4 hour Octopus Go off-peak window. Not quite fully charged, but close enough.

[calum]

I changed to Octopus Intelligent 2 months ago, and having the 6 hours is a real game changer. Even on the 3.7kw inverter you'd get a full charge with the slow ramp - is your car/charger supported - it's worth looking at, not least as it's 7.5p vs 9p for GO.

So, as it happens I got an email from Octopus inviting me to join I.O., it seems they are now sufficiently confident in their integration with the myenergi Zappi to roll it out more widely. Certainly the six off-peak hours and lower unit pricing are attractive, I was just wondering how you'd found it otherwise, there seems to be relatively little info on how it works until you actually sign up.

I'd definitely have to employ your battery protector automation, since it sounds like they can theoretically direct your EV to charge whenever, if it's plugged in, and I really don't need this thing to be emptying my battery any faster than the heat pump already does!

[Dave Foster]

I changed to Octopus Intelligent 2 months ago, and having the 6 hours is a real game changer. Even on the 3.7kw inverter you'd get a full charge with the slow ramp - is your car/charger supported - it's worth looking at, not least as it's 7.5p vs 9p for GO.

So, as it happens I got an email from Octopus inviting me to join I.O., it seems they are now sufficiently confident in their integration with the myenergi Zappi to roll it out more widely. Certainly the six off-peak hours and lower unit pricing are attractive, I was just wondering how you'd found it otherwise, there seems to be relatively little info on how it works until you actually sign up.

I'd definitely have to employ your battery protector automation, since it sounds like they can theoretically direct your EV to charge whenever, if it's plugged in, and I really don't need this thing to be emptying my battery any faster than the heat pump already does!

If you've got the Zappi sign up option (I haven't been offered it yet), i'd be much happier using that than the car interface. From what i've heard from people on the trial it's much more reliable and doesn't have the plug in charge immediately problem you get when the car is in control. The only thing it can't do is charge to an SoC which the car interface could, but tbh on mine it often overshot whatever I asked for so i'd be happier with a precise kwh setting.

And the 6 hours IO gives you makes so much difference

You'll definitely need the battery protector, I only made the mistake a couple of times but it hurts.... and i'm so glad I don't have to rely on my memory anymore

[calum]

Well, I'm switched over to IO, and I've deployed the battery protection automation you built for "Frank", which seems to work very well (the first IO EV charging period literally just started 8minutes ago so I've been watching in interest as the battery initially tried to provide 3.7kW and then stopped as the automation kicked in.

I've updated my charging period for the house battery to 00:00 to 05:30, I know it could start earlier by 30 minutes but I don't need it to to be sure of getting a full charge on the battery, and I'm not sure my inverter firmware supports charge periods across midnight.

Anyway, I'm not sure how the protection automation will react when it finds a charge period already in place from midnight onwards, I presume it will attempt to set charge period 2 and then fail because the Foxess Modbus integration won't let the periods cross.

One question I did have about IO - if Octopus trigger an EV charge period outside of the normal window, is all the power you consume during that time charged as off-peak, not just the EV power? Hopefully this is the case, otherwise it would be tricky if the heat pump decided to re-heat the water tank or something while there was a "special" IO charging slot going on!

[Dave Foster]

Well, I'm switched over to IO, and I've deployed the battery protection automation you built for "Frank", which seems to work very well (the first IO EV charging period literally just started 8minutes ago so I've been watching in interest as the battery initially tried to provide 3.7kW and then stopped as the automation kicked in.

I've updated my charging period for the house battery to 00:00 to 05:30, I know it could start earlier by 30 minutes but I don't need it to to be sure of getting a full charge on the battery, and I'm not sure my inverter firmware supports charge periods across midnight.

Anyway, I'm not sure how the protection automation will react when it finds a charge period already in place from midnight onwards, I presume it will attempt to set charge period 2 and then fail because the Foxess Modbus integration won't let the periods cross.

Great, glad you’re up and running - from what i’ve read the Zappi control is much more reliable than the other methods - there seem to be a lot of happy customers

You can set the time boundary across midnight, it wasn’t the inverter that was stopping it, it was the back end and app and that was fixed many months ago, so you’ll be fine with 23:30-05:30 if you want it.

I wrote the protection automation to keep it very simple - if it sees the zappi charging and your battery discharging at more than 3kw it assumes it must be the car charger that is on as if you had a charge period set the batteries wouldn’t discharge at all - so it will protect you (in 30 minute intervals) if you don’t have a charge period sett; if you do have one then there won’t be high battery discharge and it won’t set period 2.

One question I did have about IO - if Octopus trigger an EV charge period outside of the normal window, is all the power you consume during that time charged as off-peak, not just the EV power? Hopefully this is the case, otherwise it would be tricky if the heat pump decided to re-heat the water tank or something while there was a "special" IO charging slot going on!

IO is a bit finicky but the basic rule is that if your car is charging for any minutes within the current 30 minute billing period then all of that 30 minute will be low tariff for the whole house.

So if you car was charging to 9.10am you would have the whole of the house covered whilst it is charging and then also up to 9.30am

If you abandon the charge slot then if it gives you a slot such as 08:00-10:00 it will *only* be low tariff if the car had been charging and even then only up to the end of the last 30 minute period it was charging in.

The Octopus Energy Integration is quite good, once you have Intelligent (and you restart HA) it will add another device ‘charger’ - that provides extra information about intelligent, the best one being the IO slot dispatcher which goes true when you are in low tariff and in the attributes it has the planned and completed dispatches.

I have seen a few occasions where Octopus has started my car charging without notifying me, or giving me a low tariff period (consequently the IO slot dispatcher stays false), I only find out after the event that the slot was low when the rates get updated well after the slot has finished - i’ve tried all kinds of trickery to fix it, but to no avail - I guess as they say it’s still a beta

It doesn’t happen that often as the majority of my slots are in the 23:30 - 05:30 unless my car is really low and I have an early start - but that doesn't happen often for me.

I’ve just signed up to Octoplus in the hope it might give me some free power - they say they will email or via the app - but i’m not sure if we can see it in HA yet, so keeping my fingers crossed we get some soon to test it.

[calum]

if you do have one then there won’t be high battery discharge and it won’t set period 2.

Doh, that is very obvious logic that my 11.30pm brain completely failed to spot!
In any event it works perfectly to protect the battery

Thanks for the explanation about how the cost works outside of the 11:30-05:30 period. I did wonder if they would try to isolate the EV charging power via the Zappi, so only that bit of power would be charged at cheap rate. But then I thought that whatever power measurements the Zappi provides, they will not be supportable as a basis for billing, so it makes sense for them to set the whole slot to 'off-peak'.

We don't do a great deal of driving, and my wife quite often has access to "free" type 2 charging at her office, so we probably won't be making use of the IO all that often. I'll probably just lob ~20kWh in when the wind farms are doing well to keep us in good standing with the tariff Ts&Cs!

In any case, I can now also go back to the gentler version of the nightime charge curve .jinja file and treat my battery as kindly as possible

[Stephens-Ely]

Hi Dave;

After our chat yesterday on the FB group I thought I'd check out your Charging Profile automation. I may adopt something like this....

Just thought you may want to know about a couple of typo in your explanation of the charge required...

for example on an HV2600 pack with 4 batteries this will be approx 211V. Power = Watts * Volts so in this example 4kw/21V1 = 19A and you would set the maximum charge rate to 19A

You have Power = Watts * Volts where as it should be Power = Watts / Volts.

You also have 4kw/21V1 = 19A but I think you mean 4000W/211V = 19A

Cheers

Brian

[calum]

For DC: Power (W) = Voltage (V) x Current (A)

Power is (typically) expressed in watts, but that's a unit, not a property.

watts/volts would imply Power / Voltage, which gives Current in Amperes (commonly, Amps)

All of which being restatements of Ohm's Law.

[Dave Foster]

Hi Dave;
Just thought you may want to know about a couple of typo in your explanation of the charge required...

for example on an HV2600 pack with 4 batteries this will be approx 211V. Power = Watts * Volts so in this example 4kw/21V1 = 19A and you would set the maximum charge rate to 19A

You have Power = Watts * Volts where as it should be Power = Watts / Volts.

You also have 4kw/21V1 = 19A but I think you mean 4000W/211V = 19A

Cheers

Brian

Thanks, I wrote it some time ago and meant to say power = amps * volts or amps = power/volts - good spot !.

I’ve edited it to correct it…. Lol you wouldn't believe i’m a qualified electrical engineer..in my defence that was a long time ago

I’ll dig out the simpler automation I wrote for a friend, much easier to implement and just sets the charge current to 5A - back shortly

Code: Select all

alias: Charge Reduction
description: ""
trigger:
  - platform: time_pattern
    minutes: /1
condition:
  - condition: or
    conditions:
      - condition: numeric_state
        entity_id: sensor.battery_soc
        below: 90
      - condition: numeric_state
        entity_id: sensor.battery_soc
        above: 93
action:
  - if:
      - condition: numeric_state
        entity_id: sensor.battery_soc
        above: 92
    then:
      - if:
          - condition: numeric_state
            entity_id: sensor.max_charge_current
            above: 10
        then:
          - service: number.set_value
            data:
              value: 5
            target:
              entity_id: number.max_charge_current
          - service: logbook.log
            data:
              message: Setting Max Charge to 5A
              name: Max Charge
    else:
      - if:
          - condition: numeric_state
            entity_id: sensor.battery_soc
            below: 90
        then:
          - if:
              - condition: numeric_state
                entity_id: sensor.max_charge_current
                below: 10
            then:
              - service: number.set_value
                data:
                  value: "21"
                target:
                  entity_id: number.max_charge_current
              - service: logbook.log
                data:
                  message: Setting Max Charge to 21A
                  name: Max Charge
mode: single

There you go, this simply sets the charge current to 5A at 93% SoC and then when it drops below 90% it resets it to the high charge current (in this case 21A)