Open gcoan opened 3 days ago
dbw1966
commented
3 days ago Powerups are already taken care of in Predbat with negative prices in the plan. I believe the "free for everything over your normal usage" periods are not flagged in the octopus api, so can you comment where you are getting them from?
gcoan
commented
3 days ago Powerups are already taken care of in Predbat with negative prices in the plan. I believe the "free for everything over your normal usage" periods are not flagged in the octopus api, so can you comment where you are getting them from?
No, the problem is that powerups are NOT automatically taken care of in Predbat, I think you might be thinking of Agile plunge pricing when the published agile rate goes negative.
Powerups are where the electricity is zero price for a set period no matter how much you use and so is slightly different from the "free for everything over your normal usage".
Neither of these price rate overrides are made available to Predbat via the Octopus API's or BottlecapDave's Octopus Integration. The only way to get predbat to plan for these events are to put a manual price rate override in apps.yaml so I'm seeking a mechanism to do this more easily than having to manually edit the file each time.
I'm getting the date and times of these activities via https://github.com/8none1/octopus_powerups which gets them into HA. With the appdaemon add-on I could then write these directly to apps.yaml, but for the predbat addon it runs in its own protected space and HA doesn't have access to write to the predbat addon apps.yaml
springfall2008
commented
3 days ago What about having a power up selector like the force charge one that sets the zero rate?
gcoan
commented
3 days ago Yes that could work as well and would be reasonably easy to "drive" from a triggering automation to repeatedly select, pause, select, etc the time periods.
Only potential limitation is the time window length on those drop-down selectors, I think 16, 18 hours? Would need to be a bit longer, maybe not the whole weekend (for a Friday notification) but would want to have the ability to set 24-30 hours ahead
mpartington
commented
2 days ago Sounds a good idea to add an override for zero rates. I can also see a benefit for setting more in advance, my only concern would be the amount of scrolling (on a phone screen).for say 30 hrs (that's 60.slots to pick through). I think the current list of times is long enough to navigate. However power ups and free energy is likely to be less frequent, so maybe there is a compromise/different solution for that
I tend to also additionally set the other override options (for other reasons) using the select:select service from external automations..Not sure if duplicate times e.g. two 01:00:00 in a list would break this
springfall2008
commented
2 days ago The reason the list is shorter is not only the size of the list but also to avoid having to include the day in the list, it just auto-clears when the time wraps. I could however accept a day when its used as a service it won't matter its not on the list in this case.
mpartington
commented
2 days ago I generally use the select.select service to ensure something predictable happens everyday. For example, set my afternoon cheap slots to always charge - in case I put.a random high load on in the period. Adding a day requirement I guess would make this more complicated to automate
gcoan
commented
2 days ago If it's possible for there to be a shorter dropdown list for use via the UI and the ability to optionally pass date (or day) in when select is called via an API call (for longer term setup's) then this seems the best of both worlds
Is your feature request related to a problem? Please describe. Predbat has the ability to do price over-rides by entering the date, start time, end time and load multiplier in apps.yaml.
With Octopus Power up events and Free electricity events, these happen often and I want a simple way to be able to inform Predbat of these without having to manually edit apps.yaml each time.
Describe alternatives you've considered I have a solution for this that works perfectly with predbat running in appdaemon, but I've just discovered that it doesn't (and probably can never) work with the predbat add-on.
My (appdaemon) solution is as follows:
This works perfectly with predbat running in appdaemon as it can write to my /config/appdaemon/apps/batpred/apps/apps.yaml file
However when I modify the script to write to /addon_configs/6adb4f0d_predbat/apps.yaml it fails as the shell command runs in the homeassistant container context and it doesn't have access to /addon_configs folder tree.
I can't identify any way round this as homeassistant can't directly access the add-on file system structure. Hence this FR
Describe the solution you'd like A mechanism from within Predbat that I can invoke to instruct it to take in an import price over-ride - would need to be able to pass the start date, time, end time and load multiplier. A service API if possible would be great, or some sort of configuration in apps.yaml to point to the external over-ride data.
e.g. in apps.yaml, something like this: user_rates_import_override:
Can define these helper entities in HA, configure apps.yaml to point to them, and then have a 'trigger' toggle in predbat that reads from these helper entities and writes the override to apps.yaml.
The reason I suggest writing the override to apps.yaml and not just using these helpers directly is we are on occasion getting multiple events, e.g. this weekend there was a powerup event and a free electricity event on Saturday and then another powerup event on Sunday. The ability to queue and instruct predbat of these one by one rather than having to wait for one to finish before the next can be instructed would be useful PI A clear and concise description of what you want to happen.