Intelligent dispatching turning on for bump charges

[BottlecapDave]

In my testing, the sources within the completed dispatches have always come back as null. I perform some light data transformation with the data that is returned by OE, but all I do is squash it down.

Presumably caused of the lack of ‘sources’ in the completed dispatches, the sensor that indicates dispatching is ‘on’ triggers for both bump-charge and smart-charge… the difference being ‘bump-charge’ is the users choice and (outside of the cheap window) is expensive, where as a smart-charge is Octopus’ choice and is therefore cheap rate regardless of the time.

At the moment the dispatches sensor updates to On (and downstream Predbat considers this to mean rates are cheap and may charge the PV inverter battery I believe).

Also diagnostically its a pain because - as an example, my car randomly started charging earlier today in peak rate - and I can see some completed dispatches in the sensor - but I cant tell if that means I got stung or I got an intelligent slot retrospectively.

I dont know if there is anything you can do to include this in the completed and active dispatches to distinguish? It sounds like the data probably isn’t there :-(

Happy to provide my key and trigger a bump charge so that you can see what is coming down from the API.

Originally posted by @adamwylde in https://github.com/BottlecapDave/HomeAssistant-OctopusEnergy/issues/373#issuecomment-1716445314

[springfall2008]

I've changed Predbat to pick up bump-charge, so it now knows the car will charge but its not a special low rate slot.

For the sensor itself, maybe the user might want a choice depending on the automation. E.g. if you use the slot to enable your car charger then you might want to include bump charge. If you use it for low rate trigger then you might want it too. Maybe add both?

[adamwylde]

(re posting as I used my work account by accident)

Thanks both.

I noticed that the bump charges dont even appear in the completed dispatches they just vanish - I suppose this is because aside of them triggering the car to charge they are valueless.... and in terms of triggering the car its supposed to be Octopus doing that (its kinda the point of Intelligent) so I'm not sure what you would ever do with the bump charge notification? Mind you, I suppose predbat would want to stop inverter battery discharge so that the battery didnt get drained by the car charging...

[treforsouthwell-sifive]

(re posting as I used my work account by accident)

Thanks both.

I noticed that the bump charges dont even appear in the completed dispatches they just vanish - I suppose this is because aside of them triggering the car to charge they are valueless.... and in terms of triggering the car its supposed to be Octopus doing that (its kinda the point of Intelligent) so I'm not sure what you would ever do with the bump charge notification? Mind you, I suppose predbat would want to stop inverter battery discharge so that the battery didnt get drained by the car charging...

Yes, Predbat wants to know to predict your battery levels and maybe stop it draining totally.

I use IO but my Wallbox charger is blocked by default and so I use a slot sensor to enable the charger. In fact I use Predbat slot nowadays but not everyone will be.

[adamwylde]

Interesting - I'm still trying to understand IO and Octopus controlling my EV - it seems rather random and unreliable! Maybe I'll control my Zappi via the sensor to avoid what seems like random charging events being initiated by IO.

[springfall2008]

Part of the reason I leave my Wallbox locked is to stop it charging outside the IO slots

[BottlecapDave]

For the sensor itself, maybe the user might want a choice depending on the automation. E.g. if you use the slot to enable your car charger then you might want to include bump charge. If you use it for low rate trigger then you might want it too. Maybe add both?

I try and avoid configurable behaviour as that is prone to a complicated integration and can be confusing for users. Because of how the UI works in HA and the flow of tariffs, this configuration would need to be exposed as an entity or included in the config flow which is already getting quite big. I think whatever I choose to do (include bump charges or not), it will be wrong to someone :p

I'm going to include not including bump charges as that's the behaviour people expect when coming from the HA intelligent integration (which was one of the main driving forces of the addition). If they want to include bump charges, they can always include the additional sensor in their automations or create a template sensor which includes it.

[springfall2008]

I think as long as you list all the slots with the sources in the details then Predbat is fine.

I’d be inclined to have a separate low rate slot sensor and keep the IO slot as Is.

[github-actions[bot]]

This issue has become stale because it has been open for 30 days with no activity. If you still think it's an issue, please respond soon.

[github-actions[bot]]

This issue has been closed because it has been inactive for 14 days since being marked as stale. This is done to help keep on top of active issues. If you still think it's an issue, please respond to this issue