Hi All, Dwell time was defined as below in DSP2046_2019.3.pdf
For discrete triggers - The amount of time that a trigger event persists before the metric action is performed For NumericThresholds - The duration the sensor value must violate the threshold before the threshold is activated
In case of discrete triggers, assume if changes happen after 100 second and within a second Metric action will be performed, Dwell time will be 100 or 1 second. If we depend on Metric action time, it will be always few seconds
In case of NumericThresholds , assume if sensor value changes after a day and within a second Metric action will be performed, Dwell time will be 1 day or 1 second
Please explain about the Dwell time attribute and real use case to understand better
Mani, The notion of Dwell Time is the amount of time and situation needs to exists before the situation is deemed to have occurred. Dwell Times are used to avoid 'false' triggers because of jitter (en.wikipedia.org/wiki/Jitter) from sensors or indicators.
In your case of discrete triggers, the start of the dwell time is when the change occurs (after 100s). If the change is sustained for the duration of the dwell time value (e.g. 1s), then the 'change' will be considered to have occurred and the metric action(s) performed. If the change is not sustained for 1s, then the 'change' is not considered to have occurred.
John, It would be better to clarify in the spec or schema, since if days are allowed in pattern, user can try to use that. Another option could be set time limit(like set maximum value as 60 minutes or 3600 seconds or some time limit)
We should have a limit eventhough days allowed, since Most transients are short-lived I'm unable to understand detect global warming using triggers, currently we are monitoring sensor based on their configurable values Can you explain about this detect global warming use case?
George was just joking about the global warming use case; it's not a real scenario for Redfish
The reality is while it's possible to specify a DwellTime in the order of days per the "duration" definition, it's probably not realistic, but, someone might come up with a scenario where they do want to specify days. If your DwellTime can be modified by a client, I think it would be reasonable to apply some sort of upper bound and return a 400 Bad Request to the client stating the request is out of range. This is similar to other properties in the data model today where clients could try to set limits that are not reasonable and the service will reject the request.