8.17.0 incorrect error on inverter_limit_charge=0

[gcoan]

Describe the bug Upgraded to 8.17.0

predbat is reporting 1 error:

The error below is reporting a problem with inverter_limit_charge:

Which in my apps.yaml is actually perfectly correct:

  inverter_limit_charge:
    - 2600
    - 2600

The logfile actually shows what predbat thinks is the error:

Expected behaviour There's two problems:

1. Validation of inverter_limit_charge is incorrectly flagging that a charge rate of 0 is not an integer

2. The reporting of the validation error (and this may well be the web ui for apps.yaml) doesn't distinguish correctly between apps.yaml values in the file and things that have been overwritten with predbat_manual_api. In my case I have overwritten the default 2600 charge rate to be zero in an attempt to reduce clipping. Good that it is being validated but (point 1) zero is a valid integer value and the error reporting in the UI points me to the apps.yaml file entry not the overwritten manual API entry:

(the double setting for inverter 1 is a different issue #2153)

3. One other minor thing, the vertical alignment of the headings in the web UI has done 'off' when an error is displayed (apps.yaml is noticeable lower than the other headings)

4. I am guessing that the apps.yaml validation only runs periodically because its still reporting the same error in the logfile:

Even though I have now cleared the predbat_manual_api setting of inverter_charge_limit(1)=0

Predbat version 8.17.0

Environment details HAOS 2025.5.3 2x gen 1 hybrid

Log file

predbat.log

Predbat debug yaml file predbat_debug.txt

[springfall2008]

I've pushed a fixed to main to test

[gcoan]

Thanks Trefor for a quick fix, I set inverter_limit_charge(1)=0 as it was before:

Upgraded, and no error on inverter_limit_charge, but getting num_cars rejected now!

2025-03-29 13:47:10.340925: Warn: Validation of apps.yaml found configuration item 'num_cars' is zero 2025-03-29 13:47:10.342697: Error: Validation of apps.yaml found 1 configuration errors

predbat.log

[springfall2008]

Another fix on main for testing

[gcoan]

Interesting results.

Am no longer getting an error on inverter_limit_charge nor num_cars being zero, which is good

Am now getting a new error on pv_power only being set to one entity not two

this is probably a fair error. I have two GivEnergy inverters declared to predbat in apps.yaml, but also a separate AC FIT inverter, monitored via a Shelly EM clamp.

I sum all those 3 PV power values together every 3 minutes in a total_pv_power entity and that's what I have configured in apps.yaml. I didn't think Predbat did anything with the individual inverter PV power breakdown, it only used the total, and since I had this sensor for Apex generation vs forecast charts, I also fed it into Predbat so that the Predbat graphs also matched.

Since there is nothing that can be controlled on this inverter its not declared in apps.yaml. I suppose I could change num_inverters to 3 and add a dummy non-controllable inverter type?

Any suggestions as to what to do with this?

[springfall2008]

Maybe add a zero e.g.

pv_power:

• sensor.total_solar_power
• 0

[gcoan]

Thanks, I tried that, seems to have stopped the pv_power error

I am however getting errors on inverter_limit_charge now with 8.17.1:

11807 | 2025-03-29 23:08:43.391386: Error: Validation of apps.yaml found 1 configuration errors 11806 | 2025-03-29 23:08:43.390624: Warn: Validation of apps.yaml found configuration item 'inverter_limit_charge' is not a list but requires 2 entries based on num_inverters

inverter_limit_charge is a list as set in apps.yaml, and is overwritten in predbat_manual_api:

I have overwritten both inverter_limit_charge entries via the manual api but the predbat validation is saying this is an error

[springfall2008]

Have you tried the latest release for this?

[gcoan]

Have you tried the latest release for this?

I haven't. I am currently holding on 8.17.1 because the fix you made to #2153 in 8.17.2 didn't work with my two inverters. The charge rate for inverter 0 was being read by inverter 1 all the time.

If you are able to take another look at #2153 please Trefor I can then confirm that this is hopefully fixed

[gcoan]

all fixed now