|
|
Post by AMI_Mani on Dec 13, 2019 17:40:48 GMT
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
Thanks,
Mani
|
|
|
|
Post by jleung on Jan 14, 2020 0:21:10 GMT
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.
Regards,
John
|
|
|
|
Post by AMI_Mani on Jan 20, 2020 11:43:10 GMT
John,
Thanks for explaining with details. As per schema Dwelltime format needs to support days also
pattern: "-?P(\d+D)?(T(\d+H)?(\d+M)?(\d+(.\d+)?S)?)?",
Do we need to allow dwelltime as days which can delay metric action(s) to be performed after days only
Thanks,
Mani
|
|
|
|
Post by jleung on Jan 28, 2020 20:14:13 GMT
Most transients are short-lived. I wouldn't think transients over days would be probable.
Do you want that clarified in the spec or schema?
|
|
|
|
Post by AMI_Mani on Feb 3, 2020 8:35:06 GMT
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)
Thanks,
Mani
|
|
|
|
Post by gericson on Feb 3, 2020 16:11:19 GMT
I know that in our context, days seem really long. But... consider if you are trying to detect global warming... :-)
|
|
|
|
Post by AMI_Mani on May 17, 2020 17:21:21 GMT
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?
Thanks,
Mani
|
|
|
|
Post by mraineri on May 20, 2020 13:38:49 GMT
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. |
|
