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

[Enhancement]: Add an interval to start back from for state agg functions so that the initial time buckets have initial conditions known #814

Open
DDetlefsen opened this issue Oct 10, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@DDetlefsen
Copy link

What type of enhancement is this?

API improvement

What subsystems and features will be improved?

Continuous aggregate

What does the enhancement do?

The concept of duration_in provides the amount of time a parameter is in a certain state within a time bucket. However, if the parameter last recently changed BEFORE a the first time bucket, then the first time bucket cannot be aware of the value of that parameter until another change.

The suggestion here is to provide an optional parameter for the duration_in and interpolated_duration_in functions that tell the function how far back to go and try and capture the initial state of the FIRST time bucket.

Here is an example.
Lets say you desire the time a machine is on for the hour of 12:00 to 1:00
The states of the device can be "off", "idle", "running", "fault"

Lets say the status changes as such:
11:30 -> "off"
12:25 -> "running"
1:17 -> "idle"

For the currently implementation of durtion_in for the hour of 12:00 to 1:00 you would see
off 0:00 <- HERE WE ARE MISSING 25 minutes of "off" time
idle 0:00
running: 0:35
fault: 0:00

This does not add up to 60 minutes. This is because the initial value of "off" at the starting point (12:00) in unknown all the way until 12:25.

Proposed change:
if we can set a "go back {{interval}} for the first time bucket", then I could say duration_in (state_agg, "off", '1 hour') which would look back 1 hour for the inital time bucket, use the last() function to figure out the initial starting state and then we would result in

off 0:25 <- HERE WE KNOW THE INITIAL STATE
idle 0:00
running: 0:35
fault: 0:00

which add up to 60 minutes perfectly

Implementation challenges

No response

@DDetlefsen DDetlefsen added the enhancement New feature or request label Oct 10, 2024
@DDetlefsen
Copy link
Author

If you do not set your backup time far enough, and your signal has not changed in that window, then you will STILL not know the initial state of your first time bucket. I guess you have to just guess you are going back far enough or live with that.

@DDetlefsen DDetlefsen changed the title [Enhancement]: Add an interval to start back from for duration_in and interprolated_duration_in [Enhancement]: Add an interval to start back from for state agg functions so that the initial time buckets have initial conditions known Oct 10, 2024
@jonatas jonatas transferred this issue from timescale/timescaledb Oct 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant