Controlling battery discharge rate?

Post Reply
User avatar
HughInDevon
Posts: 39
Joined: Wed Jul 31, 2024 4:50 pm

Hi, I am on a mission to develop an automation that will stop my house battery discharging into the car whenever the IOG charging schedule is outside of the normal 23:30 to 05:30 low tariff period. I can't use the 'split off the charger supply between the grid and CU' method and all other suggestions are sub-optimal in one way or another. So, I am trying to go down the HA automation route. To this end I have installed a Shelly EM energy meter on the line feeding the Zappi charger. This works a treat and I have a (very very) simple automation that triggers when the Zappi takes more than 50 watts. It normally uses about 4 to 5 watts according to the Shelly EM but rises to over 3 kilowatts when a vehicle is charging.

What I now want to do is stop the house battery discharging when my automation triggers ( and reset afterwards of course). In my HA integration from Nathan Marlor I can see four entities that might be suitable to do this. These are:
sensor.kh10_inverter_bms_discharge_rate
sensor.kh10_inverter_invbatcurrent
sensor.kh10_inverter_max_discharge_current
number.kh10_inverter_max_discharge_current

My question is can I use any of these to set the battery discharge current to zero while my automation sensor is active? I have read the wiki on the Nathan Marlor intergration but I am not clear about what is possible. A second question is how would I do this? I have zero experience with YAML and the last time I had any actual training in programming was learning Algol 60.

Thanks, Hugh
KH10 with 4 off ECS4800 batteries.
20 Jinko 435W panels in 2 strings. 10 on house, south facing, 10 on barn, east facing.
Solar installation active on 27/11/2024. Export MPAN active on 30.12/2024.
Zappi V2 charger and 2 EVs.
Currently on Octopus Intelligent Go tariff.
Home Assistant modbus integration (Now working - ish)
Dave Foster
Posts: 1558
Joined: Thu Oct 13, 2022 7:21 pm

Yes that's a good way to do it, I have a Zappi but use a Shelly CT clamp to monitor the charge power as it is very quick to update.

I check for greater than 1100 watts for charging (as the minimum EV charge is 6A @230V = 1,380) and check for less than 100 watts to confirm no longer charging.

There are quite a few options,

if you want to just stop the batteries from discharging you can set `number.kh10_inverter_max_discharge_current` to zero (0) and then reset it to 40A when you want it to start it discharging again.

If you do that make sure you use the action `number.set` (and not the similarly named `input_number.set` which is for modifying helpers)

Or

If you want to slow charge your batteries at the same time and not discharge - then change minSoc on Grid ('number.kh10_inverter_min_soc_on_grid') to 100% and it will start a 4A charge which on your battery stack would be about 720 watts (and it will not discharge) when you are finished change it back to your normal setting 10%?

Or

If you want to fast charge your batteries set the work mode to Force Charge when the EV is charging, and back to Self-Use when finished.
For that you use the automation action select.select_option with the option set as Force Charge or Self Use
User avatar
HughInDevon
Posts: 39
Joined: Wed Jul 31, 2024 4:50 pm

Hi Dave,
That's brilliant! Many thanks for the advice. I will start with having a go at an automation using the first option, setting the discharge current to zero, as it seems to be the simplest. I am tempted by the second option using min_soc_on_grid as it will make more use of the low tariff rate during the charging schedule. My main concern is that in a perfect world it is best to minimise the number of battery charge / discharge cycles and this adds cycles. Not many as we only charge once or twice a week so probably not worth worrying about.
Thanks again, Hugh
KH10 with 4 off ECS4800 batteries.
20 Jinko 435W panels in 2 strings. 10 on house, south facing, 10 on barn, east facing.
Solar installation active on 27/11/2024. Export MPAN active on 30.12/2024.
Zappi V2 charger and 2 EVs.
Currently on Octopus Intelligent Go tariff.
Home Assistant modbus integration (Now working - ish)
User avatar
HughInDevon
Posts: 39
Joined: Wed Jul 31, 2024 4:50 pm

Hi,

I have made some progress with setting up my automation to prevent the house battery discharging into the car. I am running a proper test this evening when we have an IOG charging schedule starting at 21:30.
But there are still some things I am stuck on and I would appreciate any guidance how to do what I want.
Below is what I am trying to achieve in my automation:

Better EV Charger Automation

Set up a global readable flag (boolean variable) EV_is_charging.
Initialise EV_is_charging to False
Declare static variable (OldValue) to hold current value of MaxBatDischargeCurrent
Read current value of MaxBatDischargeCurrent and store in OldValue

If ZappiPower > 50 watts
Set MaxBatDischargeCurrent to zero
Set EV_is_charging to True
Send a notification that EV charging has started
End If

If ZappiPower < 50 watts
Set MaxBatDischargeCurrent = OldValue
Set EV_is_charging to False
Send a notification that EV charging has ended
End if

What I actually have at the moment is two simple automations. One triggers on the Zappi output being above 50 watts and the other when it goes below 50 watts. These send notifications to HA and that works OK.
It is the use of two variables that I can't fathom out how to do. The variable OldPower is desirable as otherwise I have to reset the power from 0 to a hard coded numerical value in my automation. Obviously I want to retain the ability to set the actual value outside of the automations and have that value restored when the automation runs.
The second variable is a flag that I think will be useful for the next stage of my HA journey. This will be to monitor the battery SoC a couple of hours before the IOG low tariff period and, if worthwhile, to do do a forced discharge to export the surplus energy from the battery. However, I want to be able to inhibit this if a vehicle is on charge, hence the global flag variable.

All suggestions greatly appreciated.

Thanks, Hugh
KH10 with 4 off ECS4800 batteries.
20 Jinko 435W panels in 2 strings. 10 on house, south facing, 10 on barn, east facing.
Solar installation active on 27/11/2024. Export MPAN active on 30.12/2024.
Zappi V2 charger and 2 EVs.
Currently on Octopus Intelligent Go tariff.
Home Assistant modbus integration (Now working - ish)
Dave Foster
Posts: 1558
Joined: Thu Oct 13, 2022 7:21 pm

Settings, Devices & Services, Helpers

You can create lots of things but you seem to need numbers, booleans, toggles(switches) they are global within your system, so you can see them on the dashboard, you can modify or set a value with actions in automations, or test them in conditions.

This is from one of my automations, which sets the ‘number’ helper called Battery Charge Off Peak to a value of 0
IMG_1686.jpeg
You can set it to a value of a state but you’ll have to use something called jinja templates for that - in the above example, lets say I wanted to set it to the value contained in sensor.battery_soc in the value box you would enter this template
"{{ (states('sensor.battery_soc')|int ) }}"

You can test templates if you go to Developer Tools, Template and enter the text you want to check in the Template Editor, and in the Results box it will show you how it evaluates.

Just post up if you need a hand with anything.
User avatar
HughInDevon
Posts: 39
Joined: Wed Jul 31, 2024 4:50 pm

Hi Dave - and anyone else interested.
I am happy to report that my automation scheme to prevent the house battery discharging into an EV battery worked a treat in the real world. We plugged our Nissan Leaf into the Zappi at teatime yesterday and got a charging schedule from Octopus starting at 21:30. As soon as the charging started the house battery discharge current dropped to zero and remained there until the car was fully charged. Then the discharge current limit was restored to its normal value of 30 amps. So, this means that we can charge our EVs using Octopus Intelligent Go and not have to worry about when we plug the vehicles into the charger and be sure that the house battery will always work as planned to provide power to the house during the high tariff period without being drained when a car is charging.

Dave, thanks for the information on jinja templates. I will have a play with them and see if I can make the changes I want to my basic automation scheme.

One further question if you don't mind. How do I copy and post screenshots from HA into these posts? I would like to show the history cards for my MaxBatDischargeCurrent and the myenergi zappi charge added as these show the charging story better than a description in words.

Thanks again.
Regards, Hugh
KH10 with 4 off ECS4800 batteries.
20 Jinko 435W panels in 2 strings. 10 on house, south facing, 10 on barn, east facing.
Solar installation active on 27/11/2024. Export MPAN active on 30.12/2024.
Zappi V2 charger and 2 EVs.
Currently on Octopus Intelligent Go tariff.
Home Assistant modbus integration (Now working - ish)
Dave Foster
Posts: 1558
Joined: Thu Oct 13, 2022 7:21 pm

HughInDevon wrote: Thu Dec 12, 2024 11:08 am One further question if you don't mind. How do I copy and post screenshots from HA into these posts? I would like to show the history cards for my MaxBatDischargeCurrent and the myenergi zappi charge added as these show the charging story better than a description in words.
There’s no really easy way sadly, I either view it on my phone and screen shot it - then either post it or crop it from my photo library - or if i’m on my PC I use ‘Alt & Prtscn’ to screen shot the active window and then paste it to a program like word or paint and save it to the desktop and add it from there.
adamlc
Posts: 13
Joined: Thu Sep 26, 2024 10:49 am

I need to do something similar with my PodPoint. The PodPoint does have a cloud integration where I can tell if it's charging, but the cloud part is a bit dodgy and sometimes the charge point drops off the WiFi.

Ideally I want to connect a Zigbee CT clamp to monitor it. But ironically I don't actually have an easy way to power that. The charge is outside next to the meter box. I do have another EV charger, a SolaX which has a local home assistant integration that reports charge power. So I may just use that, but it's not in a convenient location compared to the PodPoint.

Some other things I want to automate are the tariff. Theres an IOG dispatching sensor in the octopus integration, but from what I gather even if you're allocated a slot, you need to confirm the car is actually charging in order for that half hour slot for it to be charged at the low rate. I have seen instances where the car charges earlier and the house load was then charged at the peak rate. You get the guaranteed slot always between 23:30 - 5:30. What I have considered doing as a quick fix would be to limit the battery discharge to 3A when the intelligent dispatching sensor is on, but not the offpeak sensor. It should work until I can sort out a ct clamp solution! Once both sensors are off I can switch it back up to full discharge.
User avatar
HughInDevon
Posts: 39
Joined: Wed Jul 31, 2024 4:50 pm

Hi Adam,
I looked at the 'Is-Dispatching' flag from the IOG integration but it didn't seem to correspond to the reality of the IOG charging schedules so I gave up on it. If you can find a way to use a CT clamp it will definitely work. I don't know if it's possible but you could consider adding the clamp to the input line to the charger rather than on the charger output. My clamp is actually in the consumer unit that feeds the Zappi, not near the Zappi. The CU also gives a fairly straightforward way to power the Shelly energy meter that I use. Note all the usual warnings about fiddling with mains electricity. Nasty stuff if you get it wrong.
KH10 with 4 off ECS4800 batteries.
20 Jinko 435W panels in 2 strings. 10 on house, south facing, 10 on barn, east facing.
Solar installation active on 27/11/2024. Export MPAN active on 30.12/2024.
Zappi V2 charger and 2 EVs.
Currently on Octopus Intelligent Go tariff.
Home Assistant modbus integration (Now working - ish)
adamlc
Posts: 13
Joined: Thu Sep 26, 2024 10:49 am

Thanks for the reply!

I have considered the mini consumer unit next to the charger, but unfortunately there isn't any space in there either. Ideally I don't want the hassle and expense of putting in a larger mini consumer unit.

I do have power the other side of the wall in the kitchen that would be easy to tap into if needs be, but would rather not drill more holes in the wall! I know the podpoint has 12v pins I could potentially power an esp32 from with a ct clamp, would be nice and tidy inside the unit that way. The clamp I have currently is 240v.
adamlc
Posts: 13
Joined: Thu Sep 26, 2024 10:49 am

Actually looks like I was wrong, there is space in the mini consumer unit.

The MCB reset button also doesn't work anymore either, so probably a good idea to get a spark round to switch the MCB and maybe install something like a Shelly EM too!
tempImageLMjb2f.gif
User avatar
HughInDevon
Posts: 39
Joined: Wed Jul 31, 2024 4:50 pm

Hi Adam,
The Shelly EM is tiny. The CT clamp is actually bigger - but still small. One thing to consider is that it's unlikely that any WiFi device will work inside a steel enclosure. I knocked out a whatever they are called 20 mm disc in my CU and fitted the Shelley EM in a plastic box next to the CU. That way there are no nasty live connections exposed but the WiFi is free to do its thing.
KH10 with 4 off ECS4800 batteries.
20 Jinko 435W panels in 2 strings. 10 on house, south facing, 10 on barn, east facing.
Solar installation active on 27/11/2024. Export MPAN active on 30.12/2024.
Zappi V2 charger and 2 EVs.
Currently on Octopus Intelligent Go tariff.
Home Assistant modbus integration (Now working - ish)
adamlc
Posts: 13
Joined: Thu Sep 26, 2024 10:49 am

This is a crappy plastic enclosure. Ideally I'd like a zigbee device as I have zigbee lights outside and the network is better than the wifi outside.

Ideally I'd get my wiring changed so the inverter doesn't see the charger. I guess getting this costed first makes the most sense!

It should just be a case of splitting the feed again in an extra henley block. Might not be too extensive 🤞
Post Reply