Condition-Action Rules Engines for IoT

Condition-Action (CA) engines are simple, adaptable and scalable. They can connect IoT devices to create powerful chains of commands and operations, pushing the limits of what IoT can do.

571
Image of an
Illustration: © IoT For All

What Are Some Examples of Condition-Action (CA) Engines?

One of the most popular examples of the “Condition-Action” (CA) type of rules engine for IoT is the ifttt.com (“If this, then that.”) service.

Can You Build Complex Logic With Condition Action Engines?

No, unlike forward chaining engines, CA engines cannot model any complex logic (such as combining multiple non-binary outcomes, majority voting or conditional executions). They’re meant to be used only for very simple use cases.

Can Condition-Action Engines Model the Time Dimension?

One way these engines work around the time dimension problem (knowing the exact time to perform an action) is that they often rely on external triggers for determining which rule to execute. That is to say, the IF condition of a rule becomes a WHEN condition (e.g. When weather is bad, send an alarm; when I come home, turn on the lights). This is often referred to as a trigger in these tools. Even though we may argue that this is not something that’s part of the rules engine per se (because it needs to be coded somewhere else), it’s still a way for the time dimension to be used in the rules engine.

Are Condition-Action Engines Adaptable?

Yes, condition-action engines are both flexible and extensible. Adding third-party API services for example is rather simple, as the API extensions require minimal abstractions (the ‘if’ and ‘act’ part). However, due to the nature of CA engines, there are limitations with regard to the usage of API services within rules.

Most of the time, CA engines use API services as triggered actions, not as inputs since there’s a single conditional input slot available, which in IoT use cases is usually taken by the device. A typical example would be to call an external API service (SMS, email, support ticket, etc.) if a device temperature registers above 80 degrees.

When CA engines model the data of an API service as an input (what the ifttt.com CA engine calls a trigger, e.g. “if it is going to rain”), then we cannot combine this API service input with device data, as the single input slot is taken; we can only use the device in this case as the actuator (e.g. “turn on lights”).

Are Condition-Action Engines Easy to Operate?

Applying the same rule across many devices is possible as long as thresholds and all the other conditions don’t change. Templating, versioning and searchability are rather easy to achieve with such rules engines, but bulk upgrades are more difficult, as conditions and thresholds are often global variables and hard to change per instance of the running rule.

Are Condition-Action Engines Scalable?

CA rules are stateless and very simple, so it’s very easy to scale these rules engines. However, they aren’t the best option for scale, as scalability is only truly achieved by only one rules engine method: stream processing engines.

This aricle is an excerpt from our latest Benchmark Report on Rules Engines used in the IoT domain. You can have a look at a summary of the results or download the full report over here.