Would like to be able to schedule events within automations more frequently than once per hour. Additionally, we see limitations with # of executions per second and triggers beyond a certain limit will not run. It would be helpful to a) raise the limit and b) allow the extra/additional triggers to execute in the following seconds.
Hi @audreyvdc_sbd,
How frequently are you looking to run some of these automations and if possible, could you provide additional context around what you are using them for? In addition, could you elaborate by what you mean by “triggers beyond a certain limit”?
Thanks,
Jake
Hi, Currently there is a soft & hard limit on the backend triggers of automation (example: 5 executions/second). As automations are the only way in tulip to bring automated Machine data into normal tulip tables. This limit threats us from using Machine related triggers. We have more than 100 machines, so its hard for us to control the triggers.
That makes sense - I’m curious to understand if you would still utilize automations for machines once it is out of Beta (and there would be a cost per action) and if you would still need the higher rate limit.
Sincerely,
Jake
Unless you are expecting a special agreement with Tulip, I would highly recommend avoiding any automations which run this frequently. The team has been pretty forward that eventually this feature will be pay per run in some capacity.
@yokesh.shanmugam The other way to do this same thing is to use a Tulip app as the communication layer between machines and tables. I frequently do this from inside of a dashboard app which I know will be running quite often.
1 Like
We tried the tulip app as communication layer & it got failed. Because there were data losses when the app goes offline. As well maintaining a 100% device uptime and internet connectivity is not a cup of tea for a typical shopfloor. The only reason we thought of using automations is that it provided a headless transaction. If automations will become “pay as you use” in future, then no we would not think to utilize automation for this purpose. Instead we would look for an alternative improvement from tulip side to address the current limitations in Machine module. Either improving the Machine table schema & its functionalities similar to normal tulip table (or) machine tiggers to log data into tulip tables (or) any sort of change that can remove the current limitations on machine tables and its modules.
Currently we are utilizing third party softwares to handle the machine logics & logging the data into tulip tables for app integrations. But we want to get rid of managing two or more systems and looking forward to bring everything possible into tulip.
1 Like
Late to the party!
I’m looking to use automation to downgrade a status (hygienic status clean to dirty for instance) after a set period after cleaning. Lets say it stays clean for 8 hours. I dont want to rely on an app running to change that status, because a different app will want to check “is the equipment clean”. So in an ideal world I would write an expiry of the status to a table field and (my thought) was to have an automation periodically read the table and change all and any equipment that has expired to the downgraded status - similar to the looping training check, but more regular. (Ok - would need looping to do all the equipment - which isnt available yet but…). With a minimum automation schedule of 1 hour you could be 59 mins out of doing a downgrade. I could create multiple automations at different times but that seems over the top.
Alternatively (and much better) would be to be able to schedule an automation from an App - so when I perform the clean I could schedule an automation to run in 8 hours…
Andy
Hi @andybmac,
To tackle this kind of problematics I would see the following approachs:
- Having an app running 24/7 on a server that will check every Xminutes if any of your equipment timer has expired (using Aggregation, loops, …)
- Using Tulip table API to manage the proposition above externally (python script or whatever).
- Having the check logic from proposition 1 in all your apps where you need to select/view the status of your equipment (I would not go with this approach)
As for automation, if there will be a cost per use in the future, I would advertise against using it on recurrent basis.
Kind Regards,
Kevin
Hi @andybmac,
What I would recommend is having a schedule run on an hourly basis (or set it up with a half-hour bias) - for example, you could set one up to check on the hour and another to check half past the hour.
With looping coming out in the next release or two, here’s how I would set it up. I would have a connector to the table API with a query that looks for the current time or earlier and returns the list of IDs. I would loop over that list of IDs and perform whatever action that you need for each item.
I know that doesn’t fulfill the exact criteria that you were looking for but should suffice.
Thanks,
Jake
Hi @kefl,
That’s a good alternative solution with the app.
However, I do take issue with the recommendation that this is cost-prohibitive. Part of the reason that Tulip is taking time to come out with pricing is to make sure that customers using automations can do so at a reasonable cost for a variety of use cases.
When automations pricing comes out, I would encourage you to compare the cost of this specific automation (give or take 1440 tasks per month with the recommended approach) compared to the cost of a station.
Sincerely,
Jake