I seek an advice how to implement Start/Stop Timer in Losant. Basically, I have devices that temporary loss connection. I’d like to set up a notification only if a device has been down for more than N minutes. So, users receive notifications only about major connection issues. A Delay Node seems to be a good match for what I search for (Logic Path: Disconnect Event + Delay + Device Status Check = Decision about Notification), however this node has a limitation in 60 seconds maximum.
What would be the right approach to implement that logic?
Are you able to use the Device: Inactive Trigger? Inactivity is not necessarily tied to connectivity, but it’s usually a consistent symptom. If your devices are connected, but not reporting state, that trigger won’t work, and we can explore different options.
Hi Brandon, I finally tested the Device: Inactive Trigger. No event was created after the device stayed offline longer than a timeout. Because of that, I can make a conclusion that this solution does not work. Could you suggest another approach how to catch devices with unstable connection that disconnects from Losant for longer than a timeout?
That’s what I did, by the way: 1) Set up a workflow containing a notification run by Device: Inactive Trigger. 2) Checked that the device online, powered off the device 3) Checked that the device status changed to Offline on Losant 4) Waited a timeout 5) Checked if any notification was received from workflow 6) Nothing was received
The Inactive Trigger uses Device State to monitor activity. Whenever a new trigger is added to a workflow, it requires at least one state message to come through to start its internal timer. So if you powered up and then powered down the device without sending any state, the trigger’s internal timer never started.
We did this because we didn’t want previous inactivity to trigger new workflow triggers. An application could have thousands of devices that are inactive and we didn’t want a new trigger to immediately fire for all of them. So we made the decision that those triggers will start their own timers when they receive their first state message.
Let me know if that implementation will work for your use case. If not, we can still investigate other options.
Brandon,
Thank you for your reply. So far, I was not able to get Inactive trigger working even once. Probably, I need to re-check my setup. I will test this more carefully as you described.
One more follow up on Inactivity Trigger Node. I was able to make my devices to report on inactivity.
I have the opposite question now, how to trigger an event when the device returns from inactivity. I mean it’s possible to use a timestamp of last update and a Connection Node to create some workflow logic, but may be there is a simpler solution or another existing Node I can use for it.
I think you would likely still need to use two nodes (based on your use case), but the Device: State Node would probably be your best trigger (the Device: Connect Node may also help here). The workflow would be triggered each time a new state is reported, so you might, based on use case, need to [check when the last state prior was reported to ensure it was actually a “return from inactivity,” and not a normal state report. Helpful Nodes for this would be the Date/Time Node, and the Data: Time Series Node.
I can also make a ticket for this functionality if you would like!
Thank you for your reply. It would be useful to have “Return from Inactivity”/“Activity” trigger Node. Using a device state node is a bit prodigally I guess, because it is counted towards the accumulated number of monthly payloads. Currently I added one “inactive” Boolean attribute to each device to record activity/inactivity events, but such approach does not seem to be matching a “Losant” way.
One related question, does Inactivity Node for an Edge Compute type of devices triggered by payloads reported only by Edge Compute (stored attributes of a Edge Compute device) or by all peripheral devices dependent on that particular Edge Compute device as well? Asking because I have one gateway example where inactivity node generates events, but the device does not disconnect longer that the Inactivity timeout and peripheral devices continue sending/storing payloads in attributes…
I created a Feature Request for this functionality; I will update you in the future should this become available.
Inactivity is tracked by receiving state for the specific device, regardless of where the state comes from or how it arrives. A gateway reporting state for a peripheral will reset the peripheral’s inactivity timer, but will not have any effect on the gateway’s inactivity timer, since no state was reported for the gateway itself.
I will be inviting you to this example application momentarily, but I used a Latch Node to do some routing here.
In this workflow, the Latch Node only branches right (true) after the Device: Inactive Node has been triggered and is followed by a trigger of the Device: State Node. Thus, when state is reported consecutively, it will branch left, and when the Device: Inactive Node is triggered, it will also branch left.
Also note, the Device: State Node does not incur an additional payload, as it is the same payload from when state was reported to or by the device.
I will add you to this example application, keep an eye on your inbox!
