springfall2008
Saving Sessions Export Price Incorrect
Describe the bug When an Octopus saving session is opted-into, PredBat is applying the export rate increase every plan recomputation (until it hits some limit, then resets).
Here, the export rate should be 56p + 15p export = 71p, but seeing 127p after 2 plans, 183p after 3 plans.
It doesn't seem to be changing the rest of the plan around the shown figure (aside from the total).
Expected behaviour For the correct export rate to be shown.
Predbat version
8.11.4
Environment details
- Inverter and battery setup GivGateway + 2x AIOs + 2x Solax String Inverters
- Standard HAOS installer or Docker HAOS in Hyper-V
- Anything else?
Screenshots Attached
Log file Attached
Predbat debug yaml file Attached
Files starting with 2- are taken from when the first screenshot above was displaying, 3-: the second.
that's super-weird, never seen anything like that. before and my own predbat doesn't experience such behaviour. Did it keep on incrementing indefinitely ?
Did it keep on incrementing indefinitely ?
No, it reset at some point (highest I saw was almost 400p/slot which would've been nice!), but then carried on incrementing from 15p again.
Only adding in rate override in the apps.yaml file stopped it.
well weird. Hopefully Trefor can spot something in the logfile because I've never heard of anyone else having this happen to them
What is in the octopus slot sensor attributes? I'm wondering if the saving session was there twice?
Right now, not a lot...
I'll have a look next time there's a saving session scheduled (unless you can look at attributes historically?).
there isn't an easy way to look at attributes historically even though they are stored in the HA database. Would need to start writing direct SQL queries to find the data and even then I don't know how it is formatted
Struggling to reproduce this, I will try to mock up the saving session data soon (I can see it in the Debug yaml but the source of the calculation isn't stored).
In the meantime I did a new release as the Octopus export URL being used creates a huge structure in memory which is likely the cause of some crashes.
So I've managed to reproduce this issue!
It appears to be related to settings; a fixed rate in app.yaml. Changing from the fixed rate to the Octopus integration solved this for me.
What did you put in apps.yaml to reproduce it?
I've been having the same issue for the last few seasions and I had my rates set as
rates_import: - start: "23:30:00" end: "05:30:00" rate: 7 - start: "05:30:00" end: "23:30:00" rate: 25.03
Hoo ever i commented it out and used the following for the Octopus integration
metric_octopus_import: "re:(sensor.(octopus_energy_|)electricity_[0-9a-z]+_[0-9a-z]+_current_rate)"
Resolved the issue for me
Mine has been fine since I switched to the octopus integration sensor for export (after the large data bug!).
For the session later today, switching between the following lines in apps.yaml resolves or reproduces the issue for me:
metric_octopus_export: "sensor.octopus_energy_electricity_XXXX_YYYY_export_current_rate" (works)
rates_export_octopus_url: "https://api.octopus.energy/v1/products/OUTGOING-FIX-12M-BB-23-02-09/electricity-tariffs/E-1R-OUTGOING-FIX-12M-BB-23-02-09-A/standard-unit-rates/" (broken)
Hmmm... I'm seeing the same issue when I use rates_export_octopus_url (and rates_import_octopus_url)
Saving session rates super high!
And if I comment out the url lines from apps.yaml:
I only see the event once in the attributes:
