springfall2008 / batpred

Home battery prediction and charging automation for Home Assistant, supporting many inverter types
https://springfall2008.github.io/batpred/
123 stars 43 forks source link

predbat not charging 3 phase Inverter #1426

Open LeeFarm11 opened 1 month ago

LeeFarm11 commented 1 month ago

Describe the bug predbat trying to charge but fails

Expected behavior From 21:00 predbat plan says it is going to Charge. But it does not.

Predbat version 1.1.23

Environment details

Gen 3 Giv 3 phase 11kW. 18kWp panels. 20.4kWh batteries

Screenshots image

Log file predbat(3).log

apps(1).yaml.zip

springfall2008 commented 1 month ago

I don't see anything obviously wrong in the logs.

Have you checked the history of the GivTCP settings to see if the charge start/end time was set correctly and the target soc? Maybe you have a setting wrong that Predbat doesn't use, can you go into the GE Cloud and use the remote control, read all the registers (little circle button) and then snapshot their values?

LeeFarm11 commented 1 month ago

I just did a manual force charge until 22:00 and then I reset everything in Remote Control as per below screen prints. This is my 'default' position.

image image

Then I turned on predbat (Read Only Off) at 22:14 Here is 22:10 plan image And the 22:15 plan image

So now predbat doesn't want any more charge, but is trying to FreezeCharge with Limit 62%. Back to Remote Control and I re-read each register. Only one which has changed is Discharge Down To % now at 63%. So it proves that predbat can make some changes.

image image

And then the next plan at 22:20 - image

And here is log file

predbat(4).log

LeeFarm11 commented 1 month ago

image

LeeFarm11 commented 1 month ago

I see enable_charge_schedule mentioned in the log.

2024-09-02 22:20:31.101753: Switch switch.givtcp_td2343g049_enable_charge_schedule is now on 2024-09-02 22:20:31.101830: Inverter 0 Wrote scheduled_charge_enable to True successfully and got on 2024-09-02 22:20:31.101868: Inverter 0 Turning on scheduled charge 2024-09-02 22:20:31.101899: Inverter 0 Turning off scheduled charge 2024-09-02 22:20:31.101943: Setting ECO mode as no discharge window planned But I think Mark took it out....

https://github.com/britkat1980/giv_tcp/issues/216

gcoan commented 1 month ago

So now predbat doesn't want any more charge, but is trying to FreezeCharge with Limit 62%. Back to Remote Control and I re-read each register. Only one which has changed is Discharge Down To % now at 63%. So it proves that predbat can make some changes.

That sounds consistent, a freeze charge is allowing charging but stopping the SoC from dropping (it's frozen),so hence the discharge down to % being set.

LeeFarm11 commented 1 month ago

Yes, but it is not having the desired effect. The Inverter is not holding SOC. The SOC is still dropping image

LeeFarm11 commented 1 month ago

Now getting itself confused. Here is 22:40 plan image

And here is the next 22:40 plan image

LeeFarm11 commented 1 month ago

And log file again predbat(5).log

And still not holding charge. image

LeeFarm11 commented 1 month ago

I am running GivTCP-Dev 2.4.736 I haven't heard any updates impacting 3 phase, but I will now update to 2.4.745 I'll also do the predbat updates. Then ready for next instalments with latest versions. :)

LeeFarm11 commented 1 month ago

This morning battery is flat and now using expensive electric from Grid. Log File attached.

image

image

predbat(6).log

LeeFarm11 commented 1 month ago

If enable_charge_shedule and enable_discharge_schedule are GivTCP entities which are 'needed' by predbat, but if those entities don't work on 3 phase Inverter, then what is the solution? I see 2 possibilities.

1) For predbat to identify the Inverter type and but takes some actions on other available entities on the Inverter if it is the 3 phase? or 2) GivTCP to build something which is called enable_discharge_schedule etc. but takes some actions on other available entities on the Inverter?

Which is the best/ correct solution?

gcoan commented 1 month ago

Personally I would lean towards GivTCP presenting all the GivEnergy inverters in a consistent way to Home Assistant then Predbat and any other automations don't need to understand the intricacies of different inverter logic's. GivTCP already presents the hybrid inverters, the AC inverter and the AIO (single and multiple's) in the same way so would hope that the 3-phase could also be consistent.

There is also the question of what the equivalent sequence of commands is in the 3 phase inverter if enable charge/discharge schedule isn't available?

When I first started with Home Assistant (before Predbat) and wrote my own automations I worked out how the GivEnergy app manages the inverter by changing app settings and seeing what HA controls changed. For my Gen 1 inverters a force charge/discharge was basically:

[there seems to be interlinking between the charge/discharge schedule switches and the mode]

The way Predbat does it is to set the appropriate start and end end times for the charge/discharge, it does that well in advance of the actual activity being required, and then before the slot (30 minutes or an hour I think) it enables the charge/discharge schedule. This way the inverter has all the charge/discharge setup and it automatically starts charging/discharging at the correct time and doesn't need Predbat to 'kick off' the activity at the allotted time. Prevents having to deal with comms issues and also the delay that occurs whilst Predbat recalculates the plan every 5 minutes.

britkat1980 commented 1 month ago

The key to this is to work out what ThreePhase controls could mimic enable_(dis)charge_schedule and represent it in the same fashion, looks like they aren't in the portal.

LeeFarm11 commented 2 weeks ago

During my tests when predbat was unable to force the Inverter to charge the Battery from the Grid I did notice another potential issue for the future. During the test, predbat was able to change some of the settings on the Inverter via GivTCP, but not all of the them. The settings which failed were the Enable Charge settings, but the slot settings were successfully changed.

Not sure if it should be mentioned here or if I should create a new issue.

There are 'general' settings in the Giv Portal for - Discharge Down To % Charge Up To % Discharge Power Rate (%) Charge Power Rate (%) Enable Force Charge Enable AC Charge Enable Force Discharge

The 3 phase inverter has 10 Charge slots and 10 Discharge slots. Based on what I saw during my tests I think predbat only uses one (or maybe 2) of the slots and ignores the other 8 or 9. But all 10 of the Discharge slots have 3 settings - Start Time, Stop Time and Lower SOC % Limit And all 10 of the Charge slots have 3 settings - Start Time, Stop Time and Upper SOC % Limit

Those 10 + 10 SOC % Limits are independent of 'Charge Down To %' and 'Charge Up To %'

The Inverter will only allow down to the higher of the slot Lower SOC % Limit and the Discharge Down To % during that slot. The Inverter will only allow up to the lower of the slot Upper SOC % Limit and the Charge Up To % during that slot.

Now, the issue I think is that predabt will ignore at least 8 of the Charge slots and Discharge slots. If the user has set them, then they will interfere with Predbat.

Should the user be informed of this 'feature', or should predbat reset all 10 + 10 slots to known values when it starts up?

gcoan commented 2 weeks ago

Should the user be informed of this 'feature', or should predbat reset all 10 + 10 slots to known values when it starts up?

Different GivEnergy inverters have different numbers of charge and discharge slots. Eg my gen 1 hybrid has 2 discharge slots and 1 charge slot. Newer inverters have 8 I think and your 3 phase has loads!

Predbat only ever uses slot 1 for charge and discharge. And yes, if there is something manually set in another slot then predbat won't know about it. Clearing the slots might be difficult as predbat would have to try to clear the other slots that might not exist, but if it were possible then it would be a useful enhancement as people do occasionally get caught out by this.

In the meantime I can add something to the documentation