Summary
Notification Delivery Plugin Does Not Receive the Triggering Data Point Value
Problem
The plugin_deliver entry point in notification delivery plugins currently receives a triggerReason JSON document containing only the reason, asset, and timestamp:
{
"reason": "triggered",
"asset": ["sinusoid"],
"timestamp": "2020-11-18 11:52:33.960530+00:00"
}
The triggerReason does not contain the actual data point name or value that caused the notification to trigger.
For example, if a notification is configured to trigger when the sinusoid value exceeds a threshold, the delivery plugin can determine that the notification was triggered and which asset was involved, but it cannot determine the actual value that caused the trigger.
This prevents notification delivery plugins such as python35,mqtt, and other delivery plugins from including the triggering data point value in the outgoing notification message.
Expected Behavior
The triggerReason should optionally include the data point name and value that caused the notification to trigger.
For example:
{
"reason": "triggered",
"asset": ["sinusoid"],
"datapoint": "sinusoid",
"value": 87.3,
"timestamp": "2020-11-18 11:52:33.960530+00:00"
}
Alternatively, the data point information could be provided through an additional parameter to plugin_deliver.
The implementation should preserve backward compatibility so that existing notification delivery plugins that do not require the triggering value continue to work as before.
Use Case
A notification may be configured with a threshold condition such as:
sinusoid > 80
When the value reaches 87.3, the notification is triggered. The delivery plugin should be able to generate an outgoing message containing information such as:
sinusoid value exceeded threshold: 87.3
Currently, the delivery plugin receives only the trigger reason, asset, and timestamp, so it cannot determine that 87.3 was the value that caused the notification.
Proposed Change
Extend the notification delivery mechanism so that the triggering data point information can optionally be passed to plugin_deliver.
The additional information should include:
- Data point name
- Triggering value
- Timestamp
- Asset (already available)
This would allow notification delivery plugins to include the actual triggering value in MQTT messages, Python-based notifications, and other notification mechanisms.
Basic Example
Proposed Change
Extend the notification delivery mechanism so that the triggering data point information can optionally be passed to plugin_deliver.
The additional information should include:
- Data point name
- Triggering value
- Timestamp
- Asset (already available)
This would allow notification delivery plugins to include the actual triggering value in MQTT messages, Python-based notifications, and other notification mechanisms.
Drawbacks
Currently, the delivery plugin receives only the trigger reason, asset, and timestamp, so it cannot determine that 87.3 was the value that caused the notification.
Unresolved questions
No response
Implementation PR
No response
Reference Issues
No response
Summary
Notification Delivery Plugin Does Not Receive the Triggering Data Point Value
Problem
The plugin_deliver entry point in notification delivery plugins currently receives a triggerReason JSON document containing only the reason, asset, and timestamp:
{
"reason": "triggered",
"asset": ["sinusoid"],
"timestamp": "2020-11-18 11:52:33.960530+00:00"
}
The triggerReason does not contain the actual data point name or value that caused the notification to trigger.
For example, if a notification is configured to trigger when the sinusoid value exceeds a threshold, the delivery plugin can determine that the notification was triggered and which asset was involved, but it cannot determine the actual value that caused the trigger.
This prevents notification delivery plugins such as python35,mqtt, and other delivery plugins from including the triggering data point value in the outgoing notification message.
Expected Behavior
The triggerReason should optionally include the data point name and value that caused the notification to trigger.
For example:
{
"reason": "triggered",
"asset": ["sinusoid"],
"datapoint": "sinusoid",
"value": 87.3,
"timestamp": "2020-11-18 11:52:33.960530+00:00"
}
Alternatively, the data point information could be provided through an additional parameter to plugin_deliver.
The implementation should preserve backward compatibility so that existing notification delivery plugins that do not require the triggering value continue to work as before.
Use Case
A notification may be configured with a threshold condition such as:
sinusoid > 80
When the value reaches 87.3, the notification is triggered. The delivery plugin should be able to generate an outgoing message containing information such as:
sinusoid value exceeded threshold: 87.3
Currently, the delivery plugin receives only the trigger reason, asset, and timestamp, so it cannot determine that 87.3 was the value that caused the notification.
Proposed Change
Extend the notification delivery mechanism so that the triggering data point information can optionally be passed to plugin_deliver.
The additional information should include:
This would allow notification delivery plugins to include the actual triggering value in MQTT messages, Python-based notifications, and other notification mechanisms.
Basic Example
Proposed Change
Extend the notification delivery mechanism so that the triggering data point information can optionally be passed to plugin_deliver.
The additional information should include:
This would allow notification delivery plugins to include the actual triggering value in MQTT messages, Python-based notifications, and other notification mechanisms.
Drawbacks
Currently, the delivery plugin receives only the trigger reason, asset, and timestamp, so it cannot determine that 87.3 was the value that caused the notification.
Unresolved questions
No response
Implementation PR
No response
Reference Issues
No response