You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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
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
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
The text was updated successfully, but these errors were encountered: