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

Is start_with_last broken? #340

Closed
swiergot opened this issue May 18, 2022 · 17 comments
Closed

Is start_with_last broken? #340

swiergot opened this issue May 18, 2022 · 17 comments
Labels
bug Something isn't working Stale

Comments

@swiergot
Copy link

swiergot commented May 18, 2022

This is not working as expected:

   -  entity: sensor.daily_yield
      offset: -7d
      statistics:
        type: state
        period: hour
        align: start
      group_by:
        func: diff
        start_with_last: true

It just shows zeros throughout the entire graphspan.

I have debugged the code and the reason is the third IF statement here:

      if (this._config.group_by.start_with_last) {
        if (index > 0) {
          if (bucket.data.length === 0 || bucket.data[0][0] !== bucket.timestamp) {
            const prevBucketData = buckets[index - 1].data;
            bucket.data.unshift([bucket.timestamp, prevBucketData[prevBucketData.length - 1][1]]);
          }

Basically, when retrieving hourly long term statistics, there is only one datapoint in each bucket and the datapoint's timestamp is always equal to the bucket's timestamp.

So the question is: why are the timestamps expected to be different?

@swiergot swiergot added the bug Something isn't working label May 18, 2022
@RomRider
Copy link
Owner

So the question is: why are the timestamps expected to be different?

Because diff is supposed to work with the last and the first entry of a bucket and I didn't test that feature with the statistics.
I can make an exception for the statistics, but I won't change the behavior for historical data as it doesn't make sense to me.
The timestamp is expected to be different because if there is a value (for historical data) on the timestamp of the bucket it means that it's the first value of the bucket and nothing else can be "first" in that bucket.

@swiergot
Copy link
Author

Thanks for your reply.

The timestamp is expected to be different because if there is a value (for historical data) on the timestamp of the bucket it means that it's the first value of the bucket and nothing else can be "first" in that bucket.

Isn't that in contradiction with the very purpose of start_with_last? I mean, even if there cannot be any earlier value in the bucket, start_with_last actually adds a value from the previous bucket (as the documentation states). I think that's the behaviour one would always expect when using start_with_last, regardless of whether originally the first value was on the bucket's timestamp or not.

@swiergot
Copy link
Author

To illustrate my point, suppose we have a sensor that yields a new, increasing value every 10 minutes (and resets at midnight).

11:40:01 0
11:50:01 0
12:00:01 1
12:10:01 2
12:20:01 3
12:30:01 4
12:40:01 5
12:50:01 6
13:00:01 7
13:10:01 8
13:20:01 9
13:30:01 10
13:40:01 10
13:50:01 10

With start_with_last set to true, the diff function will show 6 for hour 12 and 4 for hour 13.

But now suppose the sensor updates 1 second earlier (at full minutes):

11:40:00 0
11:50:00 0
12:00:00 1
12:10:00 2
12:20:00 3
12:30:00 4
12:40:00 5
12:50:00 6
13:00:00 7
13:10:00 8
13:20:00 9
13:30:00 10
13:40:00 10
13:50:00 10

Due to timestamp checking, start_with_last will have no effect here - the diff function will show 5 (6-1) for hour 12 and 3 (10-7) for hour 13.

I would expect that the sum of hourly diffs will be equal to the daily gain (which is 10 in our example). It's true in the first example, but not in the second one, just because the sensor is just 1 second faster. It seems not justified to me.

@RomRider
Copy link
Owner

I see your point, thanks. I'll update the behavior!

@github-actions
Copy link

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days.

@swiergot
Copy link
Author

swiergot commented Jul 3, 2022

Hi, I have created a PR for you.

@github-actions github-actions bot removed the Stale label Jul 4, 2022
@github-actions
Copy link

github-actions bot commented Aug 3, 2022

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days.

@github-actions github-actions bot added the Stale label Aug 3, 2022
@github-actions
Copy link

This issue was closed because it has been stalled for 10 days with no activity.

@RomRider RomRider reopened this Nov 4, 2022
@github-actions github-actions bot removed the Stale label Nov 4, 2022
@github-actions
Copy link

github-actions bot commented Dec 5, 2022

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days.

@github-actions github-actions bot added the Stale label Dec 5, 2022
@github-actions
Copy link

This issue was closed because it has been stalled for 10 days with no activity.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Dec 15, 2022
Ranzdo pushed a commit to Ranzdo/apexcharts-card that referenced this issue Jan 13, 2023
@RomRider RomRider reopened this Aug 13, 2023
@RomRider RomRider removed the Stale label Aug 13, 2023
@github-actions
Copy link

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days.

@github-actions github-actions bot added the Stale label Oct 13, 2023
@swiergot
Copy link
Author

Still unclosed.

@github-actions github-actions bot removed the Stale label Oct 15, 2023
Copy link

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days.

@github-actions github-actions bot added the Stale label Dec 14, 2023
@swiergot
Copy link
Author

Still unclosed.

@github-actions github-actions bot removed the Stale label Dec 15, 2023
Copy link

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 10 days.

@github-actions github-actions bot added the Stale label Feb 14, 2024
Copy link

This issue was closed because it has been stalled for 10 days with no activity.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Feb 25, 2024
@swiergot
Copy link
Author

Reopen please.

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

No branches or pull requests

2 participants