Fix for crash when tariff code cant be found & consumption key is not found in tariff #7
Conversation
|
@Altirix - many thanks for raising this. I've had a look at the tariff and it does indeed seem like a strange edge case. The tariff is not listed in the product endpoint: But it the pricing is there if you construct the URLs manually:
The second error is probably related to the first as the logic should use the appropriate tariff for the time of the consumption. If the missing tariff data is filled in, I'm hoping you won't get a key error. Could you try manually specifying the missing URLs, e.g. add this to the beginning of if tariff_code == 'E-FLAT2R-VAR-22-11-01-H':
return [
{
'rel': 'standing_charges',
'href': 'https://api.octopus.energy/v1/products/VAR-22-11-01/electricity-tariffs/E-FLAT2R-VAR-22-11-01-H/standing-charges/',
},
{
'rel': 'day_unit_rates',
'href': 'https://api.octopus.energy/v1/products/VAR-22-11-01/electricity-tariffs/E-FLAT2R-VAR-22-11-01-H/day-unit-rates/',
},
{
'rel': 'night_unit_rates',
'href': 'https://api.octopus.energy/v1/products/VAR-22-11-01/electricity-tariffs/E-FLAT2R-VAR-22-11-01-H/night-unit-rates/',
},
]If this works, we can find a neater way of adding special cases rather than silently skipping missing data. |
|
The KeyError might have another cause, originally i had only tested with my account. Recently I also tried to set up my parents account and theirs only gets the KeyError crash. Originally I assumed these must have been the same problem, but now it seems they might be subtly different. The manual link patch you provided seems to work as expected and does not crash when applied to Going to look into why my parents place produces the KeyError Here's the crash for my parents place, at the time i didn't look over it too closely, but |
|
I think i get what is happening, both agreements started after the requested backdating date. which was
so it seems the KeyError can be caused if the user tries to backdate to a date that is outside of the oldest agreement, and i only stumbled into it originally as by skipping our old tariff we were outside of the remaining agreement's start date. |
|
Hi @Altirix, thank you for retesting. For your parent's account could you try using the config If you still experience an error, I'd like to reproduce it. Could you send me either their API key + account number, or you could enable cache (see config options) and send me the resulting directory contents. This way you can obfuscate their address in the account response (and the account number as well if you prefer, which will also be in the filename). |
|
OK, got you. Yes, please don't try and backfill from a date before when the account was active. Perhaps we can add validation for that. Does that mean the only real issue is your special |
yes, the real issue is just the FLAT2R tariff missing from their endpoint, the issue with attempting to backdate before the agreement starts is mentioned in the readme if That should also allow As for the product itself, I'm going to send Octopus an email and see what they say, id have to assume its an error on their end that the tariff isn't part of the product endpoint. Or maybe this endpoint only lists current products, and can't be relied upon to get the pricing links? |
The curl -vs "https://api.octopus.energy/v1/products/VAR-22-11-01/?tariffs_active_at=2022-11-01T00:00:00Z"Otherwise, yes, please email them and let me know what response you get. |
|
just realised i missed the email, Response from octopus: will check if the old product still causes issues when im back home |
|
Hi @Altirix, did you receive any further response from Octopus? |
The first edge case only occurs if you are on a tariff that cannot be found.
the tariff we were on previously was E-FLAT2R-VAR-22-11-01-H which is never found by
_find_linksresulting in this crashIn this case, I believe we should just skip over the iteration when this occurs. ideally, there would be a way to get the correct tariff data but i dont see any way to do that.
The second edge case occurs when you have consumption data from before the start of the current tariff. the time won't be part of either
standard_unit_ratesorstanding_chargesso both should be checked before accessing.I wasn't sure if it would be preferred to do this as an
if key in dictortry: except keyerror:within this PR I've done it as the former, but happy to change to the latter if preferred.