-
-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Predbat shows jumps in actual cost figure despite also showing no increase in consumption #1663
Comments
Here's the entire appdaemon.log file from 09:00 to 09:15 this morning as I assume there answer will be in here somewhere but I've looked through and I can't figure out how the cost figure was reached |
Maybe it isn't quite as random as I thought, same time as yesterday (16:20) and the import cost jumped, yesterday £5.03 to £7.61 and today £5.33 to £8.08
Cost in p/kWh changes massively around these times too: Trying to pick my way through the code, it seems there's three LOG outputs from the today_cost function:
I can't see anything really wrong in the code so I've added some more logging to grab the values as it cycles through each minute's data to calculate the values, will update when it next hits the issue. |
Got another one, with the extra logging enabled which is the following to output the minute, import, load, rate and cost for every individual minute in the previous hour:
So, during the run at 21:30 Predbat recorded the rate for all minutes from 1231 (20:31) to 1290 (21:31) as 7 pence:
However, in the 22:05 run, it now shows some of those same historic minutes as having a price of 26p - this is 'in the past' and so should be totally unchanged. My car was plugged in at 19:23 and Intelligent Dispatching started at 19:24 and remained on the whole time with the actual price being 7 pence Something has clearly overwritten the values in between the 22:00 and 22:05 runs which has then totally messed up the cost calculation.
If anyone can point me where to start looking to find how those rates are getting changed, it'll save me a load of digging as there's a lot more .py files with rate_import in than with cost_import! |
Happened again, and I can see that the 9am scan today dropped out a previous 'smart-charge' slot from IOG which ran from 6am to 8am:
That makes sense from an Octopus point of view, there's no need to maintain previous slots once the time they were active has ended (though I'm not sure why the source 'None' ones persist for a day or two but the source 'smart-charge' do not). In any case, it doesn't seem unrealistic for that to be happening as they've got to stop being advertised at some point. So, the issue is that Predbat is retrospectively recalculating previous usage, which is incorrect because those transient low-rate slots are not longer being returned by the Octopus integration. |
Don't know how to solve this but can't believe I'm the only one it is affecting. From what I can tell, today_cost actually goes through every minute of today each time it runs to recalculate the costs (day_cost and day_cost_import) based on whatever data is has 'now':
This means at 23:55 it will rerun the entire day's costs, despite having already calculated them (correctly) throughout the day. I'm sure there's a reason (restarts?) but this means the actual costs calculated can only be accurate if Intelligent slots are maintained until the following day - any ad-hoc slots created during the day, if they aren't persisted until midnight in the Intelligent data will cause huge cost errors to be introduced. I don't know if this is a change in behaviour for IOG APIs - there's definitely a difference in how charge slots are displayed in the Octopus App now, so maybe it used to persist slots for long enough after the event for this recalculation to work. At 16:15, Predbat recalculated the 13:00 charge slot incorrectly - I added debug into the loop I listed above - here's the results for the 16:10 and 16:15 runs:
So, the data was correct, and then 3 hours later, it recalculated the slot cost and got it wrong, adding £3 because IOG no longer reported the old slot. |
Describe the bug
At various points during the day, the actual cost recorded by Predbat increases significantly. It has been doing this for ages, and I've been unable to figure out why - only just updated everything to full versions and got back to it, hence raising now.
Expected behaviour
At these times, there is no increase in the energy usage on any metric or recorded by Predbat - the actual cost reported just jumps up for no apparent reason. Debug doesn't show the calculation (that I can see) so I cannot tell what Predbat thinks is costing this large amount extra.
I'm on IOG, so rates do change throughout the day, but that's 26p peak and 7p off-peak, all that changes are some future slots become 7p, so I can't see it is related to that.
Predbat version
8.7.2
HAOS, HACS etc all updated to latest versions yesterday
Environment details
SolarEdge 8kW Inverter, 24 panels, Three 9.7kWh Solaredge batteries
Appdaemon install
Screenshots
Here you can see a plot of the Predbat values showing the actual reported cost above the readings from Smart Meter/Solar showing energy usage. When the Predbat costs line jumps vertically up, there is no increase in any of the consumption graphs.
Log file
Yesterday afternoon - change from £2.91 to £5.41 despite energy import remaining at 43.32kWh (and exporting!)
Today:
Change from £1.82 to £3.52 - again energy import value remains constant.
Since midnight, my Smart Meter (read directly using Hildebrand Glow) shows import of 17.09kWh at off-peak (£1.19) and 0.09kWh at peak (£0.02) with a standing charge of 62p so the actual cost is £1.83 so the original £1.82 reported at 09:00 was the correct figure showing actual electricity cost and I've absolutely no idea where the additional £1.70 came from?
I assume I'm missing something obvious or have something misconfigured somewhere but despite looking at this many times over the last few months it seems mostly random and I cannot figure out why the daily costs are so far out.
The text was updated successfully, but these errors were encountered: