Hello,
I’m working on alerts and thresholds. What I need to do is not send an alert immediately on a given threshold, but wait until that threshold has been exceeded multiple times in a row. So let’s say a temperature is above the threshold - I don’t want it to alert until I’ve seen it above that threshold n times consecutively in the device state payloads.
I’m looking at latch and math nodes, but I’m not sure how I could pair them up to get the desired effect.
TIA.
@Wayne_Hughes we’re actually working on an implementation of this currently and will report back shortly.
Hey @Wayne_Hughes,
Implementing this requires an unintuitive use of Workflow Storage, so I went ahead and created a Custom Node with this behavior. You can download it here:
consecutive-threshold.node (11.2 KB)
This node accepts the following inputs:
Value: The incoming value to compare against the threshold.Threshold: The threshold to compare against the incoming value.Comparator: How to compare the threshold against the incoming value (greater, less, equal).Identifier: Optional. A unique identifier that allows this node to perform threshold checks for multiple sets of data. A common identifier is a device ID.Count: The number of consecutive times the value must exceed the threshold before taking the true path.This is a branching node that “latches”, which means it will only take the true path one time when the consecutive count has been reached. This prevents continuous alerts if the value continues to meet the threshold. The latch resets whenever the value no longer meets the threshold. For more details, check out the Latch Node.
Here’s a screenshot of the implementation:
Thanks for the question! This custom node solves a pretty general problem and it’ll make a great addition to our Template Library.
Thank you, @Brandon_Cannaday and @Dylan_Schuster - amazing timing. I’ll download and go tinker and see what I can break! 
Your solution is probably a better process overall, but I didn’t understand a lot of what I was looking at, so I tinkered until I figured this all out. This may not work for everyone, but the effect for me works well. I had to add an attribute to my devices to store the counter value. My devices send data every 5 minutes, my threshold is 3. This flow will evaluate consecutive changes for a device and set the counter accordingly. I use the device:get to retrieve the previous counter value, as that field may not change which would cause problems for the conditional node.
I just got a chance to check this out. One thing to keep in mind is that workflows and data storage are asynchronous processes within the Losant platform. When device state comes into Losant, they are queued and processed independently by separate pools of worker services. This is an architecture that facilitates the large scale at which our customers and platform operate.
This means when a workflow is triggered, there are no guarantees when it comes to querying data, especially the most recent data point. There are many reasons why the storage service or the workflow service could be temporarily delayed, which will introduce inconsistencies with your implementation.
For example, your Device: Get Node does return the previous data point most of the time. However, if the workflow service is delayed even a few hundred milliseconds, the storage service may have already persisted the new data point. If that happens, the Device: Get Node will return the same data point that triggered the workflow - not the previous data point. This can happen fairly regularly and will confuse your implementation.
For devices reporting more frequently (< 60 seconds), there’s also a chance the workflow will trigger before the storage service has persisted the previous data point. In this case, the Device: Get Node can return any arbitrary data point from the recent past.
This is why I chose to use a counter in workflow storage instead of a counter on a device attribute.
All that said, it is quite common that users do require the previous data point whenever a workflow triggers. Our underlying architecture makes implementing this behavior challenging, but we are aware of the issue.
I’ll keep that in mind and try to come to an understanding of the custom node. Is there a blog or doc that walks through it piece by piece?
There’s no post that walks through the implementation, but the node is now in the Template Library, so there is a readme that explains it a little. Once imported you can open the custom node and see the details of all the inner nodes.
