IOG constantly changing cheap slots and messing up my target sensors - how to handle this?

[ragg987]

I'm on IOG and in the last few weeks Octopus have become increasingly "aggressive" in the way the allocate and continuously re-allocate cheap slots. I would appreciate any input on how I can handle this situation.

Example, tonight they offered a cheap slot at 22:00 to 22:30. I saw it on the Octopus app up until around 22:00 and then they pulled it and turned that into an expensive slot.

My target sensor for heating (heat-pump) is set with the option "Existing target rates haven't started or finished". As I understand it this option will re-evaluate the slot in the minute prior to planned start to make sure it is still the optimal slot, however in tonight's example I believe the change from Octopus came too late. So my heat-pump started in the (now) expensive period at 22:00 and the target sensor did not re-evaluate as the target period had started.

Would appreciate any tips into how I can improve the robustness of this so that the target sensor and hence the heat-pump do not react until the slot is confirmed by Octopus.

I had thought that bringing in the Dispatch sensor might help, however if I look at the sensor history it looks like the sensor also got fooled by this last minute switch from Octopus.

Another option I thought of was to see if my Zappi has been set to boosting by Octopus, but in this instance I notice that the sensor was stuck on boosting for some 24hrs so that would not have helped either. I think it got stuck on boosting as my EV was full at that point, however Octopus did not cancel the unused boost.

[ragg987]

I should add that my Libbi automation also kicked in and started to boost charge from grid, however it turned off as soon as the Dispatch sensor turned off. This automation does not depend on a target sensor, just on the dispatch sensor. In any case I had 4 minutes of boost at the high rate and would also like to avoid this from occuring.

[BottlecapDave]

This is unfortunately the consequence of OE only providing polling for this data, and would probably have been an issue if you configured everything manually based on the schedule you originally had. Maybe this is there way to stop people using the cheap data for anything but your car.

If you know when your car is plugged in etc with your Libby sensor, you could take advantage of the manual polling service - https://bottlecapdave.github.io/HomeAssistant-OctopusEnergy/services/#octopus_energyrefresh_intelligent_dispatches. With this method, you could call the service just before your target sensor comes on to force a refresh which should then be re-evaluated.

You could also set an offset on the target sensor so it turns on a couple of minutes after the period starts where the dispatching sensor should have updated, and so you can then check the dispatching sensor as well. You'd need to check the end time of the sensor as well as the target sensor to determine when it should turn off, as the offset shifts the entire time period not just the start time.

[ragg987]

Thanks for that @BottlecapDave . It looks like I would have to control intelligent refreshes completely with this method so something I need to get comfortable with.

With this method, you could call the service just before your target sensor comes on to force a refresh which should then be re-evaluated.

How do I do that? At present my automation is triggered by the state of target sensor, I'm unsure how I can trigger the service just before the target sensor comes on? I guess an option would be a time-based trigger based on the attributes of the target sensor - "next_time:" maybe?

[BottlecapDave]

Yeah you would use the next time attribute or index into the first item of the target times array. This could be a template trigger or you could move the time to a helper or template sensor.

[ragg987]

Thanks - something for me to try over the next few days. Also I'll continue to monitor OE's cheap slot changes - maybe what I saw was a one-off.

My worry with going down this rabbit hole is that OE continue to evolve the way they allocate slots so I could end up piling workarounds on top of workarounds over time. If this is is a <5% scenario I might just live with it...

[ragg987]

Just as an update, I tried a simpler method to check if the cheap slot really exists (thanks for the suggestion @BottlecapDave ).

Using 2 triggers, one based on off-peak sensor and the other on the dispatching sensor but with a 5 minute delay. The 5 minute delay should allow the Octopus integration (3 minute refresh as default) to update the dispatching sensor in case the switch was made last minute.

  - trigger: state
    entity_id:
      - >-
        binary_sensor.octopus_energy_electricity_XXX_XXX_off_peak
    from: "off"
    to: "on"
    id: "on"
  - trigger: state
    entity_id:
      - binary_sensor.octopus_energy_a_XXX_intelligent_dispatching
    from: "off"
    to: "on"
    id: "on"
    for:
      hours: 0
      minutes: 5
      seconds: 0

Then a condition for the action that performs an AND against the trigger id and the dispatching sensor. i.e. no need to honour the 5-minute delay if it is in the off-peak period.

actions:
  - if:
      - condition: state
        entity_id: sensor.octopus_tariff_type
        state: octopus_intelligent
    then:
      - choose:
          - conditions:
              - condition: and
                conditions:
                  - condition: trigger
                    id:
                      - "on"
                  - condition: state
                    entity_id: >-
                      binary_sensor.octopus_energy_a_XXX_intelligent_dispatching
                    state: "on"

So far so good...

[nickwaring]

hi @ragg987

I'm looking to implement similar and, as a HA newbie, want to check how to setup:

• Are the trigger and action code part of a single automation configuration?
• I'm stuggling to decipher the action performed (it looks like the action conditions are a logic check rather than action) - can you confirm is an entity/sensor gets updated as a result of the action?

Apologies for the basic questions!

[ragg987]

Hi @nickwaring just to try to address your queries.

Yes they are part of the same automation - I did not add the code for the action in the second snippet, I only showed that I performed an additional check : if triggered "on" and off_peak sensor is on then run the action straight away - i.e. I do not need the 5 minute delay which is there in case Octopus change the planned slot, which is monitored via the dispatch sensor. My premise here is that the dispatch sensor is always at risk, however if the off_peak sensor is on then the dispatch can be ignored.

The action would be a switch action against entity switch.myenergi_libbi_charge_from_grid.

I don't know if this helps - I'm no coder so I would not use my example as good practice - I'm sure someone with better skills could make it simpler and more robust, however it works for me.

[nickwaring]

thanks @ragg987 - really appreciate you taking the time to reply. I'll have a go and post results later :-)