We don’t think of an internet-of-a-couple-of-things when talking about IoT. It’s an internet-of-many-things or maybe even an internet-of-all-things that comes to mind. So the idea of connecting large groups of objects is held within the very definition of IoT. Next, the value of IoT resides not in connecting the objects per se but in what happens after we get them online, namely what happens when we apply business logic to them. So one of the biggest challenges in a live operational IoT deployment is managing these two aspects: device onboarding– bringing ever growing numbers of devices online, and rules lifecycle management– managing the rules that make up the logic we want to run for them.
This post aims to give a brief explanation into how we do the latter at Waylay.
In the Waylay rules engine, you start building your logic in the form of a generic template, from which you create running tasks for your IoT devices. When the rules change, so do the running tasks. This is achieved through a process called template migration.
What is a template in Waylay?
Within the Waylay framework, a template is a generic piece of logic built with sensors, functions, gates and actuators that has no runtime data associated to it. Once we associate a resource (a device) and its runtime data to a template, the template gets instantiated in the form of a task.
You can deploy a template in the form of as many tasks as you need. If you have let’s say one single AC unit you would like to run the logic for, you would deploy your template as one task. For 100 AC units, you would deploy it as 100 tasks, for 100k units- 100k tasks, and so on. The strength of the Waylay template is that it enables a clean and consistent deployment model for very large groups of devices.
What is a template to type association in Waylay?
The way templates are actually able to do that in a fully automated way is through the template to resource type association. The template to type concept refers to the association of a template to a particular type of resources, for example to a group of devices that share common characteristics, such as manufacturer and model. The real strength of the template to type association is that it enables the automated instantiation of tasks for new devices of that type that are being discovered at any time after the template started running in production.
To continue with our example above, let’s say that you have built your logic and deployed it for your 100 AC units. As your business grows, new AC units will come online that will need to have the same logic applied to them. Thanks to the template to type association, as soon as they are discovered by the system as part of a resource group, all logic associated to that group will automatically start running on them. There’s nothing for you to do, no additional steps or manual configuration whatsoever.
The opposite is also valid. If a device is no longer recognised as part of a resource type, all of that type’s related tasks are automatically stopped for it. If for example, the device gets a firmware upgrade and it now belongs to a different resource type, all tasks running will be automatically stopped and, if the new resource type that it now belongs to has any logic associated to it, new tasks will be automatically started for it.
What is template migration in Waylay?
The concepts of template and template to type association explain the smooth automated processes of running logic on very large groups of devices, automating the instantiation of logic for new devices joining and the clearing of logic for devices leaving the group. But what happens if you need to change something inside the very logic being deployed? As business evolves, you may want to add new services or discover new applications that require changes in the initial logic scenarios. This is where template migration comes into play.
Template migration is the feature that ensures that all changes done to the template are automatically applied to all associated tasks running on that template. So if you need to change something inside the logic that is running for your 100 AC units, changing the template and using the migration feature will automatically update all 100 tasks running for the devices, without any additional configuration necessary.
The template migration feature is not only useful for changes coming from the business side but (and more importantly) is applicable for all other types of changes that we need to account for when deploying automation tasks in production environments, such as for instance changes or updates to various sensors or actuators that we are using in our logic. It is a crucial element to ensure your automation solution is as agile as your business and ultimately- future-proof.
Here is a short demo of the template migration feature. In the example below, we edit a simple template to change the message that we want to receive on Slack. Migrating the template automatically updates the logic for the three tasks that we have running on the template.
Read more on template migration on our technical documentation site:
Interested to learn more about the platform’s capabilities or have a question? Request a free demo session here.
