Intelligent slot mismatch

[thestumonkey]

Sometimes it seems that binary_sensor.octopus_energy_{{ACCOUNT_ID}}_intelligent_dispatching turns on, but it's not tracked in the dispatch slots nor offpeak.
I don't know yet if this is a bug, or a random free energy slot that octopus occasionally throw in if there's plenty of renewables going.
Anyone else seen this? I will have to wait until my bill arrives to see which it is

[BottlecapDave]

The dispatching sensor should only turn off if off peak of a pending dispatch slot is active. There are times however that pending dispatch slots do not turn into completed dispatches. This is sometimes an omission in the API depending on the integration provider, but can also be the result of your car not being on charge during said slot (a requirement to get the cheaper rate outside of the off peak times).

As mentioned in the docs, you should use other measurements if possible to ensure you're in an actual cheap slot to reduce the risk.

[thestumonkey]

Yeah u saw the docs, but it is incorrect that you will only get cheap rate if your car is charging, so I don’t want to use that signal. I have examples where it’s on and there’s nothing in planned dispatches, so as mentioned, there’s either a bug somewhere, or theres a type of octopus cheap slot that the integration integration does t deal with. I know that when wind power is high, sometimes octopus throw out a cheap slot, but as it’s not planned, it likely doesn’t make it onto planned dispatches, and therefore won’t be on completed dispatches. I guess I can maybe make a sensor to write to mqtt to monitor this, as the completed dispatches don’t persist over reset?

…

On Sat, 23 Nov 2024 at 09:25, David Kendall ***@***.***> wrote: The dispatching sensor should only turn off if off peak of a pending dispatch slot is active. There are times however that pending dispatch slots do not turn into completed dispatches. This is sometimes an omission in the API depending on the integration provider, but can also be the result of your car not being on charge during said slot (a requirement to get the cheaper rate outside of the off peak times). As mentioned in the docs <https://bottlecapdave.github.io/HomeAssistant-OctopusEnergy/entities/intelligent/#is-dispatching>, you should use other measurements if possible to ensure you're in an actual cheap slot to reduce the risk. — Reply to this email directly, view it on GitHub <#1087 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADKNITBIXLAFYOBMDOG4Q32CBC2DAVCNFSM6AAAAABSFLRLSOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMZVGYYTOMA> . You are receiving this because you authored the thread.Message ID: <BottlecapDave/HomeAssistant-OctopusEnergy/repo-discussions/1087/comments/11356170 @github.com>

[BottlecapDave]

it is incorrect that you will only get cheap rate
if your car is charging, so I don’t want to use that signal.

If you get a pending dispatch outside of your off peak times, it will only be charged at an off peak rate if your car is charging. This is what I've been told by other users as well as other places which is why this sensor has this warning.

I guess I can maybe make a sensor to write to mqtt to monitor this, as the
completed dispatches don’t persist over reset

The sensor just reports back what the API reports. It doesn't keep track of an indefinite schedule. I believe the completed dispatches is only for a couple of days max.

I have examples where it’s on and there’s nothing in planned dispatches, so
as mentioned, there’s either a bug somewhere, or theres a type of octopus
cheap slot that the integration integration does t deal with.

The sensor should only turn on when you're in a off peak period or during a planned dispatch window in a smart charge state (e.g. if a planned dispatch is for something like 10:20, then the dispatching sensor will be on until the end of that 30 minute period - 10:30 as this is when you'll be charged to).

If there's an issue, please raise an issue (or comment on an existing one if one exists) where I'll need to see the sensor on and the attributes of the sensor showing the pending/completed dispatches without the current time period. This is a difficult issue to recreate with the OE data constantly changing

[BottlecapDave]

If you're comfortable with running SQL queries, you can run the following via the SQL add-on to see what the attributes were at the time of the dispatching sensor turning on/off (changing the start/end dates to match the times for your examples where the sensor didn't work correctly.

SELECT  "states_meta".entity_id, "states".state,  "state_attributes".shared_attrs, DATETIME("states".last_updated_ts, 'unixepoch') AS last_updated
FROM "states_meta"
JOIN "states" ON "states".metadata_id = "states_meta".metadata_id
JOIN "state_attributes" ON "state_attributes".attributes_id = "states".attributes_id 
WHERE "states_meta".entity_id LIKE '%intelligent_dispatching%'
AND DATETIME("states".last_updated_ts, 'unixepoch') >= '2024-11-20 00:00:00Z'
AND DATETIME("states".last_updated_ts, 'unixepoch') <= '2024-11-20 10:00:00Z'

It would also be good to upvote https://community.home-assistant.io/t/simple-way-to-view-the-history-of-sensor-attributes/553324 to make this process easier