Monday morning tip, Davis monitor status value

[henk_stobbe]

Hello,

As long as you can only use higher or lower in Davis anomaly detection, this could be a workaround.

testing on status 4:

timeseries myseries = avg(xxx.device.status),by: {`dt.entity.xxx:xxx`} ,interval:1m | filter (arrayLast(myseries) == 4)

The anomaly detection should be like <100 (or more)

Who can confirm?

KR Henk

[t_pawlak]

Hi Henk,
IMO, this can work only partially, but I would not treat it as a clean or fully reliable workaround.

timeseries myseries = avg(xxx.device.status), by: {`dt.entity.xxx:xxx`}, interval:1m
| filter (arrayLast(myseries) == 4)

filters in only the timeseries whose latest sample is 4, but the anomaly detector still evaluates the returned 1-minute samples in the series, not just that single last value. So with a threshold like < 100, you would effectively mark all returned points as violating, which means the alert logic is no longer really “status equals 4”, but rather “this series passed the filter and its samples are below 100”. That can be misleading. 

A better approach is to transform the status into a dedicated numeric signal, for example:

• 100 when status = 4
• 0 otherwise

and then alert on above 50 or similar. That way the anomaly detector evaluates an explicit signal instead of relying on record filtering

[henk_stobbe]

Thanks for your replay, simulation at my end  looks perfect. myseries is already a 1m avg?

Am I missing something?

KR Henk

[t_pawlak · Accepted solution]

yes, in your query myseries is already a 1-minute averaged time series, because avg(...) with interval:1m creates one average value per 1-minute bucket.
So filter(arrayLast(myseries) == -1) checks whether the latest 1-minute bucket is -1, and if yes, the series remains in the result.
So from that perspective, your simulation result makes sense.
The only caveat is that alert behavior still depends on the anomaly detector window/dealerting/missing-data logic, because Davis evaluates the returned 1-minute series format