Closed slopemad closed 9 months ago
Looks like the entity changed as part of the octopus integration change to event in version 9.0. But that doesn't work either
octopus_saving_session: 're:(binary_sensor.octopus_energy([0-9a-z_]+|)_octoplus_saving_session(s|))'
Ah shit I’ll fix it this evening
Yup, I changed mine to octopus_saving_session: 're:(event.octopus_energy([0-9a-z_]+|)_octoplus_saving_session_events)'
and all was good, showing the event on the rates chart and in the log.
I changed my octopus_saving_session config a @tim-mawson suggested and it works now. Hopefully it'll refine the plan closer to the session, as it's initial thoughts are to not even bother discharging in the first half hour and therefore not pre-charge ahead of it... (Quite possibly because it's expecting a hefty household load (what with it being teatime and all that) and thus not calculating much profit to be made, but the reality is the Heat Pump, and the kitchen appliances will not be on, and the kids will be encouraged to sit in the dark, or maybe even go to their friends' for tea!).
https://github.com/springfall2008/batpred/releases/tag/v7.13.17 includes a fix, keep in mind you should put back the original line in apps.yaml with this update
Looking better :-)
seems to be all good for me but notice that the import rates jump for the saver period, assume this is known
also the 4.30pm slot has some export which I am assuming is minimal but surprised me it came on before the saver session starts
seems to be all good for me but notice that the import rates jump for the saver period, assume this is known
The SS payments are based on net reduction, so any import is effectively costing £4.15/kWh more.
seems to be all good for me but notice that the import rates jump for the saver period, assume this is known
The SS payments are based on net reduction, so any import is effectively costing £4.15/kWh more.
Ah, very good point, thanks for the clarity
I'm still having a problem - the session is recognised, but doesn't impact the plan?
2023-11-28 20:20:04.263610 INFO pred_bat: Joined Octopus saving session: 2023-11-16T17:30:00+00:00 - 2023-11-16T18:30:00+00:00 at assumed rate 400.0 state False 2023-11-28 20:20:04.275719 INFO pred_bat: Joined Octopus saving session: 2023-11-29T17:00:00+00:00 - 2023-11-29T18:30:00+00:00 at assumed rate 400.0 state False
Do you have any rate overrides in apps.yaml? Seems a little odd.
I'm still having a problem - the session is recognised, but doesn't impact the plan?
Did you join the session? If the saving session line in apps.yaml uncommented?
Hi yes, the session has been recognised - as captured in the logs..
"2023-11-28 20:20:04.263610 INFO pred_bat: Joined Octopus saving session: 2023-11-16T17:30:00+00:00 - 2023-11-16T18:30:00+00:00 at assumed rate 400.0 state False 2023-11-28 20:20:04.275719 INFO pred_bat: Joined Octopus saving session: 2023-11-29T17:00:00+00:00 - 2023-11-29T18:30:00+00:00 at assumed rate 400.0 state False"
This is the line from apps.yaml:
octopus_saving_session: "re:(binary_sensor.octopusenergy([0-9a-z]+|)_saving_session(s|))"
Full apps.yaml attached.. apps.yaml.zip
Log file.. appdaemon.log.zip
Do you have any rate overrides in apps.yaml? Seems a little odd.
Hi Trefor, no - I've enclosed the apps.yaml in the above comment.
Sorry I don't get why it's being ignored, for now maybe use the override method and I'll take a look tomorrow?
Thanks Trefor, what’s the override method :)
same issue for me, the saving session is recognised by predbat but it then doesn't seem to include it in the plan
https://github.com/springfall2008/batpred/issues/211#issuecomment-1830845347
@SheriffOfNotts add an import and export rate override to apps.yaml like this:
rates_import_override:
- date: "2023-11-29"
start: "17:00:00"
end: "18:30:00"
rate: 400.0
rates_export_override:
- date: "2023-11-29"
start: "17:00:00"
end: "18:30:00"
rate: 400.0
I had my octopus_saving_sessions pointing to the binary sensor (as per the docs). Just changed it to point to the saving session event as suggested by @tim-mawson above https://github.com/springfall2008/batpred/issues/383#issuecomment-1830457205 and no change; the saving sessions are identified in the logfile but the plan doesn't show them
same issue for me, the saving session is recognised by predbat but it then doesn't seem to include it in the plan
@SheriffOfNotts add an import and export rate override to apps.yaml like this:
rates_import_override: - date: "2023-11-29" start: "17:00:00" end: "18:30:00" rate: 400.0 rates_export_override: - date: "2023-11-29" start: "17:00:00" end: "18:30:00" rate: 400.0
Thank you :)
I've just seen this in the logs - is this correct?
2023-11-28 22:35:54.449512 INFO pred_bat: Setting Octopus saving session in range 11-29 17:00:00 - 11-29 18:30:00 export False assumed rate 400.0
sounds like yours is now being auto detected. I don't have that message
I've "fixed" it. Deleted Predbat folder rebooted and reinstalled. Then kept the new apps.yaml file and manually edited my config into it.
I think this looks correct now?
yes that looks correct I can try reinstalling predbat as well but seems strange to need to for this when everything else works
Same here - only took 2 mins though. Wish I'd done it a couple of hours ago :( Looking at the apps.yaml it seems that there were quite a few changes, I may have missed copying something across..
Hope you get it sorted..
Thanks @SheriffOfNotts I have no idea why that should be the case, but uninstalling predbat, restarting HA and all the add-on's, editing apps.yaml to put back the edits required to get it to work with my (non standard GivTCP & solcast entities and my own calculated house load), and it all bloody well works
2023-11-28 23:10:01.790782 INFO pred_bat: Setting Octopus saving session in range 11-29 17:00:00 - 11-29 18:30:00 export False assumed rate 400.0
2023-11-28 23:10:02.254247 INFO pred_bat: Rate min forward looking: now 16.2225 at end of forecast 16.2225
2023-11-28 23:10:02.265471 INFO pred_bat: Import rates min 16.22 max 460.29 average 42.73
2023-11-28 23:10:02.283409 INFO pred_bat: Setting Octopus saving session in range 11-29 17:00:00 - 11-29 18:30:00 export True assumed rate 400.0
2023-11-28 23:10:02.288994 INFO pred_bat: Export rates min 5.76 max 428.1 average 29.43
it works in that the saving session rates are now recognised. Unfortunately predbat doesn't save the battery for the peak session or charge it up beforehand, and reinstalling hasn't fixed that, but that's a different issue #357 #367
Excellent :) Glad you made progress
it works in that the saving session rates are now recognised. Unfortunately predbat doesn't save the battery for the peak session or charge it up beforehand, and reinstalling hasn't fixed that, but that's a different issue #357 #367
Are you on the latest Predbat? Is your low rate threshold at 0 (automatic)?
it works in that the saving session rates are now recognised. Unfortunately predbat doesn't save the battery for the peak session or charge it up beforehand, and reinstalling hasn't fixed that, but that's a different issue #357 #367
Are you on the latest Predbat? Is your low rate threshold at 0 (automatic)?
I'm on v7.13.17 at the moment, latest as at last night. Yes low rate threshold is zero. I'll post the screenshots of the not charging correctly ahead of the peak rates on the other issue as it's not really a saving session issue, it occurs for all peak rates
@springfall2008 thank you for this functionality, it worked perfectly.
I could just be being impatient here, but... I have opted into tomorrow's savings session, it is reflected in the Octopus Energy app (since 17.30), I've even changed the assumed rate to 400, and this is in apps.yaml
octopus_saving_session: 're:(binary_sensor.octopus_energy([0-9a-z_]+|)_saving_session(s|))'
but Predbat doesn't appear to be picking it up? It worked well on the last one a couple of weeks ago...