Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

next_time is miscalculated, offset seems doubled #169

Closed
mateuszdrab opened this issue Mar 12, 2023 · 8 comments
Closed

next_time is miscalculated, offset seems doubled #169

mateuszdrab opened this issue Mar 12, 2023 · 8 comments
Assignees
Labels
bug Something isn't working

Comments

@mateuszdrab
Copy link

mateuszdrab commented Mar 12, 2023

Describe the bug

I have created a sensor with offset: '-3:00:00', the first target time starts at 2023-03-13T03:00:00+00:00 but the calculated next_time is 2023-03-12T21:00:00+00:00.
Also reproduced it with offset -01:00:00 where the next time was 2 hours instead of 1 hour early compared to the first target_rate time.
Without offset, next_time is correctly at 3:00.

Expected behavior

I expected the next_time to be 2023-03-13T00:00:00+00:00

Home Assistant Version

2023.3.3

Integration Version

v6.0.1

Fresh Install?

Fresh

Home Assistant Logs

Full sensor data:

Name: night_laundry
Hours: 5
Type: Continuous
rolling_target: false
Start time: '0:00'
End time: '9:00'
offset: '-3:00:00'
is_target_export: false
target_times:
  - value_inc_vat: 5.628
    valid_from: '2023-03-13T03:00:00+00:00'
    valid_to: '2023-03-13T03:30:00+00:00'
    tariff_code: E-1R-AGILE-FLEX-BB-23-02-08-H
  - value_inc_vat: 1.0185
    valid_from: '2023-03-13T03:30:00+00:00'
    valid_to: '2023-03-13T04:00:00+00:00'
    tariff_code: E-1R-AGILE-FLEX-BB-23-02-08-H
  - value_inc_vat: 5.0715
    valid_from: '2023-03-13T04:00:00+00:00'
    valid_to: '2023-03-13T04:30:00+00:00'
    tariff_code: E-1R-AGILE-FLEX-BB-23-02-08-H
  - value_inc_vat: 3.6855
    valid_from: '2023-03-13T04:30:00+00:00'
    valid_to: '2023-03-13T05:00:00+00:00'
    tariff_code: E-1R-AGILE-FLEX-BB-23-02-08-H
  - value_inc_vat: 4.431
    valid_from: '2023-03-13T05:00:00+00:00'
    valid_to: '2023-03-13T05:30:00+00:00'
    tariff_code: E-1R-AGILE-FLEX-BB-23-02-08-H
  - value_inc_vat: 16.5375
    valid_from: '2023-03-13T05:30:00+00:00'
    valid_to: '2023-03-13T06:00:00+00:00'
    tariff_code: E-1R-AGILE-FLEX-BB-23-02-08-H
  - value_inc_vat: 13.4505
    valid_from: '2023-03-13T06:00:00+00:00'
    valid_to: '2023-03-13T06:30:00+00:00'
    tariff_code: E-1R-AGILE-FLEX-BB-23-02-08-H
  - value_inc_vat: 26.901
    valid_from: '2023-03-13T06:30:00+00:00'
    valid_to: '2023-03-13T07:00:00+00:00'
    tariff_code: E-1R-AGILE-FLEX-BB-23-02-08-H
  - value_inc_vat: 19.5825
    valid_from: '2023-03-13T07:00:00+00:00'
    valid_to: '2023-03-13T07:30:00+00:00'
    tariff_code: E-1R-AGILE-FLEX-BB-23-02-08-H
  - value_inc_vat: 25.242
    valid_from: '2023-03-13T07:30:00+00:00'
    valid_to: '2023-03-13T08:00:00+00:00'
    tariff_code: E-1R-AGILE-FLEX-BB-23-02-08-H
next_time: '2023-03-12T21:00:00+00:00'
current_duration_in_hours: 0
next_duration_in_hours: 5
icon: mdi:camera-timer
friendly_name: Octopus Energy Target night_laundry

I'd like to know if this is a bug or am I doing something wrong?

@mateuszdrab mateuszdrab added the bug Something isn't working label Mar 12, 2023
@mateuszdrab mateuszdrab changed the title Offset calculated time is 2x what is requested Calculated next_time is 2x of offset Mar 12, 2023
@mateuszdrab mateuszdrab changed the title Calculated next_time is 2x of offset next_time is miscalculated, offset seems doubled Mar 12, 2023
@BottlecapDave
Copy link
Owner

Hi there :)

This all looks as expected based on your configuration. The target sensors will never guarantee the same start/end times from day to day, especially if you're on an agile tariff. The start and end periods define the period of time that you want your target hours to be found within, where in your case it will find a 5 hour block of time with the cheapest combined price. This time period also determines when a daily block of time starts/ends to ensure the sensor doesn't come on multiple times within a 24 hour period.

The offset determines an offset to this best period for when the sensor should come on, which could be at an expensive time. This is designed to be used in automations with equipment where you want to perform a job (e.g. a robot vacuum using energy in it's battery) before you want it to charge during the cheap period.

It appears from the sensor that for 13/03 the best time started at 03:00 and so with your offset it turned on at 00:00. For the next time period it appears the best time started at 00:00 and so with your offset it will turn on at 21:00.

Assuming based on the name of the sensor, you probably want your start at 21:00 and your end at 09:00 with your offset set to 00:00:00. This will mean that the sensor (and your washing machine) will turn on each night between the hours of 21:00 and 04:00` (09:00 minus your desired 5 hours) where the 5 hour block from the start is the cheapest combined cost.

This is all much better explained in the readme and accompanying examples.

@mateuszdrab
Copy link
Author

mateuszdrab commented Mar 13, 2023

Hey @BottlecapDave

Thanks for the detailed explanation.

As mentioned, I configured my start-end times between 0:00-9:00. The integration found a 5 hour block between 3:00-7:30 (best period). The reason I configured a -3h offset is because I don't have a smart washing machine, so I wanted the sensor to turn on 3h early to trigger a notification for me to set the washing machine up with a 3h delay timer before bed.

The problem is that the next_time changed from 3:00 to 21:00 (6h early) after configuring the offset (whilst the calculated best time window remained the same based on target_times).

What is next_time? There is no mention of it in the documentation
Is next_time not a result of start time of the best time (3am) - offset (-3) = 0 (midnight) calculation? I don't understand where 9pm comes from.

For the next time period it appears the best time started at 00:00 and so with your offset it will turn on at 21:00.
Regarding the above - there was only one calculated 5h slot available that night.

Essentially, I understood that the sensor should be on between 3:00-7:30 with offset 0. With offset as -3h, the sensor should turn on at midnight which should be equal to the next_time calculation?

Any set time restrictions will include the offset.

I'm also not understanding the above sentence, does that mean configuring the offset will also change my desired start and end time? Making the 0:00-9:00 window a 21:00-6:00 window? This would explain why next_time is 21:00.

Thanks

@BottlecapDave
Copy link
Owner

next_time is when the sensor will next turn on and so this should be as you mentioned start_time of the discovered period minus offset. However looking at the code, I see your issue and it does look like I'm indeed applying the offset twice :( Sorry about the miscommunication. I'll try and fix the issue within the next week.

@mateuszdrab
Copy link
Author

No worries :)

I'm glad I helped you discover the bug.

When you get round to fixing it, could you perhaps elaborate better on the offset feature?
What I mean is talking more about how and what it affects, mentioning that the sensor will turn on and off at the times calculated after applying the offset. If I understand, that is the case, right?

@BottlecapDave
Copy link
Owner

This should be resolved in the latest release https://github.com/BottlecapDave/HomeAssistant-OctopusEnergy/releases/tag/v6.1.1.

I've also updated https://github.com/BottlecapDave/HomeAssistant-OctopusEnergy#offset which should elaborate more.

@mateuszdrab
Copy link
Author

mateuszdrab commented Mar 18, 2023

Thanks, I think you meant 6.2.0.

I'll test it out once installed though I think I'll keep it without offset as I've developed an automation which displays the actual best window and calculates an offset window for my small display.

@BottlecapDave
Copy link
Owner

It was originally in 6.1.1, then I found another small issue which would have had an effect.

I would also be interested in what your automation does differently when you say "actual best window" (out of curiosity)

@mateuszdrab
Copy link
Author

Thanks, I think you meant 6.2.0.

I'll test it out once installed though I think I'll keep it without offset as I've developed an automation which displays the actual best window and calculates an offset window and displays it on my small display.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants