Closed psfshr closed 1 month ago
Hello. This is by design as the sensors are built to compare the costs of your current tariff with the costs of another tariff. If you've changed the default offset, then my guess this is due to the data being available later than the standard one day. If the comparison didn't take the offset into consideration then there's a chance the sensors would never update due to the data not being available in time. It also uses the same consumption data as the previous consumption sensors to calculate the cost to reduce data retrieved from the APIs. I'll update the docs to make this clearer.
So, let me re-explain. As I understand it, the point of the offset is to pull additional data in the situation where it's not updated properly on the OE side (for example), so you can pull more than one day to then get the missing data on the next day.
The issue I see is that with the offset set to more than one day, the comparison rate entity only has data for that many days in the past, it doesn't have the days "in-between". Plus, if I set the offset back to 1 day then I am properly seeing data from the previous day (it is updating from OE as expected).
For example... In my settings I have my normal account details, and a tariff comparison I've called "agile" (as I'm comparing my current tariff to Agile).
This gives me two entities: event.octopus_energy_electricity_23l3520058_2700001750370_previous_day_rates and sensor.octopus_energy_electricity_23l3520058_2700001750370_previous_consumption_rates_agile
If I set the offset for electricity to 1 day (default) and I look at the entities this evening (10/07) on both of them I'll see rate data for yesterday (09/07)
If I set the offset for electricity to 3 days (for example) and I look at the entities this evening (10/07) then on the "current" tariff I'll see rates for yesterday (09/07), but on the "agile" tariff I'll only see rates for 3 days ago (07/07) and nothing for the intermediate 2 days.
As both are previous rates, I would have expected to both return data for the same day(s), whether that's fixed to the previous day, all days back to (today - offset) or the single day defined by the offset.
As I understand it, the point of the offset is to pull additional data in the situation where it's not updated properly on the OE side (for example), so you can pull more than one day to then get the missing data on the next day.
By default the previous consumption/cost sensors look at the previous days worth of data as this is the latest data available via the APIs. However for some people, the data can take longer than 24 hours to populate, which means that it misses the cut off time for the sensor to update, which means the sensor gets "stuck". The offset is to move how many days behind the previous consumption/cost sensors look, but still only look at a 24 hour period.
The issue I see is that with the offset set to more than one day, the comparison rate entity only has data for that many days in the past, it doesn't have the days "in-between". Plus, if I set the offset back to 1 day then I am properly seeing data from the previous day (it is updating from OE as expected).
As mentioned, this is by design. The comparison sensors compare the cost of the previous consumption data against a different tariff. This is so you have as close to a like-to-like comparison and can plot the data on graphs etc so you know when you're on a worse tariff.
This gives me two entities: event.octopus_energy_electricity_23l3520058_2700001750370_previous_day_rates and sensor.octopus_energy_electricity_23l3520058_2700001750370_previous_consumption_rates_agile
The two sensors that are more comparable are
sensor.octopus_energy_electricity_xxx_yyy_previous_consumption_rates_agile
and
event.octopus_energy_electricity_xxx_yyy_previous_consumption_rates
(Note the sensor prefix is an error as this should be in the event
domain, as it's an event entity)
The event.octopus_energy_electricity_23l3520058_2700001750370_previous_day_rates
sensor is data that drives the previous_rate
sensor as this data is required when crossing over midnight otherwise it turns unknown for a period of time.
Describe the bug
A Tariff Comparison sensor appears to return rates based on the set previous consumption offset value (e.g. 3 days) rather than the previous day. The normal previous consumption rates still report correctly.
Reproduction steps
Set a previous consumption offset of 1 day, restart HA, and check the entity for the comparison previous consumption rates, it returns rates for the previous day. Set a previous consumption offset of 3 days, restart HA, and check the entity for the comparison previous consumption rates, it returns rates for 3 days ago rather than the previous day.
Expected behaviour
Should return rates for the previous day irrespective of the offset value, the same as the standard previous consumption rates.
Tariff Code
E-1R-AGILE-24-04-03-H (comparison tariff)
Integration Version
11.2.1
Home Assistant Version
2024.7.1
Fresh Install?
After upgrading
Home Assistant Logs
{ "home_assistant": { "installation_type": "Home Assistant OS", "version": "2024.7.1", "dev": false, "hassio": true, "virtualenv": false, "python_version": "3.12.4", "docker": true, "arch": "aarch64", "timezone": "Europe/London", "os_name": "Linux", "os_version": "6.6.33-haos", "supervisor": "2024.06.2", "host_os": "Home Assistant OS 12.4", "docker_version": "26.1.4", "chassis": "embedded", "run_as_root": true }, "custom_components": { "meross_lan": { "documentation": "https://github.com/krahabb/meross_lan", "version": "5.3.0", "requirements": [] }, "alarmo": { "documentation": "https://github.com/nielsfaber/alarmo", "version": "v1.10.4", "requirements": [] }, "cololight": { "documentation": "https://github.com/BazaJayGee66/homeassistant_cololight", "version": "v2.0.7", "requirements": [ "pycololight==2.1.0" ] }, "pod_point": { "documentation": "https://github.com/mattrayner/pod-point-home-assistant-component", "version": "2.0.3", "requirements": [ "podpointclient==1.6.1", "StrEnum>=0.4,<0.5", "aiodiscover", "scapy" ] }, "hacs": { "documentation": "https://hacs.xyz/docs/configuration/start", "version": "1.34.0", "requirements": [ "aiogithubapi>=22.10.1" ] }, "octopus_energy": { "documentation": "https://bottlecapdave.github.io/HomeAssistant-OctopusEnergy", "version": "11.2.1", "requirements": [] } }, "integration_manifest": { "domain": "octopus_energy", "name": "Octopus Energy", "codeowners": [ "bottlecapdave" ], "config_flow": true, "dependencies": [ "repairs", "recorder" ], "documentation": "https://bottlecapdave.github.io/HomeAssistant-OctopusEnergy", "homekit": {}, "iot_class": "cloud_polling", "issue_tracker": "https://github.com/BottlecapDave/HomeAssistant-OctopusEnergy/issues", "ssdp": [], "version": "11.2.1", "zeroconf": [], "is_built_in": false }, "setup_times": { "null": { "setup": 0.015091819921508431 }, "1b697877a582840fecee1cdb8161619b": { "config_entry_setup": 0.014970776857808232 }, "86f42e82eb82fce6c398388622e9b5e2": { "wait_import_platforms": -17.659649336943403, "wait_base_component": -0.0031083140056580305, "config_entry_setup": 18.891941021895036 } }, "data": { "id": "A-8772418B", "octoplus_enrolled": true, "electricity_meter_points": [ { "mpan": "REDACTED", "meters": [ { "active_from": { "__type": "<class 'datetime.date'>", "isoformat": "2024-02-05" }, "active_to": null, "serial_number": "REDACTED", "is_export": false, "is_smart_meter": true, "device_id": "REDACTED", "manufacturer": "1063 - Landis and Gyr", "model": "00050204", "firmware": "38040602" } ], "agreements": [ { "start": "2024-01-20T00:00:00+00:00", "end": null, "tariff_code": "E-1R-VAR-22-11-01-H", "product_code": "VAR-22-11-01" } ] } ], "gas_meter_points": [ { "mprn": "REDACTED", "meters": [ { "active_from": { "__type": "<class 'datetime.date'>", "isoformat": "2024-02-05" }, "active_to": null, "serial_number": "REDACTED", "consumption_units": "m\u00b3", "is_smart_meter": true, "device_id": "REDACTED", "manufacturer": "1063 - Landis and Gyr", "model": "47720101", "firmware": "03035524" } ], "agreements": [ { "start": "2024-01-20T00:00:00+00:00", "end": null, "tariff_code": "G-1R-VAR-22-11-01-H", "product_code": "VAR-22-11-01" } ] } ] } }
Confirmation