"Current PV" sensor no longer tracking pv_today properly.

[TCWORLD]

Describe the bug
A clear and concise description of what the bug is.

The "Current PV' sensor is supposed to mirror the sensor in the pv_today config entity. However at some point in the last few days it seems to no longer be mirroring properly.

By the looks of it, there seems to be sometimes a residual amount from the previous day that's being subtracted from it.

Expected behaviour
A clear and concise description of what you expected to happen.

Current PV and pv_today should be the same.

Predbat version
V8.27.21

Environment details

• Inverter and battery setup
• Standard HAOS installer or Docker
• Anything else?

Screenshots
If applicable, add screenshots to help explain your problem. The most useful ones can be your battery chart, the Predbat HTML plan and your current settings in HA.

Log file
Can you capture a log file from the time of the issue, debug mode is not normally required.

You can download the logfile from the WebUI on the Dash tab select predbat_debug.log

Predbat debug yaml file
This is important for any plan related issues.

Once you have captured the issue go to the Web UI, in the Dash tab click on predbat_debug.yaml and wait 30 seconds for it to download. Select 'keep' if your Web Browser thinks the file is dangerous.

Rename the download file to predbat_debug.yaml.txt and upload it to Github. This will allow your plan to be reproduced and also stores all your settings for review.

[TCWORLD]

I guess this comes from this line:

batpred/apps/predbat/fetch.py

Lines 517 to 521 in de20ec1

	if "pv_today" in self.args:
	self.pv_today = self.minute_data_import_export(self.now_utc, "pv_today", required_unit="kWh")
	self.pv_today_now = max(self.pv_today.get(0, 0) - self.pv_today.get(self.minutes_now, 0), 0)
	else:
	self.log("Warn: You have not set pv_today in apps.yaml, you will have no previous pv data")

That's by the looks of it removing the value at the start of the day (00:00:00) presumably to allow for sensors that are lifetime totals.

For the SolaX setup (#259) we use daily tally's that reset at midnight. However due to polling delays reading the values and slight RTC mismatches, this reset happens between 00:00:10 and 00:00:25 in my case. The days where the PV today is wrong are days where this is at the slower end.

This will also be affecting the day imported and exported energy values too if used.

Two possibilities to fix if support for day resetting sensors is desirable (the name in apps.yaml suggests they are):

1. Add a config option to day "energy sensors reset at midnight", which if true means the start of day value is not subtracted. Would have no impact on non-resetting sensors.
2. Using 00:01:00 (self.minutes_now - 1) as the start of day values to accommodate slight latencies in measurement. The impact on both resetting and non-resetting sensors would be a likely minimal inaccuracy.

If daily sensors are unsupported, for SolaX I can just switch to the total sensors rather than the todays sensors.

[gcoan]

For the SolaX setup (#259) we use daily tally's that reset at midnight. However due to polling delays reading the values and slight RTC mismatches, this reset happens between 00:00:10 and 00:00:25 in my case. The days where the PV today is wrong are days where this is at the slower end.

Pretty sure predbat requires these to be properly 'today' sensors. We've been having problems in predbat with the _today sensors from our givenergy inverters (via givtcp) not resetting properly at midnight.
If you don't have a reliable today sensor, can you wrap the 'total' sensor up in a utility meter that HA will reset each day?

[TCWORLD]

@gcoan The sensors are "today" resetting on the inverter, but reading in takes 10 to 25 seconds. I imagine most integrations reading remote registers will have a similar latency.

Looking at the logic there it seems like predbat would be happier with non-resetting total sensors based on the inclusion of the logic subtracting the value from the start of the day. It seems like a sledgehammer to crack a nut adding extra utility meters to remove a sub-minute latency.

[gcoan]

The UM was just a suggestion. It would be better if predbat didn't need today sensors and could take total sensors as well, so why don't you try changing the code and see if it works?
And then PR it in if successful. Or I can include in my next PR, but you should take the credit !

[TCWORLD]

Aye. Planning on playing with it tomorrow.

[TCWORLD]

Had a go adding in an option for adding am optional start of day offset to the todays load/import/export/pv sensor data (https://github.com/springfall2008/batpred/compare/main...TCWORLD:batpred:today-sensor?expand=1).

Wasn't sure whether the option was best added under APPS_CONFIG or APPS_SCHEMA, I tried the former but it was causing odd errors so I'm trying the latter for now.

It appears to work, though today the reset latency was on the early side so I'm going to have to keep checking for a random day that would have otherwise triggered the problem. Looking at the logs of the load_today sensor though it does seem to work - I can see when I change the start delay to 1 minute from 0 minutes, the load_today_now value drops by 0,01kWh (the amount it increased in that first minute of the day).

[springfall2008]

I've made this fix now in a different way, on 'main' please re-test

[TCWORLD]

@springfall2008 Yep appears to be sorted now, thanks.