BottlecapDave
commented
3 months ago Hello. Sorry that you've encountered this. This was an issue with loading the configuration around the minimum/maximum rates and should be fixed in v12.2.1.
as per https://github.com/BottlecapDave/HomeAssistant-OctopusEnergy/discussions/957 I don’t see there is any value in storing the account id, mpan or tariff code for the found price slots in the target rate sensors. All of these should be pretty explicit by the context you created it. Possibly you need to retain the mpan or at least some form of representation of whether its import or export that the target rate sensor applies to, but otherwise, no point in keeping the others, especially repeating the tariff code.
The attributes on the target rate sensor are useful for debugging (both for end users and for myself when bugs are raised), so I don't see any of these going away. As outlined in the linked issue, they may be removed from being saved to the database to reduce storage, but want to gain feedback from people before I do this. I suspect no one is using the data in this context, but want to make sure first.
think the documentation needs to be clearer about the units of maximum and minimum thresholds for the target rate sensor. I assumed they were pence, so hence put 13, but when I see the output that the average/min/max cost are in pounds, then maybe the min and max need to be in pounds as well (i.e. 0.13)? Not clear in the documentation
I've updated the docs and added further clarification to the config screens.
I found that there’s a limitation of the target rate sensor is that it has to be in half hour increments, e.g. 1.5 hours. I first configured it as 1.33 hours as the washing machine runs for 1:20, and so the most optimum time could be 10 minutes in to a half hour slot, so using 20 minutes of that slot and 2 full further slots. Its not a major limitation to enforce the half hour configurability (but would be nice if it wasn’t a limit), but suggest this needs to be made explicit
This is by design as all rates are in 30 minute increments, so made no sense to go any lower. I also originally didn't know how the sensor is being used (before weightings existed), so in that I would be making an abitary decision on which block the fraction of slot would be assigned to (the 20 minutes might be most power hungry time or the least power hungry time). There are no plans to change this behaviour.
The error message is quite clear on the format if a user picks an invalid configuration, however I've updated the docs and screens with this limitation as well.
gcoan
Describe the bug
Created a new target rate sensor last night, which works as correctly:
But when I went to make changes to the configuration, I get an ‘expected str’ error.
Cancel the changes, go back in to configure the target rate sensor, press confirm (no changes), and same thing happens
Reproduction steps
Configure a target rate sensor. I had 1.5 hours from 16:00 to 16:00, max price 13. Let the sensor populate.
Try to reconfigure the sensor, press commit get the error.
NB: Not sure the trigger cause of this error because when I first set the target rate sensor up I had set min price 13 but the sensor didn’t populate any expected times. Changed it to max price 13 and it then populated times as expected. Only now when I try to reconfigure it I can’t.
Expected behaviour
Able to reconfigure target rate sensors at any time.
Additional comments/observations:
Tariff Code
E-1R-AGILE-23-12-06-A
Integration Version
12.2.0
Home Assistant Version
2024.8.1
Fresh Install?
Not specified
Home Assistant Logs
Debug log for Octopus integration whilst triggering the error although I don’t know if this shows anything, looks like regular polling:
Confirmation