Skip to main content
Solved

Dynamically identifying shifts in data

  • August 27, 2026
  • 4 replies
  • 53 views

What is the best way to dynamically identify data shifts like this in Trendminer?  Control chart calculations would be ideal, but I don’t think that’s possible.

 

Best answer by fvandael

Hi ​@rwchartrand ,

You're right that TrendMiner has no control-chart object, and the aggregation tag builder has no standard-deviation operator either. The available operators are Average, Minimum, Maximum, Range, Delta and Integral, on a rolling window between your index resolution and a maximum of 24h (Tag Builder: Aggregation). So true ±3σ limits aren't reachable without Python. For a step shift, though, you don't need σ. You can build the shift itself as a tag and monitor it.

Two options, both no-code:

Delta aggregation. Create an aggregation tag on your measurement with operator Delta, direction backwards, and Aggregate per set to roughly the timescale over which the shift happens. The tag returns the difference between the start and end value of that window, so a step shows up as a spike.

Fast-vs-slow mean. Create two Average aggregation tags, for example 15m and 8h, then a formula tag:

fast - slow

A sustained non-zero value means the mean has moved away from its own recent history. Formula tags accept up to 10 mapped variables (Tag Builder: Formula), so you can normalise or scale further if needed.

Then run a value based search on that tag (> x / < -x), save it, and enable it as a monitor. Monitors re-run the saved search against live indexed data every 2 minutes and execute the configured actions on each new result (Monitoring and alert overview), so you can send yourself an email when a data drift happens or create an automatic context item.

Kind regards

Frederik Vandael

4 replies

Forum|alt.badge.img
  • Employee
  • Answer
  • September 1, 2026

Hi ​@rwchartrand ,

You're right that TrendMiner has no control-chart object, and the aggregation tag builder has no standard-deviation operator either. The available operators are Average, Minimum, Maximum, Range, Delta and Integral, on a rolling window between your index resolution and a maximum of 24h (Tag Builder: Aggregation). So true ±3σ limits aren't reachable without Python. For a step shift, though, you don't need σ. You can build the shift itself as a tag and monitor it.

Two options, both no-code:

Delta aggregation. Create an aggregation tag on your measurement with operator Delta, direction backwards, and Aggregate per set to roughly the timescale over which the shift happens. The tag returns the difference between the start and end value of that window, so a step shows up as a spike.

Fast-vs-slow mean. Create two Average aggregation tags, for example 15m and 8h, then a formula tag:

fast - slow

A sustained non-zero value means the mean has moved away from its own recent history. Formula tags accept up to 10 mapped variables (Tag Builder: Formula), so you can normalise or scale further if needed.

Then run a value based search on that tag (> x / < -x), save it, and enable it as a monitor. Monitors re-run the saved search against live indexed data every 2 minutes and execute the configured actions on each new result (Monitoring and alert overview), so you can send yourself an email when a data drift happens or create an automatic context item.

Kind regards

Frederik Vandael


  • Author
  • Navigator
  • September 9, 2026

Thanks for the response.  I like the fast vs. slow mean option.  My pump speed is idle a lot of the time, so I created a formula that excludes data if it is below x.  I tried doing the 8 hour and 30 min averages based on that variable.  The 30 min average works ok, but the 8 hour average will not calculate.  I assume it’s because of the excluded data.  How do you suggest I get around that?


  • Author
  • Navigator
  • September 14, 2026

Thanks for the response.  I like the fast vs. slow mean option.  My pump speed is idle a lot of the time, so I created a formula that excludes data if it is below x.  I tried doing the 8 hour and 30 min averages based on that variable.  The 30 min average works ok, but the 8 hour average will not calculate.  I assume it’s because of the excluded data.  How do you suggest I get around that?

I figured out this was just because my time range was set to less than 24 hrs.  


Jef Vanlaer
Community Manager
Forum|alt.badge.img
  • Community Manager
  • September 16, 2026

Hi ​@rwchartrand 

It looks like we missed your followup question from 6 days ago. Sorry for that, but I’m glad you were able to figure it out. Feel free to reach out again if you happen to have other questions.

Kind regards,
Jef