Battery_Rate_Max type error in 8.34.8 - expecting int but float supplied

[NeoVR]

On updating to 8.34.8 - predbat reports an error in apps.yaml for the "battery_rate_max" value with error:
Warn: Validation of apps.yaml found configuration item 'battery_rate_max' element sensor.sigen_plant_available_max_active_power is not a valid type integer

Rolling back to 8.34.7 does not show this issue.

Expected behaviour
No error in apps.yaml

Predbat version
8.34.8

Environment details
Sigenergy Sigenstor 8kw inverter - 18.08KW of battery capacity
Predbat running in HAOS

Log file

predbat.log

[springfall2008]

Seems unrelated, I suspect you just hit a time when the sensor was invalid

[davesbell]

I've got the same issue with the same inverter.

I think the issue is that the sensor is returning a float, but the config is validating to an int.

Seems to relate to this line which was updated yesterday:
https://github.com/springfall2008/batpred/blame/b604555e6be6dda90e61b4f80410e9f72fc73a35/apps/predbat/config.py#L2061

Here is the sensor:

[gcoan]

battery_rate_max should be an integer battery size in watts https://springfall2008.github.io/batpred/apps-yaml/#battery-information

so it is right that its validated to be a number not a float

predbat has relaxed some of the rules as to unit of measure, accepting and automatically converting kW to W, so hence why you can use the inverter kW entity, but its getting rejected as a validation error

so one fix is to just change to using a fixed watts number in apps.yaml rather than the inverter sensor the

[davesbell]

Ah. I'm using https://github.com/springfall2008/batpred/blob/main/templates/sigenergy_sigenstor.yaml as the base for my config, so presumably a lot of other people are also. This means that there are going to be a bunch of people who now have an error in their config.

Is there any way to do fancy maths to fix this in the config? Something like:

{{ sensor.sigen_plant_available_max_active_power * 1000 | int }}

I can't see any examples of this, so I'm assuming not. I guess the easiest fix (since you can add/remove batteries and affect the max power) is to create a helper sensor that does that conversion, and use that instead.

[gcoan]

Ah. I'm using https://github.com/springfall2008/batpred/blob/main/templates/sigenergy_sigenstor.yaml as the base for my config, so presumably a lot of other people are also. This means that there are going to be a bunch of people who now have an error in their config.

Yes, I know. I was explaining why this is occurring, it is a consequence of changes made elsewhere that is now impacting Sigenergy users.

Is there any way to do fancy maths to fix this in the config? Something like:

{{ sensor.sigen_plant_available_max_active_power * 1000 | int }}

No, apps.yaml isn't that clever, no Jinja code.

For most people the battery max power isn't going to change, so setting a fixed entry is a workaround until predbat can be fixed to accept floats again

[leacho73]

Same problem with SolarEdge Battery/Inverter - happy to open another bug if required.

[gcoan]

Same problem with SolarEdge Battery/Inverter - happy to open another bug if required.

no, its the same bug/predbat feature

[leacho73]

I can confirm that rolling back to v8.34.7 the bug isn't present.

[darkorb]

Well that partly explains why mine exploded and stopped doing plans that made any sense I guess... without setting it to watts manually for my sigen plans were just 🤷🏼‍♂️ so it'd been manging nothing for three days until I fixed it just now 🤦🏼‍♂️