Octopus/GivTCP failure

[PianSom]

This morning there was what is considered to be an API fail by Octopus. Those of us on Intelligent Octopus Go and Flux (though, it appears, not Agile) woke to very strange Predbat plans. Looking at the history of the givTCP import rate sensor, it appears that the api updated the rate every 5 mins until 5.30am, then not again until the problem was corrected (presumably by Octopus) at approx 10.30am

The effect of this was that predbat.rates stayed at the 5.30am level of 7.5p for us IOG users, potentially causing us to import at 30p cost for a period of 5 hours.

Discussion - is there a better failed api behaviour that can be suggested? Does Predbat only note changes when the GivTCP import rate cost changes (rather than becoming "Unknown")? What behaviour could have been better in this morning's scenario?

[SwiftRR]

I'm not sure which sensor you have shown.
This is my closest match (for Agile). As you can see there is no time period where nothing happened.

Rob

[gcoan]

For predictable tariffs like IOG then presumably could set the rates up in apps.yaml. Q how predbat would handle this, would it fallback to the apps.yaml config and just miss out on any extra IOG sessions (if there were any)?

I had solcast go wrong on me before now, spotted it by there being no solar charging during the day. Fixed it by reloading the integration but would be good if we had more automations to spot these things?

[PianSom]

Good timing. As you know there was a major Solcast outage yesterday.

It seems to me that good behaviour might include
1 - notify (with some kind of Urgent flag) that a critical input has failed
2 - pause any discretionary power events (iboost, car charge etc)
3 - allow for manual override of all inputs (like exists for import rates)
4 - fail safe - if a critical input becomes missing then leave the battery in Eco mode or similar

This all may be easier said than done …

[SwiftRR]

I didn’t experience (or see) the solcast glitch, although I have seen the comments from others.

From your 4 suggestions, 1. Notify and 4. Eco ……
Could a notification be picked up by an automation, similar to Geoffrey's Givtcp activity monitor?

Rob

[gcoan]

I saw the solcast issue yesterday, despite my previously working random times for the solcast update automation, it failed every time after 1am yesterday. The several random runs I did of the automation also failed, and it's now working OK again from this morning.
In the case of solcast it's not such a critical issue as solcast forecasts several days ahead and if the site /API is not working you at least still have the original forecast that can be used.
Maybe we could check for stale Ness in some way?

[radiatorsimon]

Looking at apps.yaml, you could just set a backup energy rates source so if there is an outage or gap in data there is something for PredBat to fall back on.

" # Energy rates

Please set one of these three, if multiple are set then Octopus is used first, second rates_import/rates_export and latest basic metric"