Target Rate Sensor is incorrect

[SoHSolar]

Describe the bug

Target rates are not the correct price (minimum price is an hour later than it says, the prices are incorrect on the attributes of the sensor but are correct in the main integration). Also the sensor triggers at random times and not the correct times stated in the attributes.

Reproduction steps

Has been happening for a week or so

Expected behaviour

Expected to be at the right time and also trigger when expected and doesn't.

Tariff Code

E-1R-Agile-23-12-06-M

Integration Version

0314B700

Home Assistant Version

2024.4.4

Fresh Install?

Not specified

Home Assistant Logs

None but can get if needed.

Confirmation

• I confirm that I cannot find my solution within the documentation
• I confirm that I cannot find my solution within the FAQ

[BottlecapDave]

Hello sorry that you're having issues. Can you please provide some more information?

• The configuration of your target rate sensor
• The target rate times that it picked, based on the attributes of the sensor
• For the same period as the target rate times, a screenshot of the history view focusing the same time period as the selected target rate times/configuration (see screenshot for example where my target rate is set between 07:00 and 20:00, my target times are for 26th so my history is set to focus on 26th)

[SoHSolar]

This is the history for my 3h offset target sensor. It is programmed as below.

As you can see it triggered at a random time and then went off at a random time too. They are always whole 30 minute blocks. plus, the minimum block that it chose was an hour later then the actual minimum block when I checked on the octopus rates card (and also on my octopus app).

Sorry to be a pain but this makes the sensors almost not useable at this time. Please let me know if there's anything simple I can do to rectify this. All of my sensors are doing the same and triggering at random times (or sometimes they all trigger at the same time despite all having different block times!

[SoHSolar]

This sensor hasn't triggered yet and it should have triggered at 2:30pm. These all worked perfectly for the last 4 months. Not sure what's changed?

[SoHSolar]

Sorry to post multiple times but all of my target entities have failed to turn on and are also at the incorrect time, regardless of the times, offset or any other variable. Sorry!

[BottlecapDave]

A lot to unpack

First, I'm not too sure what version of the integration you're on. It looks like a git changeset instead of a release? If you're not, I would suggest updating to the latest stable release (v10.3.1).

As you can see it triggered at a random time and then went off at a random time too

This is hard to tell as the history view is before the target rate scheduled times. What was the offset 3h sensor doing between 27-04-2024 12:00 BST and 27-04-2024 22:00 BST. Based on attributes of the first image of the target rate sensor, the sensor picked times between 27-04-2024 13:00 BST and 27-04-2024 16:00 BST. With an offset of 3 hours, the sensor should come on between 27-04-2024 16:00 BST and 19:00 BST. However the next_time attribute is stating it should start coming on at 27-04-2024 19:00 BST which implies the offset is being applied twice. This was raised back in march and has since been fixed on the latest release.

the minimum block that it chose was an hour later then the actual minimum block when I checked on the octopus rates card (and also on my octopus app).

Please note the times reported in are in UTC/GMT, so while it states 27-04-2024 12:00 in the first image, this translates to 27-04-2024 13:00 local time. There is a beta release which translates the times to local time (HA only half does this in the frontend). The rates card shows the rates in local time (as does the octopus app).

This sensor hasn't triggered yet and it should have triggered at 2:30pm

Based on this sensor, it's picked times starting at 14:30 BST, however with an offset of 1 hour, the sensor should turn on at 15:30 BST. As per the docs, the offset is aimed to turn on the sensor before/after the discovered times, not to offset the target times. Again, the next time seems like it's applied the offset twice.

I think the first port of call is to make sure you're on the latest release, which can be confirmed by downloading the diagnostics of the integration

[SoHSolar]

Dear David,

Thank you for your reply! It appears that updating to the beta version has made it work again. Thank you for your help and thank you for making such an awesome integration!

[heisenberg2980]

EDIT: please ignore me, I just realised the reason is the start and end times are UTC while I am in UTC+1 timezone.

@BottlecapDave having a similar issue, where the integration is not picking up the correct price. For example today at 10:30 to 11:00 the integration is returning 0.1323 while octopus shows 0.1575

Do you think this will be fixed in the next release? how can I try the beta version?

[BottlecapDave]

The next release will display all timestamps in local time. Instructions on the beta release can be found at #857

[BottlecapDave]

Closing as it looks like this was fixed in the beta release, which has now been released as part of v11.0.0.