Addition of a Timer capability

Feature Request
,
1

Hi

I have had a number of situations where I need a timer to fire in at a point in the future to trigger a workflow.

At the moment the only solutions I can come up with convoluted or require some external service.

The simplest way to achieve this is to use an Edge Agent that also has REDIS installed on the same host, and subscribe to events. Then if I need a workflow to trigger in 10mins, set an expiry time on a REDIS value, and set redis to provide Keyspace notifications.

The based on some criteria set a value with the desired expiry time, and then have a workflow subscribe to the event.

Unfortunately this doesn’t work in cloud workflows as we can’t subscribe to REDIS Pub/Sub.

Other schemes I have come up with cloud workflows, include

  • Use the Edge Agent to send an appropriate data, or call API in Losant, as a result of the above local Redis key Expiry.
  • define timeout, and start time in a Datatable, then have a workflow run every 30 seconds with a timer, that queries recent data table records and checks for timeout duration expiration.

Neither seem particularly elegant.

May be you could generalise the REDIS key expiry mechanism as a general purpose timed event generator for cloud workflows ?

Thanks

Tim

2

Hi @Tim_Hoffman1,

I think this is a splendid idea! Something of a non-recurring timer or a “countdown clock.” The ways around this are a bit cumbersome, but I could see a tag value time set as a timestamp string, and a Timer Node that would compare the current time to the tag time, and fire if it is past that time. Again, it’s by no means an elegant way around the problem, and is similar to your second suggestion and may not be ideal for your use case.

I will pass this over to our engineers as a feature request. :smile:

Thanks,
Julia

3

Hi Julia.

Again that is the constant polling data via a timer scenario. Which feels expensive.
Also tags, would limit the numbers of timers for a device that was possibly active.

A Data Table of timers allows abstract events not tied to a single device that allows workflow(s) to be triggered for a range of scenarios. Also datatable would provide visibility of upcoming timers.

However I feel a first class single shot timer entity (I know you have now where to put such a thing at the moment) which could be cheaply created and destroyed, would be ideal.

I will work on a complete model based on Data Tables in the meantime.

Thanks

Tim

1 Like
4

Tim-

I failed to weigh the factor of payload limits; in retrospect, a timer would indeed be costly! I will pass this over, and as always thank you for your suggestions. :grinning:

Thanks,
Julia