springfall2008
GivTCP Writes Excessive - linked to 'Setting Eco mode' very frequantly (3 Phase System)
Describe the bug
Excessive GivTCP writes, on reviewing the GivTCP-Beta log, I can see a very large number of attempts to set the Eco mode. Approx. every 5 minutes.
Small snippet of the log file
2025-02-28 13:00:04,207 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-28 13:05:04,508 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-28 13:10:03,586 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-28 13:15:03,846 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-28 13:20:03,903 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-28 13:25:04,444 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-28 13:30:00,706 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-28 13:35:03,479 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-28 13:40:05,274 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-28 13:45:04,045 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-28 13:50:04,321 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-28 13:55:04,254 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-28 14:00:03,326 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-28 14:05:04,574 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-28 14:10:04,174 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-28 14:10:04,174 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-28 14:15:04,989 - GivTCP - write - [INFO ] - Setting Eco mode was a success 2025-02-28 14:20:07,783 - GivTCP - write - [INFO ] - Setting Eco mode was a success
Expected behaviour Only see a very limited number of attempt to set the Eco mode...
Predbat version
v8.15.1
Environment details
GIV-3HY-11 GivEnergy battery module stack - 51.8 Ah | 20.29 kWh | (6 Packs) HAOS on PC hardware (dedicated)
Screenshots This is an error from the main HA log file - possibly linked, as there is reference to attempting to set an invalid state for Eco Mode.
These writes do not appear to be ending up as 'real' writes to the Inverter
Log file Can you capture a log file from the time of the issue, debug mode is not normally required.
Predbat debug yaml file Enable debug mode and let Predbat run for one cycle. Look in the 'debug' directory under the Predbat add-on and take the .yaml file for the time period in question. Rename the predbat_debug_XX_XX_XX.yaml to predbat_debug_XX_XX_XX.yaml.txt and upload it to Github. This will allow your plan to be reproduced and also stores all your settings for review.
If you look at the inverter mode control in HA, I assume Eco mode is one of the options.
What happens if you set it to Eco mode?
If you look in the event log, what changes do you see for the inverter mode?
Does it get written to the inverter correctly and does the control then show Eco is set?
My guess is that this is actually a problem with GivTCP, that setting Eco mode in HA which is reported as successful in GivTCP, but the next time Predbat runs it finds that Eco mode isn't set in the HA control so it sets it again
Surprised though you are seeing this issue, the others with 3 phase inverters haven't report it
As far as i know (I have only seen a 3 phase Inverter), there is a fundamental difference between the 3 phase inverters and all the others -
The 3 phase inverters do not have any 'Modes'. There is no such thing as an Eco mode switch.
For the 3 phase it translates as ensuring that Enable Dicharge is Off (or there are no active Discharge time slots) and Enable Charge and Enable AC Charge are both Off (or there are no active Charge time slots).
@gcoan The above is very fundamental which needs to be understood. I think you suggested that we probably need the 3 phase Inverter to be looked at by predbat as different to the other Giv Inverters. I believe this is correct. Effectively the 3 phase is as different to the previous Giv Inverters as a Solis or Tesla Inverter (well not quite, but hopefully you see what I mean)
If those settings are set, then the Solar and Battery will satisfy Load until either the Battery is empty (at which point it will draw from the Grid) or the Battery is full (at which point it will export to the Grid). I think this is what is generally referred to as Eco mode on the other Inverters.
I don't think that predbat via GivTCP has yet got that level of 'knowledge' built in to be able to fully read that back without error to GivTCP, but it is probably achieving success, but with error messages like you see.
I have not yet tested the suggestions of @trevordowling here - https://github.com/springfall2008/batpred/issues/2057
Excellent, I agree (again) we need to deal with the 3 phase separately as its got some quite different options @LeeFarm11
This explains why setting Eco mode isn't settable, GivTCP thinks it is but next Predbat run, it tries again. So good news is this excessive number of inverter register writes is not real as the inverter will be rejecting the commands.
How did you get around the lack of Eco mode with Predbat?
I was using my automation posted elsewhere which turned those switches on or off depending on predbat.status.
The timeslots did not need to be included in the automation because they were were handled ok by predbat and GivTCP without intervention.
But only properly worked for Charging, Exporting, Demand. The other statuses I think I was effectively mapping others to one of those 3.
Thanks @LeeFarm11 what did you do about the inverter mode in apps.yaml that predbat wants to set to Eco for @trevordowling but this doesn't work on givtcp. Use a dummy helper entity that predbat can set I assume?
All the details and the development are posted in these 2 issues.
https://github.com/springfall2008/batpred/issues/1607 https://github.com/britkat1980/giv_tcp/issues/286
Based on feedback from @britkat1980 after release of a new Dev version I did turn off my automation but left REST turned OFF. I think it was an improvement but not sure.
I have been focussing on trying to identify what happens with all the different combinations of the 3 switches and global percentages we have (along with timeslots and timeslot specific percentages we have) and it is really weird. Various combinations with Force Charge Enabled can result in Discharge and vice versa. I might post my results early next week. I'm trying to identify setups which can equate to Hold Charge etc. and so far I'm failing to find settings which work correctly with Sun out and also when sun disappears behind a cloud and also work if SOC is just above and just below the Target SOC.
What does the Predbat log show? Maybe we need to configure another inverter type but without having access to such a system or knowing what the controls are its hard for me to help.
I generated this dump of all entities defined for my system (GIV-3HY-11) - might be of use to review against the single phase equivilant.
GivEnergy MQTT Entities for GIV-3HY-11 Hybrid Inverter v2.xlsx