What are condition-action engines?

Condition-Action based (CA) rules engines belong to the group of Forward Chaining engines, however there are some relevant differences, especially in the context of the IoT domain. AS oposed to forward chaining engines, Condition-Action rules engines don’t allow multiple conditions, which makes them on one hand very limited in their logic expression capabilities and on the other hand – much more scalable. Condition-Action rules engines (if this – then that) are sometimes extended with the ELSE statement (if this – then that – else – that).

‍

What are some examples of condition-action engines?

One of the most popular examples of this type of rules engine for the IoT domain is the ifttt.com service.

‍

Can you build complex logic with condition action engines?

No, unlike forward chaining engines, CA engines can not model any complex logic (such as combining multiple non-binary outcomes, majority voting or conditional executions). They are 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 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 the 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, and even though we may argue that this is not something that is part of the rules engine per se (because it needs to be coded somewhere else), it is still obvious how the time dimension could to be introduced into the rules engine.

‍

Are condition-action engines explainable?

Just like forward chaining engines, CA engines like IFTTT provide us with an easy way of designing rules for simple problems. There is nothing easier to grasp than if-this-then-that rules!

‍

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 times, CA engines use API services as triggered actions, not as inputs, as there is a single conditional input slot available, which in IoT use cases is usually taken by the device data. A typical example would be, for instance, to call an external API service (SMS, email, support ticket etc) if a device temperature registers above 25.

When CA engines do model the data of an API service as an input (what the ifttt.com CA engine for example 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, and 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 for example is possible as long as thresholds and all the other conditions do not 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 is very easy to scale these rules engines. However, they do not get the maximum score for this category, as scalability is truly achieved by only one rules engine category, namely the stream processing engines.

This 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.

‍

‍