springfall2008
Issue: predbat setting charge_rate or discharge_rate to 5000 in monitor mode on startup
Describe the bug In Monitor Mode with GE REST disabled, predbat attempts to set charge_rate or discharge_rate to 5000 on startup. This behaviour should not occur in Monitor Mode, and it's unclear where the 5000 value is originating from.
It does not appear to be related to battery_rate_max or any settings in apps.yaml or predbat_config.json.
It's possible it's linked to the MQTT topic? name: Battery Discharge Rate state_topic: GivEnergy/GW2330G088/Control/Battery_Discharge_Rate max: 5000
Expected behavior predbat should not be setting any rates (charge_rate or discharge_rate) in Monitor Mode.
Predbat version 8.3.2
Environment details Inverter and battery setup: GE Gateway + 2x 13.5kWh AIO Standard HAOS installer or Docker: HASSOS
Your battery chart - N/A, crashes before generation The Predbat HTML plan - N/A, crashes before generation Your current settings in Home Assistant predbat_config.json
Log file write error.txt
Agree it shouldn't be trying to set the discharge rate when in monitor mode.
There's something weird with some of the other sensors, both charge and discharge rate are currently reported as zero (which is probably why Predbat is trying to change this), and current SoC is 31.92kWh which is too high as well. Worth checking what the actual sensors are in HA as these could be GivTCP bugs.
Are you using the GivTCP beta or the main 'prod' release? The beta has better support for AIO including multiple AIO configs.
Are you using the GivTCP beta or the main 'prod' release? The beta has better support for AIO including multiple AIO configs.
Beta - the data from the gateway is different than that from an inverter:
There's something weird with some of the other sensors, both charge and discharge rate are currently reported as zero (which is probably why Predbat is trying to change this),
Agreed - when in Dual AIO mode, we need to control the AC registers (see https://github.com/springfall2008/batpred/issues/1361)
and current SoC is 31.92kWh which is too high as well. Worth checking what the actual sensors are in HA as these could be GivTCP bugs.
The SoC kWh is correct - that's 2x fully charged 13.5 AIOs.
There's something weird with some of the other sensors, both charge and discharge rate are currently reported as zero (which is probably why Predbat is trying to change this), Agreed - when in Dual AIO mode, we need to control the AC registers (see #1361)
Think it is worth you raising a similar ticket on GivTCP. It would make life a lot easier if GivTCP could hide the differences for different inverter types and present multi-AIO inverters in a consistent manner to the other inverter types.
At present Predbat doesn't have to distinguish between AIO's, AC3's, Hybrids, etc, so would argue that multi-AIO's should work the same as all the other inverter types and not need special coding.
and current SoC is 31.92kWh which is too high as well. Worth checking what the actual sensors are in HA as these could be GivTCP bugs. The SoC kWh is correct - that's 2x fully charged 13.5 AIOs.
No, that's not correct. 2x 13.5 is 27kWh.
The AIO incorrectly reports its full battery size, not the usable battery size which is what Predbat needs. You will need to set battery scaling in apps.yaml https://springfall2008.github.io/batpred/apps-yaml/#battery-size-scaling
Thanks @gcoan, I had missed the fact predbat needs to work with usable capacity for some reason. I had it in my head that it was a 15.9kWh battery with a X% reserve... fixed!
At present Predbat doesn't have to distinguish between AIO's, AC3's, Hybrids, etc, so would argue that multi-AIO's should work the same as all the other inverter types and not need special coding.
True, although there is probably another brand out there which sets charge/discharge rate in % not W?
I think for now I'm going to create a couple of helpers and an automation which monitors (dis)charge_rate and then converts this to the new percentage rate and vice versa.
No worries.
I will add something to the documentation to cover scaling the battery size for multiple AIO's.
I also see you're engaged in other discussions about SoC for multiple AIO's https://github.com/britkat1980/giv_tcp/issues/204
All very new for everyone.
Yeah I’m in the same boat, had to disable rest and I did create a bunch of sensors myself so predbat could see it as a single invertor. It mostly works but we need to work with GivTCP to get the gateway entity to publish all the combined infor required.
however there is one thing I don’t think givTCp can fix and that’s the way the gateway controls charge and discharge rate. The gateway reports 0 charge or discharge rate and uses % of the individual AIO rates to control them. I had to fudge this with fake input helpers to get it working.
