Power "leakage" when pausing discharge on multiple inverter models

[DJBenson]

Hi @springfall2008

As we discussed briefly on the Facebook group - the way in which predbat pauses the discharge results in a power leakage of around 600w. Although the settings allow for this value to be modelled, it's quite a high power loss when the battery should be paused.

After some playing around I found that by sending a pause command and an end time in the future the battery would go into a "deeper" state of pause and only discharge around 30w which is more acceptable.

You said this is something you could implement a fix for this but would need some testers. There's a few AIO users now so I think you'd get some takers and I'm obviously in if you want to do a limited beta/separate branch to test.

Applicable section in the portal;

[mpartington]

I think this could be widened to all inverters running 'faster' firmware. Whilst not in the portal yet, I can do similar on my AC3 through GivTCP. My thoughts are it could be added as an option in expert mode initially and used if selected. GivTCP uses a similar process in the configuration set up. Maybe there could be some error checking to switch off and default to the old method if it doesn't return A valid response

[DJBenson]

@mpartington what kind of values do you get from your AC3 with the two scenarios? I didn't realise it impacted more inverters but agree make it wider if it helps more people!

By two scenarios I mean;

• Just the pause option set
• The pause option set with an end time (in the timeslots section or via the portal)

[DJBenson]

FYI setting the pause options in GivTCP on an AIO does not pause the battery hence this ticket specifically mentioning the AIO - you have to provide an end time for it to go into the lowest pause mode (but still discharging which is frustrating but from the explanation I saw, it's to keep the BMS alive which it would not do if it were drawing from grid and the grid suddenly disappeared).

[mpartington]

Ah, that's a bit different! No start or end time required on the AC3 firmware to set a pause. The older firmware has zero leakage using the current method, it's a shame they felt the need to change. This is what I reported back in the beta group, hoping to drive a firmware change. I later found turning eco off didn't work in a charge period.

[mpartington]

Just giving this some thought as a stop gap. Could you pre-set your pause charge window to cover the whole day and then toggle it on and off via a givtcp automation (would that work currently in GivTCP, or is it all in development with Mark)? The trigger could be a change that predbat makes, such as if discharge (or charge) power is set to 0, then enact the appropriate pause. If it changes above 0, then cancel pause. Could also be done on predbat status changes.

Would be quite easy on AC3, but i guess not on AIO if the givtcp code isn't there

[DJBenson]

So I think Predbat is setting the pause mode but the lack of a time renders it, not useless but less useful than it could be as the "leakage" is quite a high amount (10% of the total power output of the unit is high to me). I think it might be possible to set a time manually but what I'm asking for is that in cases where the pause mode is set, a time is also set for the expected end of the window - Predbat knows what it is so it should be something which can also be sent/set.

The bit I don't know is how it might affect different inverters (if at all). If all models/firmware revisions have the mode and the start/end time fields then there is probably no harm sending the data to all inverters but 1) I don't know if it will break something on older inverters if they don't have the same options and 2) why send a command when it's not necessary, so perhaps a way to toggle this extra level of control for this use case...

,,,and clearing the value after each slot...

[wilsondw]

Gen 2 inverter on latest firmware seems to behave the same as AIO - With the current predbat approach Freeze Charge results in constant discharge - but to add to the mix it can't be modelled precisely as the discharge amount varies between Freeze charge slots (this morning it was 450w, this eveing 300w - not clear why there is a difference). Using the Pause functions in contrast results in 29w leakage.

For Gen 2 you have to set the pause time slot but you can set the time slot to 00:00 - 23.59 so that pause will be effective whenever it is set. With Gen 2 you can choose the pause mode: pause charge, pause discharge or pause both charge and discharge.

+1 for predbat to use the pause option

Broader question - what is Freeze Charge attempting to do? What I see from the logs is that it:

• sets charge window with a target charge of 4% (as 4% is the reserve, current SOC is always higher than this, it simply indicates discharge with house load until you get to 4%)
• it sets discharge rate to 0 (theoretically preventing discharge - but in practice not doing so on AIO and Gen 2 at least)

If the aim is to prevent discharge for a period of time and cause the house load to be covered by the grid, the alternative approach within Predbat of setting the reserve to the target SOC seems to work much more effectively at preventing discharge.

[gcoan]

On my gen 1 hybrid I'm seeing freeze charges when the plan says for it to be charging #357

But my freeze charges are setting target soc and reserve soc to the same value (eg 14%) when soc is 4% so it doesn't charge at all

[wilsondw]

Hi @springfall2008. Last night was interesting as I got a mix of Freeze Charging and Hold Charging from Predbat. I'm not clear on the different intents of the two modes, but Hold Charging does stop discharge to house load completely on my Gen 2, whereas Freeze Charging does not (and as you can see from the graph, the amount of discharge varies between freeze charging slots).

I assume Freeze Charging does not intend to do what it actually does on my Gen 2. What is the intent of this mode?

[mpartington]

Trefor, please correct me if wrong: Hold charging seems to turn off the charge schedule completely. I think it was introduced because on a particular Gen2 firmware, if your SoC was higher that the target in a charge window, then the battery would not discharge. Turning off the charge schedule until it ran down to the SoC target was a work around someone requested (I'm unsure if the Gen2 firmware has been fixed yet). I think this was turned on using set_reserve_hold (which is now on by default in basic mode for all inverters)

Freeze charging sets battery discharge rate to 0, however there is 'power leakage' from the battery on anything other than original gen 1 firmware (where it does set to true zero), hence why you see the constant battery discharge during those periods. There is a new 'battery pause' method on 'faster firmware', but even that has a small leakage - but minimal in comparison~30W

[springfall2008]

So my plan is to change freeze charging to use the reserve setting rather than the discharge rate in the hope that will work better, do you agree?

[mpartington]

So my plan is to change freeze charging to use the reserve setting rather than the discharge rate in the hope that will work better, do you agree?

This didn't work well on the last beta version of AC3 for me. Once SoC was at target, I saw battery power charge/discharge fluctuations as it tried to hold the SoC. The magnitude depended on load, so if I had the car charging, I would see significant throughput, if just normal baseload it wasn't too bad. There is a risk of trading one problem for another.

[springfall2008]

So my plan is to change freeze charging to use the reserve setting rather than the discharge rate in the hope that will work better, do you agree?

This didn't work well on the last beta version of AC3 for me. Once SoC was at target, I saw battery power charge/discharge fluctuations as it tried to hold the SoC. The magnitude depended on load, so if I had the car charging, I would see significant throughput, if just normal baseload it wasn't too bad. There is a risk of trading one problem for another.

What works best on AC3?

[mpartington]

Depends entirely on firmware. On the Old firmware,.setting battery discharge to zero is perfect. If you are on new firmware, then the best option by far is to use the pause function (screenshot in second post on this thread)

[springfall2008]

Can you share with me an automation to enable the freeze option, I could make this be a configuration setting to use it?

[mpartington]

So this will work on AC3 new firmware, and those inverters where you don't need to set a pause start and finish time (definitely Gen 1 - if it's ever released) i.e. it's just a toggle:

Automation I use is: action:

• service: select.select_option data: option: PauseBoth target: entity_id:
  • select.givtcp_inverter_serial_battery_pause_mode

your options are: Disabled - battery is not paused (normal operation) PauseBoth - pauses both charge and discharge PauseCharge - pause charge PauseDischarge - pause discharge

Looks like from comments above, for Gen 2, 3 and AIO need to also set the pause time slot - but you can set the time slot to 00:00 - 23.59 so that pause will be effective whenever it is set.

[wilsondw]

For Gen 2 (and I assume Gen 3 and AIO) the pause time slot entities are: select.givtcp_inverter_serial_battery_pause_end_time_slot select.givtcp_inverter_serial_battery_pause_start_time_slot

I think the reserve setting will work for many but not all as it is inverter/BMS firmware dependent. Some versions of the firmware can't hit specific SOC values so if you happen to try to 'freeze' on that value the system ends up cycling charging and discharging around the target point. Pause is probably the safest bet on all newer versions of firmware

[mpartington]

Coming back to this issue following it being raised again by new users.

I have implemented a standalone automation that sets the new 4x pause functions in the new firmware. It tracks in lockstep Predbats method of setting either charge rate, discharge rate or both to 100% or 0%. The chart below shows Hold Charge before and after the automation was switched on. There is a significant improvement in leakage. It reduces from 311W to just 28W (more than acceptable)

The automation (or similar) could be made available for users to copy (it is more complex as has repeat until set loops) or incorporated into Predbat and activated either by a toggle or auto recognition based on serial, firmware rev etc.)

HERE IS THE AUTOMATION

Pause.txt

[mpartington]

log files appdaemon.log

[gcoan]

For Gen 2 (and I assume Gen 3 and AIO) the pause time slot entities are: select.givtcp_inverter_serial_battery_pause_end_time_slot select.givtcp_inverter_serial_battery_pause_start_time_slot

Just FYI I've found out that if you're running a Gen 1 hybrid with the new "fast action" 191/193 firmware then these controls are also now available

[mpartington]

@springfall2008 just logging this.. I think something else is also going (possibly battery SOC is self adjusting), but just that to one side as I think the potential issue is probably still valid.

It looks like Predbat is instructing a charge freeze at 1am, before continuing to charge at 3am once the rates drop. This is perfect slot selection!

However it is managing the pause by just turning the scheduled charge toggle off and switching off discharge (i.e freeze charge). All the commands were correctly enacted on my system.

Freeze charge means the battery will continue to charge at the 'leakage' value, in my case here that seems to be around 300W, so we're not getting the benefit of the Pause as charging continues at a higher rate. I can't explain why the very first part seems to fully pause. The leakage was worth about 0.5kWh.

My proposal would be to instruct 'PauseBoth' if you want to hold charge by switching off charge schedule during a period of no solar generation.

Hope that makes sense, happy to explain further.

appdaemon.log

[mpartington]

Actually I'm wondering if this is more driven by what the BMS was doing. I can't see anything obvious in the log that is different for the period this worked (22:30 -00:00) and (01:00-01:37). Might need to blame GivEnergy on this one, looks like one of my batteries is realigning the SoC, upsetting the status quo. Was in ECO mode the whole time