Manual_api appears to have rate always defined as "0"

[Ashpork]

Describe the bug I'm on Tomato Intensity as a tarrif, which means when the CO2 levels nationally are less than 115, they apply a 15% discount to the tarrif in that time slot.

I've written a short template to evaluate and generate the manual_api command to adjust the rate for that timeslot by 15%. My output looks like the below

rates_import_override?date=2024-11-24&start=00:00:00&end=00:30:00&rate=20.924 rates_import_override?date=2024-11-24&start=01:00:00&end=01:30:00&rate=4.501 rates_import_override?date=2024-11-24&start=02:00:00&end=02:30:00&rate=4.501 rates_import_override?date=2024-11-24&start=03:00:00&end=03:30:00&rate=4.501 rates_import_override?date=2024-11-24&start=04:00:00&end=04:30:00&rate=4.501 rates_import_override?date=2024-11-24&start=05:00:00&end=05:30:00&rate=4.501 rates_import_override?date=2024-11-24&start=06:00:00&end=06:30:00&rate=20.924 rates_import_override?date=2024-11-24&start=07:00:00&end=07:30:00&rate=20.924 rates_import_override?date=2024-11-24&start=08:00:00&end=08:30:00&rate=20.924 rates_import_override?date=2024-11-24&start=09:00:00&end=09:30:00&rate=20.924 rates_import_override?date=2024-11-24&start=10:00:00&end=10:30:00&rate=12.631 rates_import_override?date=2024-11-24&start=11:00:00&end=11:30:00&rate=12.631

I'm firing each one of these at the select.predbat_manual_api entity in an attempt to override the price for those slots. However, I'm finding that each slot I'm adjusting, just changes the rate to '0' regardless of the value I provide.

Expected behaviour I was hoping for the manual_api, to enable me to adjust the import rate for a given time slot, outside of '0'

Predbat version v8.7.0

Environment details

Screenshots

Log file

app.yaml has the below defined:

rates_import:

• start: "22:30:00" end: "01:00:00" rate: 24.617
• start: "01:00:00" end: "06:00:00" rate: 5.2952
• start: "06:00:00" end: "09:30:00" rate: 24.617
• start: "09:30:00" end: "11:30:00" rate: 14.86
• start: "11:30:00" end: "20:30:00" rate: 24.617
• start: "20:30:00" end: "22:30:00" rate: 14.86

[Ashpork]

Done a bit more digging on this this morning.

whilst "rate" doesn't work as I was expecting, I did find "rate_increment" did work.

Some excerpts from the log:

The log from my action: 2024-11-23 08:39:00.300230: select_event: manual_api, select.predbat_manual_api = rates_import_override?date=2024-11-23&start=10:00:00&end=11:00:00&rate_increment=10.1,rates_import_override?date=2024-11-23&start=11:00:00&end=12:00:00&rate=10.1

The interpretation from predbat: 4327 2024-11-23 08:39:21.495825: Adding rate rates_import_override: {'index': None, 'date': '2024-11-23', 'start': '11:00:00', 'end': '12:00:00', 'rate': '10.1'} => 11-23 11:00:00 to 11-23 12:00:00 @ 0.0 date 2024-11-23 00:00:00 increment False 4326 2024-11-23 08:39:21.495742: Adding rate rates_import_override: {'index': None, 'date': '2024-11-23', 'start': '10:00:00', 'end': '11:00:00', 'rate_increment': '10.1'} => 11-23 10:00:00 to 11-23 11:00:00 @ 0.0 date 2024-11-23 00:00:00 increment True 4325 2024-11-23 08:39:21.495540: Basic rate API override items for rates_import_override are [{'index': None, 'date': '2024-11-23', 'start': '10:00:00', 'end': '11:00:00', 'rate_increment': '10.1'}, {'index': None, 'date': '2024-11-23', 'start': '11:00:00', 'end': '12:00:00', 'rate': '10.1'}]

Using rate_increment is fine for me, as I'm subtracting 15% rather than defining an adhoc special rate with no relation to the original.

[Ashpork]

rate_increment needs a little help too. It currently only accepts a whole number.

Basic rate API override items for rates_import_override are [{'index': None, 'date': '2024-11-23', 'start': '10:00:00', 'end': '11:00:00', 'rate_increment': '10'}, {'index': None, 'date': '2024-11-23', 'start': '11:00:00', 'end': '12:00:00', 'rate_increment': '10.9'}]

8788 2024-11-23 09:11:54.378536: Adding rate rates_import_override: {'index': None, 'date': '2024-11-23', 'start': '11:00:00', 'end': '12:00:00', 'rate_increment': '10.9'} => 11-23 11:00:00 to 11-23 12:00:00 @ 0.0 date 2024-11-23 00:00:00 increment True 8787 2024-11-23 09:11:54.378451: Adding rate rates_import_override: {'index': None, 'date': '2024-11-23', 'start': '10:00:00', 'end': '11:00:00', 'rate_increment': '10'} => 11-23 10:00:00 to 11-23 11:00:00 @ 10.0 date 2024-11-23 00:00:00 increment True 8786 2024-11-23 09:11:54.378261: Basic rate API override items for rates_import_override are [{'index': None, 'date': '2024-11-23', 'start': '10:00:00', 'end': '11:00:00', 'rate_increment': '10'}, {'index': None, 'date': '2024-11-23', 'start': '11:00:00', 'end': '12:00:00', 'rate_increment': '10.9'}]

Happy to check through anything further

[gcoan]

I've only ever used the manual API with rate=0 for Octopus power up and Free electricity events. You're probably the first person to test a non-zero rate!

[gcoan]

Thinking about it a bit further, there's a potential FR here @springfall2008 if rate_increment could take a + or - percentage amount as well as a + or - pence amount then this would directly meet the needs of @Ashpork on his Tomato tariff:

i.e.

rates_import_override?date=2024-11-23&start=10:00:00&end=16:00:00&rate_increment=-15.0%

[springfall2008]

Odd it worked for me:

rates_export_override?start=17:00:00&end=18:00:00&rate=5

[Ashpork]

Try with a decimal value?

rates_export_override?start=17:00:00&end=18:00:00&rate=5 rates_export_override?start=18:00:00&end=19:00:00&rate=5.1 rates_export_override?start=19:00:00&end=20:00:00&rate=-5 rates_export_override?start=20:00:00&end=21:00:00&rate=-5.1

[springfall2008]

Right that would make sense now,debugging....

[springfall2008]

Fix on 'main' for testing

[Ashpork]

Just installed Main, and it looks good to me. Thank you @springfall2008 .

I will try and package up my script into a blueprint and share. To help me do this, can you confirm if my understanding is correct, does the attribute "results" in entity "predbat.rates" always show the original rates, rather than any overridden rates? For example, the above image with the overrides, still shows the original values in predbat.rates "results" attribute. If so, that'll make this blueprint a little easier for configuration.

[Ashpork]

Just to follow on, in general this works. Although last night we had a short powercut, just after the cheap period started. On power restore everything booted up, apart from predbat which seemed to be unhappy with what was cached in my predbat_config.yaml and was stuck in a boot loop with a predbat.status "Error: Exception raised 'attributes'".

Frustratingly I've removed the content of the manual_api parameter in that file, but didn't keep a copy of it. Removing the contents of that file (with predbat addon not started) and then starting predbat up, it came back to life. But i did have some bad values whilst building out the script.

I'm wondering if predbat should try and use the contents of that file, and if it can't, then don't use the aatribute that's failing and continue. That said, perhaps I should probably get the contents correct in the first place!

The image below gives a hint as to how the value was incorrect, but that was hours before our power cut, and I'm sure I'd restarted predbat a couple times too since correcting that value.