Timed Export - Paused Battery Afterwards

I've seen and tried to understand a number of posts on this topic but can't work out the current state of things and if what I want is possible and if so how to achieve it.

Setup on my AIO and gateway:

• charge battery for cheap overnight
• use the battery in the morning until the solar covers the house load
• top up the battery via the solar with any excess exported to the grid
• in the evening force discharge the battery to 45%
• see through the evening on the battery

Now this works great most of the time. I have a toggle in home assistant to disable the forced export if I want to hold back the battery completely to run an AC unit or something in the evening.

The problem is that if the solar isn't very good on a particular day the discharge starts at say 90% and so gets to 45% before 19:00 and the battery just goes idle until then, leaving the house to draw from the grid at the most expensive time.

I originally set my timed export for the whole Octopus peak time frame but quickly discovered this pausing problem and so pushed the start time back so when it starts at 100% it hits 45% as close to 19:00 as possible.

Do I have to write some automation to dynamically move my discharge start or end time each day based on the battery percentage? (I think I would need to amend this before it starts the discharge because changing the end time while inside the originally set window didn't seem to work when I tried it).

Is there a setting I can toggle instead to kick the battery back in once the target has been reached instead? I tried toggling on and off various options in the remote control settings area this evening but couldn't get it to kick back in with any of them, it eventually did it itself at 19:00 but can't work out what dictates that in order to change it manually via HA.

Thanks in advance for any help!

GavinCarpenter What you’ve discovered is that the forced export stops when either the end time is reached or the % battery level is reached. If the % battery level is reached first then the inverter will not let the battery discharge below the % level before the end of the time period, so yes, it will start to grid import.

So yes, you will need to adjust your automation so it stops this happening.

Easiest way is to start the discharge at your set time, then have an automation that runs every 10 minutes between 4 and 7pm (or whatever). If the SoC is less than your desired figure then it sets the inverter to Eco mode and stops the forced export.

You could look at something like Predbat in Home Assistant that will optimise the battery for you based on solar forecast and predicted house load, or write your own automations as you are doing.

geoffreycoan thanks for the quick reply. So I thought "Enable eco mode" was the setting I should be looking for based on what I had read but my logs show me trying twice just before 7pm today to toggle it and it didn't work.

It was already enabled, I turned it off and then on again in quick succession. Repeated this a few minutes later.

I also tried manipulating "Pause Battery", was already set to "not paused" as well as "Enable DC discharge" which was already set to "true" (I think I've been able to toggle this option on and off mid timed export and had it stop and restart the discharge as I would expect.

Maybe this evening I changed too many things in a short period of time or something.

I'll try again at some point when I'm not busy at the relevant time and see if it works as it sounds like it should and report back.

I looked briefly at predbat but decided at the time it was a bit complex and I preferred the simpler approach to things. Might take another look at some point.

GavinCarpenter There are a lot of different controls in GivTCP and it can take a while to work out how they all operate.

The main control is givtcp_SERIALNO_mode. Normally this will be set to Eco. Set it to Timed Export to start an export (using the start and end discharge times), so setting this back to Eco will cancel any export.

If you set switch.givtcp_SERIALNO_enable_discharge_schedule to false this will turn off the discharge schedule but won’t return the inverter back to Eco mode.

Battery Pause mode you set to PauseDischarge if you want to stop the battery from discharging, useful to hold the charge at a level and allow charging, but not discharging. Do set back to Disabled when you want normal Eco mode.

For battery pause mode you will need to set a start and end time first, or you can set these to 00:00:00 and 23:59:00 then just use the pause mode control directly.

Predbat is quite comprehensive and complex but there’s lots of people using it and a lot of effort has been put into making the install process easy to follow. Its very flexible though, might be more powerful than you need

GavinCarpenter I thought "Enable eco mode" was the setting I should be looking for

Yes it is, but during a timed export, eco mode is overridden, for the entire timed period (even if battery reaches the % limit configured).

geoffreycoan Thanks for the summary of options, really helpful.

All of the changes I mentioned though were made directly in the givenergy portal though, not via HA. Maybe having it connected in HA as well causes some things to work incorrectly/differently perhaps. I'm using the beta version of GivTCP if that makes any difference.

I think perhaps where I'm getting confused is thinking that every option in HA maps to an accessible register in the online portal and changing it in one reflects it in another and there is just some naming differences between them. If this is not how it works am I now right in thinking that GivTCP via HA is more detailed/powerful than using the portal and it takes precedence over some things set there?

In this is true I'm still a bit confused based on what you've said about eco mode not being turned back on.

When in HA I toggle off switch.givtcp_SERIALNO_enable_discharge_schedule I can see givtcp_SERIALNO_mode being automatically changed over to eco, it I turn it back on it goes back to "Timed Demand" which it seems to stay in normally.

I can see twice yesterday evening I toggled the discharge schedule in HA off and then back on again while I was trying to get the battery to kick back in. I can see the main control mode go from "Timed Demand" to "Eco" at the same time. I didn't manipulate this directly, even accidentally, as it isn't on my dashboard view. Now these were only for 47 seconds and 1 min 14 seconds so perhaps I just didn't wait long enough before turning it back on and trying something else?

Basically, if I have a discharge timed between 5pm and 7pm and the target percentage is reached at 6:30pm what should I be changing in HA to make the battery pick up the house load right away again instead of waiting till 7pm?

It sounds like changing just the main mode to "eco" should do it (which for me happened when I toggle the discharge schedule off) but based on what DD has said and what I've seen this doesn't work, once the export starts you have to wait it out until the end time that was set when the export originally started.

If this is the case then fine, I can work around it by pushing the start time back dynamically; this is probably better anyway because it means I have 45% battery at 7pm rather than a bit less because the discharge level was hit too early and then the battery was used a bit before 7pm (which I can't seem to get it to do anyway).

It does seem a bit of a weird design choice by GivEnergy to have it work this way though based on how I imagine people would want to use this feature. If there are use cases where people do want to discharge the battery to a level and then hold it at that level until the end time then I would suggest that an extra tick box that changed the default behaviour could also be made available:

"Reenable battery usage immediately once target is reached (enable to avoid grid usage at peak import rate times)".

GavinCarpenter All of the changes I mentioned though were made directly in the givenergy portal though, not via HA. Maybe having it connected in HA as well causes some things to work incorrectly/differently perhaps. I'm using the beta version of GivTCP if that makes any difference.

The portal tends to show the last value it sent, rather than reading from the inverter. And I suspect it only sends a value if it's different from the last value it sent, even if HA has changed it.

I think perhaps where I'm getting confused is thinking that every option in HA maps to an accessible register in the online portal and changing it in one reflects it in another and there is just some naming differences between them. If this is not how it works am I now right in thinking that GivTCP via HA is more detailed/powerful than using the portal and it takes precedence over some things set there?

HA does give access to more registers than available through the portal. But changing through HA does not automatically update the copy in the portal - need to force the portal to re-read the register from the inverter.

Basically, if I have a discharge timed between 5pm and 7pm and the target percentage is reached at 6:30pm what should I be changing in HA to make the battery pick up the house load right away again instead of waiting till 7pm?

I don't use HA, but I do use modbus-based scripting to implement this. The way I do it is that I configure the discharge limit to be slightly lower than I really want. Then my script monitors the SoC and turns off the enable-dc-discharge flag once it gets to 5% above that.

The automation is basically set up to try to keep the battery SoC between limit+5% and limit+10% - whenever it exceeds the latter, it turns on the export until it gets down to the former. Limit is currently set to 35% so target range is 40% to 45% throughout the day. Will probably raise that as the year moves on and I need more in the evening. The inverter should never see the SoC get down to the configured limit itself, but if it does - because my script has crashed - it serves as an emergency brake.

I'm sure it ought to be easy to set up a HA automation to do the same (though there you probably have freedom to use a separate parameter). [Using the inverter's registers is a convenient way for me to pass information to my script - saves me having to invent a different channel for sending in configuration changes while it's running.]

It does seem a bit of a weird design choice by GivEnergy to have it work this way though based on how I imagine people would want to use this feature. If there are use cases where people do want to discharge the battery to a level and then hold it at that level until the end time then I would suggest that an extra tick box that changed the default behaviour

Yeah... but this is happening inside the firmware, and while it's simple to describe what you want, actually encoding it can be complex. Eg what if you change the limit once it's been reached - does it resume discharging, or is it a toggle that has latched into the stop-discharging state ?

(Rather than describing it as 're-enable battery usage', I'd probably describe it as 'exit timed-export mode when either the end-time or the lower-limit SoC has been reached'. After all, 're-enable battery usage' implies you were in eco mode, but you might not have been.)

GavinCarpenter @DD has covered the main points I was going to make.

It’s worth recapping the architecture. Your inverter has a number of registers that controls what it does. The portal has an abstraction of those registers, presented in a user friendly way. When you change a control in the portal, the portal makes the appropriate changes to the inverter registers. The GivEnergy app acts as a front end to the portal, any changes made in the app are sent to the portal and thence the inverter.
Key point is that the inverter has a copy of what it thinks the inverter settings are. You can force the portal to retrieve what is actually on the inverter by pressing the little circle arrow icon next to the controls in the portal.

Now add GivTCP into the mix. This talks directly to the inverter via modbus and maps the inverter registers and controls into Home Assistant controls. These are thus at a much lower level of granularity than the portal controls. There is some abstraction/reformatting of the inverter registers to make them user friendly in HA, but you do end up seeing registers and controls that are linked together like the mode and enable discharge schedule.

Worth re-highlighting that if you make changes in HA via GivTCP then this is written directly to the inverter and the portal knows nothing about the change.

Also worth highlighting that GivTCP sends write commands immediately to the inverter but only polls the inverter for updates every X seconds. This is the ‘run frequency’ in the givtcp config. Set it too low a value and the inverter will spend all its time talking to givtcp and not be able to communicate to the portal/app. Too high and you’ll get a noticeable lag between sending commands and seeing the effect of them. I have mine set to 20 seconds.

My scripts to start a discharge set the start and end time and then change the mode from Eco to Forced Export. When I want to cancel I change the mode back to Eco. I don’t I use the enable_discharge_schedule switch although as you’ve seen, it changes automatically when you change the mode and vice versa.

Thanks DD and geoffreycoan all very helpful and detailed information, much appreciated.

Think I've got enough to go on now for what I want to do and hopefully all the above is useful to others who come across this in the future.

geoffreycoan My scripts to start a discharge set the start and end time and then change the mode from Eco to Forced Export. When I want to cancel I change the mode back to Eco. I don’t I use the enable_discharge_schedule switch

I changed mine to use Enable Discharge Schedule once the inverter was on 191/193 f/w rather than use the "Forced Export" setting as I still find Forced Export more unreliable (battery discharge gets stuck on occasion). Not had a problem with the Discharge Schedule post 191/193....

Vestas I changed mine to use Enable Discharge Schedule once the inverter was on 191/193 f/w

That’s interesting to hear that there is a reliability issue with setting the mode to Forced Export, I use Predbat most of the time so don’t often use my manual scripts.

But not an issue to change them.

The scripts are quite belt and braces to ensure the inverter is in a totally known state for an action, they currently:

select discharge start time slot 1 as “00:00:00”
select discharge end time slot 1 as “23:59:00”
set discharge rate to max (2600)
set battery reserve to 4
pause 15 seconds to allow the above to take effect
select battery pause mode as Disabled (I added this with firmware 191/193)
pause 5 seconds
select inverter control mode as Timed Export

So presumably it’d just be a matter of turning on enable discharge schedule and letting that in turn set the mode appropriately?