Freeze Charge / Discharge Is Not Pausing AIO Battery Correctly

[nbullus]

Describe the bug I have an issue that has resurfaced which was working in a previous version. It is not clear at which version this stopped working.

When the battery is paused (pause charge, pause discharge or pause both), the battery continues to charge or discharge around 500 watts. Where surplus PV is being generated, then up to the first 500 watts is pushed to the battery first and any remaining surplus is exported to the grid.

This behaviour means the SOC continues to increase or decrease above/below the planned target, and this can also have a knock on effect of reducing the planned export costs given the battery is taking priority over grid export.

Expected behavior When a battery pause is enabled, battery charging and/or discharging should be paused. In the case of a charge pause, surplus PV should be exported. In the case of a discharge pause, only the surplus PV should be exported and nothing exported from the battery.

Talking to GivEnergy and doing some initial investigation of my own and talking to other members has confirmed that the battery is not being paused due to the battery being left in "Eco" mode rather than "Eco (Paused)". I understand that the "Eco (Paused)" mode is implicitly set by the value of the following two switches:

• Eco Mode = On
• Battery Power Mode = Off

It would therefore appear that when the battery pause is initiated, the Battery Power Mode is not being turned 'off' which leaves the mode as "Eco" and the battery continues to charge or discharge at around 500 watts. Manually changing this switch (after Predbat has initiated the Pause) has the desired effect and the battery stops charging/discharging completely.

When the battery pause is eventually disabled, the Battery Power Mode is being turned back 'on' as expected. Therefore the issue may only be when the pause is enabled and not when the pause is disabled.

It is not clear whether this issue effects the AIO inverter only or others as well.

Predbat version

Add-on v8.5.1

Environment details

• GivEnergy AIO
• Standard HAOS installer

Screenshots None

Log file The following log shows a Pause Charge being enabled at 14:30 followed by me manually turning "Eco (Paused)" mode on at 14:37

2024-10-18 14:30:21,274 - Inv1 - write - [INFO ] - Setting Battery Pause Mode to: PauseCharge 2024-10-18 14:30:22,793 - Inv1 - write - [INFO ] - Setting Battery Pause Mode to PauseCharge was a success 2024-10-18 14:30:31,307 - Inv1 - write - [INFO ] - Setting Charge Target to: 100 2024-10-18 14:30:33,843 - Inv1 - write - [INFO ] - Setting Charge Target 100 was a success 2024-10-18 14:37:18,510 - Inv1 - write - [INFO ] - Setting Battery Mode to: Eco (Paused) 2024-10-18 14:37:19,096 - Inv1 - write - [INFO ] - Setting dynamic mode was a success 2024-10-18 14:37:20,623 - Inv1 - write - [INFO ] - Setting shallow charge 100 was a success

The following log shows the pause being disabled at 14:55 followed by the "Eco" mode being set back automatically by enabling the Battery Power Mode:

2024-10-18 14:55:58,361 - Inv1 - write - [INFO ] - Setting Battery Pause Mode to: Disabled 2024-10-18 14:55:59,887 - Inv1 - write - [INFO ] - Setting Battery Pause Mode to Disabled was a success 2024-10-18 14:57:02,741 - Inv1 - write - [INFO ] - Setting Battery Power Mode to: enable 2024-10-18 14:57:03,063 - Inv1 - write - [INFO ] - Setting demand mode was a success 2024-10-18 14:57:32,847 - Inv1 - write - [INFO ] - Setting Battery Mode to: Eco 2024-10-18 14:57:37,754 - Inv1 - write - [INFO ] - Setting dynamic mode was a success 2024-10-18 14:57:39,291 - Inv1 - write - [INFO ] - Setting shallow charge 4 was a success

[springfall2008]

You might want to try the version on 'main' which has had some of this re-written and feedback?

[nbullus]

Will do. I'll keep you posted.

[nbullus]

First thing I have noticed is that when battery was discharging to house and iBoost kicked in, PauseDischarge was correctly set and status changed to "Hold for iboost", but battery continued to discharge to house/immersion at rate of 620 watts. After about 10 mins it switched to a Time Export anyway and turned off iBoost. If it had continued with "Hold for iboost" it would have drained battery to the immersion, so the PauseDischarge is not fully working with iBoost Hold.

[gcoan]

PauseDischarge was correctly set and status changed to "Hold for iboost", but battery continued to discharge to house/immersion at rate of 620 watts...If it had continued with "Hold for iboost" it would have drained battery to the immersion, so the PauseDischarge is not fully working with iBoost Hold.

Can you check when Predbat started 'hold for iboost', as well as PauseDischarge set, was the discharge rate on the AIO also set to zero? If so then there's probably not much more Predbat can do, it's instructing the AIO to stop discharging but the AIO isn't fully stopping. This would be down to the AIO firmware not Predbat's control.

Have seen similar issues before, usually the trickle discharge is at 200W though

[nbullus]

Yes discharge rate was zero.

GivEnergy have stated that to stop the battery from trickle discharging (mine is at 200-500+ watts depending on amount of PV surplus at the time), the battery needs to be put into "Eco (Paused)" mode. When GivEnergy did this for me, it had the desired effect and battery did not trickle discharge - 0 watts. So it can be done, but you need to set the required settings to move it to "Eco (Paused)".

[mpartington]

I've just tried setting ECO mode switch (on V3), known as battery power mode on V2, and it stops all discharge. It also sets the ECO(Paused) mode.

What this doesn't explain though on your system is why the PauseDischarge (GivTCP pause mode) doesn't have a similar effect. It should still pause (to within a few Watts) without going into eco pause mode. Have you tried pausing Predbat and selecting this mode directly in GivTCP? If that works as expected then it would suggest an interface issue between the 2, otherwise a GivTCP issue, or something related to the AIO firmware.

I'm on givtcp V3 with an AC3 and the pause function works perfectly. Now the only difference in implementation that I'm aware of is that the AIO also needs the pause start and end times to be set, so it is worth checking GivTCP to see if these are actually being changed.

I think the primary issue here is the battery isn't properly going into pause mode. Using battery power mode (or eco mode) is an alternative option that could be implemented, but it should work regardless of toggling that.

[nbullus]

Thanks for the info Matt. I'm currently testing the effect of some re-write changes that have been put onto 'Main' and so I will have a tinker with the above based on how the testing goes. I did previously set Battery Power Mode (GivTCP v2) whilst in Pause Discharge and this completely stopped any battery leakage and changes the Mode to "Eco (Paused). The Pause End Time was not set in this instance. I suspect the behaviour of the AIO may be different to other inverters and may behave differently again between v2 and v3 of GivTCP. I'll keep the thread updated.

[mpartington]

Had another play with my AC3 (now solar finally is greater than consumption) and the battery power/eco switch also stops charging. So essentially it is doing the same function as the GivTCP "PauseBoth" function. This isn't used within Predbat, so I don't think it would be a drop in solution.

There is another chap BG on the FB page that seems to be having very similar issues, also with an AIO, I've pointed him to this thread and the main version

[nbullus]

Tested Freeze Charge and still getting battery drain so 'Main' changes hasn't had an effect from what I can see.

Turning Battery Power Mode (GivTCP) on/off basically switches Eco mode on/off, which in turn flicks the control mode between "Eco" and "Eco (Paused)". Sometimes when I set Battery Power Mode Off, it has the desired effect and stops any battery discharge completely, but other times it doesn't seem to have any effect.

There have been times when Pause Discharge is set and discharge rate is zero, and when I switch to "Eco (Paused)" it works fine and battery doesn't drain. Then when the battery goes to Idle and then back into Freeze Charge it starts discharging battery again so this change doesn't seem to hold.

I am also bewildered by the 'givtcp_ch2316g434_enable_discharge' setting. This seems to be permanently 'on' and turning it 'off' just flicks it straight back 'on' again . Cannot see any equivalent register in the portal so not sure what registers this effects and may be a red herring.

The other thing I have noticed is that i cannot see my battery pause end time in Predbat, but checking the portal it shows as 23:59. I have reset my registers on the portal and this has now changed it to 00:00. Again, this may be a red herring and have no effect on this issue.

[gcoan]

The other thing I have noticed is that i cannot see my battery pause end time in Predbat

If you have non-REST setup in your apps.yaml you should see it there:

  pause_start_time:
    - select.givtcp_{geserial}_battery_pause_start_time_slot
  pause_end_time:
    - select.givtcp_{geserial}_battery_pause_end_time_slot

If using REST then Predbat will set the start and end time controls directly on the inverter

[nbullus]

The other thing I have noticed is that i cannot see my battery pause end time in Predbat

If you have non-REST setup in your apps.yaml you should see it there:

  pause_start_time:
    - select.givtcp_{geserial}_battery_pause_start_time_slot
  pause_end_time:
    - select.givtcp_{geserial}_battery_pause_end_time_slot

If using REST then Predbat will set the start and end time controls directly on the inverter

Yes I have a REST setup and also have the above Pause start/end times set in Apps.yaml

[mpartington]

Not sure it makes a difference in this case, however there is no rest endpoint for the pause command in GivTCP V2, so Predbat uses the fall back method via the entities. There is in GivTCP V3, however I don't think it has been implemented in Predbat yet.

23.59 may well have been correct. I would expect Predbat to simply set the pause start / end times for the full 24 hrs and then just cycle the pause mode as necessary.

I think one potential clarification is if it is purposeful that the pause times don't appear in the Predbat logs as being changed, but checking the entities directly in GivTCP should confirm if they are as expected

Have you tried setting the start and end times and PauseCharge or PauseDischarge directly in the portal (Predbat on read only) and does that work

[nbullus]

Not sure it makes a difference in this case, however there is no rest endpoint for the pause command in GivTCP V2, so Predbat uses the fall back method via the entities. There is in GivTCP V3, however I don't think it has been implemented in Predbat yet.

23.59 may well have been correct. I would expect Predbat to simply set the pause start / end times for the full 24 hrs and then just cycle the pause mode as necessary.

I think one potential clarification is if it is purposeful that the pause times don't appear in the Predbat logs as being changed, but checking the entities directly in GivTCP should confirm if they are as expected

Have you tried setting the start and end times and PauseCharge or PauseDischarge directly in the portal (Predbat on read only) and does that work

That's a good shout. I'll try the Pause directly in portal with Predbat in read-only and see if there is any difference in behaviour. I'll try this later tonight.

With regards the Pause Times, I can see the start time but not the end in GivTCP. I can see both start and end on the portal. I don't actually see the end time as a setting in GivTCP at all. I just assumed it would be 'select.givtcp_ch2316g434_battery_pause_end_time_slot' but it may not exist which is why its not displaying. Should end time be 00:00 or 23:59?

[gcoan]

I think one potential clarification is if it is purposeful that the pause times don't appear in the Predbat logs as being changed, but checking the entities directly in GivTCP should confirm if they are as expected

With regards the Pause Times, I can see the start time but not the end in GivTCP. I can see both start and end on the portal. I don't actually see the end time as a setting in GivTCP at all. I just assumed it would be 'select.givtcp_ch2316g434_battery_pause_end_time_slot' but it may not exist which is why its not displaying. Should end time be 00:00 or 23:59?

Predbat sets the start and end times to 00:00:00 and 23:59:00 respectively, but only if they are not already set to these times. It then toggles the pause mode as and when necessary.

From inverter.py:

        # Some inverters have start/end time registers
        new_start_time = "00:00:00"
        new_end_time = "23:59:00"

        # GE Cloud has different pause names
        if old_pause_mode in ["Not Paused", "Pause Charge", "Pause Discharge", "Pause Charge & Discharge"]:
            pause_cloud = True
        else:
            pause_cloud = False

        # Not Paused, Pause Charge, Pause Discharge, Pause Charge & Discharge
        if pause_charge and pause_discharge:
            new_pause_mode = "Pause Charge & Discharge" if pause_cloud else "PauseBoth"
        elif pause_charge:
            new_pause_mode = "Pause Charge" if pause_cloud else "PauseCharge"
        elif pause_discharge:
            new_pause_mode = "Pause Discharge" if pause_cloud else "PauseDischarge"
        else:
            new_pause_mode = "Not Paused" if pause_cloud else "Disabled"

        if old_start_time and old_start_time != new_start_time:
            # Don't poll as inverters with no registers will fail
            self.base.set_state_wrapper(entity_start, state=new_start_time)
            self.base.log("Inverter {} set pause start time to {}".format(self.id, new_start_time))
        if old_end_time and old_end_time != new_end_time:
            # Don't poll as inverters with no registers will fail
            self.base.set_state_wrapper(entity_end, state=new_end_time)
            self.base.log("Inverter {} set pause end time to {}".format(self.id, new_end_time))

[nbullus]

Just tried a few things out. Firstly I set the Pause End Slot Time to "23:59" and now I can see this value in Predbat and GivTCP.

I then put Predbat into read-only mode, and initially used the Pause button on the GE app. This sets the Charge and Discharge rates both to zero, but doesn't set the Pause mode (Not Paused). The battery continues to discharge at a rate matching home demand.

I then manually set the Pause mode to "Pause Discharge". This split the house load between battery (40%) and grid (60%).

I then changed the Pause Mode to "Pause Charge & Discharge" and this split the house load between battery (10%) and grid (90%).

I think this proves that something is not right here with my inverter as it demonstrates a number of issues:

1. Pause button on the app doesn't even set a Pause Mode, but leaves it as Disabled.
2. "Pause Discharge" and "Pause Both" alter the percentage of the battery draw by different percentages rather than stop discharge completely.
3. Play button restores the Charge and Discharge rates back to 6000w, but doesn't revert Pause mode back to Disabled.

This is very odd and I've asked the GE group if anyone else has seen this behaviour. I think I need to contact GE tech support again tomorrow to find out whats happening? Not sure anyone else is having this issue with the AIO or not?

[mpartington]

The pause button in the GE app only sets the charge and discharge rates to zero. Unfortunately they are yet to implement the new way of pausing (I think to maintain compatibility with the oldest gen 1 inverters). So this is normal behaviour, but I understand at some point this will change. Unfortunately via official means, setting Pause can only be done via the remote control screen on the portal

I suspect this also covers point 3, as the app button can't switch off pause. So nothing wrong/abnormal so far with what you've observed.

What is interesting is point 2. Where are you setting the pause modes, the portal? That behaviour just doesn't seem right. Pause should be much less than 10%, reducing charge or discharge to a handful of watts. Its starting to sound like buggy AIO firmware or something needs resetting (possibly a hidden setting).

[nbullus]

The pause button in the GE app only sets the charge and discharge rates to zero. Unfortunately they are yet to implement the new way of pausing (I think to maintain compatibility with the oldest gen 1 inverters). So this is normal behaviour, but I understand at some point this will change. Unfortunately via official means, setting Pause can only be done via the remote control screen on the portal

I suspect this also covers point 3, as the app button can't switch off pause. So nothing wrong/abnormal so far with what you've observed.

What is interesting is point 2. Where are you setting the pause modes, the portal? That behaviour just doesn't seem right. Pause should be much less than 10%, reducing charge or discharge to a handful of watts. Its starting to sound like buggy AIO firmware or something needs resetting (possibly a hidden setting).

Thanks for clarifying points 1 & 3.

regarding point 2, I set this on the GE portal. According to Paul L on the other group, he says Pause Discharge should reduce the discharge to 30 watts which is clearly not happening.

[mpartington]

Sounds like you've pinpointed the cause of your issues. Just working out what the solution is now

On Mon, 21 Oct 2024, 20:06 nbullus, @.***> wrote:

The pause button in the GE app only sets the charge and discharge rates to zero. Unfortunately they are yet to implement the new way of pausing (I think to maintain compatibility with the oldest gen 1 inverters). So this is normal behaviour, but I understand at some point this will change. Unfortunately via official means, setting Pause can only be done via the remote control screen on the portal

I suspect this also covers point 3, as the app button can't switch off pause. So nothing wrong/abnormal so far with what you've observed.

What is interesting is point 2. Where are you setting the pause modes, the portal? That behaviour just doesn't seem right. Pause should be much less than 10%, reducing charge or discharge to a handful of watts. Its starting to sound like buggy AIO firmware or something needs resetting (possibly a hidden setting).

Thanks for clarifying points 1 & 3.

regarding point 2, I set this on the GE portal. According to Paul L on the other group, he says Pause Discharge should reduce the discharge to 30 watts which is clearly not happening.

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/1552#issuecomment-2427502932, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZQHXHIY6RVNW52GXXQXTBTZ4VGE3AVCNFSM6AAAAABQGEW7U2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRXGUYDEOJTGI . You are receiving this because you commented.Message ID: @.***>

[gcoan]

I don't see why the GivEnergy app can't work out what kind of capabilities your GivEnergy firmware has and set the inverter accordingly. That's precisely what Predbat does, if you have pause mode, it'll set it, if not, it only changes the discharge rate,

I'm not surprised with this behaviour but its not acceptable in my view, its a bug in the app.

On my gen 1 hybrid inverters with 191/193 fast response firmware which does have battery pause support, my discharging rate drops down to 20W or so. Does sound like a firmware issue

[nbullus]

Thanks all.

I'll contact GE support in the mrning and find out what issue is. I'm pretty sure it was working fine when the Pause was first introduced into Predbat, but i think i've done 1-2 firmware updates since then so may have broken it again.

[nbullus]

Bizzarely, Predbat has just instigated a Pause Discharge (Freeze Charge), and battery has stopped discharging, i.e. 0 watts. I've asked Paul L if he has made any changes, because if he has, it has had a very positive affect. I'll monitor and see if the changes continues to pause battery as expected and try and find out what he changed. Finger crosssed.

[nbullus]

I contacted Paul L and he confirmed he hasn't changed any inverter settings, so its a mystery as to what has happened. Anyway I have been monitoring the discharge pause throughout the day and most of the time it seemed to behave and do what it is supposed to do. On a few occasions there was a small amount of leakage, but most of the time there was no leakage, although Paul stated it would be 30 watts when Pause Discharge was set.

I'm starting to be convinced that the issue is the GivTCP Enable Discharge switch not being activated every time there is a Pause Discharge. Comparing various sensors side by side confirms that there are few times when this switch is not being turned off which can be seen in the screenshot.

Comparing the sensor lines in parallel time shows the following:

1. GivTCP control mode - ECO on for this whole duration.
2. predbat.status - flicking between blue (Freeze Charge) and brown (Idle)
3. GivTCP battery pause mode - flicking between green (Pause Discharge) and blue (Disabled)
4. GivTCP enable discharge - flicking between orange (discharge on) and grey (discharge off)
5. GivTCp discharge rate - alternating between 0 and 6000w on the graph

As is now seen, everything lines up except for the GivTCP Enable Discharge. Sometimes it lines up and sometimes it sticks and becomes out of step. Generally, it turns 'off' when Pause Discharge is set, and 'on' when pause is disabled. There maybe another sensor which i cannot see yet which also has a bearing on this state, but as of yet I haven't seen any pattern.

Something I want to rule out as a possibility is the fact that delays in some of these senors changing coincides with a Predbat re-plan and it throws it out of kilter due to pure timing. There are times when the GivTCP Enable Discharge is changing state multiple times within 2-3 minute period. Also my machine may not be quick enough to keep up and things changing before its even finished reacting. I will therefore increase the frequency of the re-plans from 5 to 10 minutes and see if I get things more in alignment and stable, or whether they stay the same.

[nbullus]

So today the Freeze Charge & Discharge have been working as expected with very little battery drain. There have been a couple of times where something is turning GivTCP Enable Discharge switch 'on' when it is meant to be 'off'. Predbat appears to be turning it back 'off' at the next 5 minute interval and this can happen three or four times in quick succession. The following screenshot shows the grey 'off' period with short orange 'on' periods where something is trying to turn it back 'on' (see 13:30-14:10 on timeline):

What I cannot work out is what is turning it 'on' as this is what causes the battery leakage and it starts discharging. There is nothing in the GivTCP, Predbat or GE portal logs at these 'on' times so unsure if Predbat is instigating this directly or indirectly, or something else? I think the GE advice about Eco (Paused) being switched on has nothing to do with this issue as its never been set when battery was paused today and it seems quite happy to stay in normal Eco mode throughout.

[nbullus]

Still not got to bottom of whats causing the the random changes to Enable Discharge switch. I've restarted GivTCP and its been working fine again for last 12 hours. I'll see how long it goes before it starts playing up again as it may be a GivTCP issue.

[springfall2008]

I made some fixes to the control code in the latest predbat that maybe worth testing with?

[nbullus]

I made some fixes to the control code in the latest predbat that maybe worth testing with?

Thank you. Just moved to v8.5.3 so I'll monitor it again over next few days and let you know.