Since openHAB 2.4 another Rule Engine has been added.
It allows Rules to be edited in a graphical fashion and to interact with [JSR223 Scripts (Javascript, Jypthon, etc)](https://www.openhab.org/docs/configuration/jsr223.html).
A rule consists of basic information like name, tags and a description. The main building blocks of rules are modules however, and each rule consists of one or more instances of each of the following modules:
- **'trigger'** modules specify the events that trigger a rule execution.
- **'condition'** modules act as a filter for rule execution.
Actions of the rule will be executed only if event data satisfies all conditions.
In case there are multiple conditions in the 'if' section then all of them must be satisfied.
- **'action'** modules perform actual operations in openHAB.
If more than one action is specified in a rule they will be executed sequentially.
The output of the previous action can be used as an input for the next action.
An imaginary action can therefore also just be a conversion to make one action output compatible to another actions input.
Each module is created from a template called **Module type**.
A module type specifies parameters for the template, like e.g. "eventTopic" for the "GenericEventTrigger" or "operator" for the "GenericCompareCondition".
The automation engine provides some generic module types.
Those can be extended by so called **composite module types**.
Those use predefined configurations and/or modified module input/output objects.
> An example is the module type "ItemStateChangeTrigger" which is based on the GenericEventTrigger but specifies in its configuration that it is triggered only by item's state change events.
### Module Types
A given **Module type** has the following elements:
The types supported in the **input/output** objects can be any string and the following validation is performed:
- if the input type and the output type are equal as string the connection is valid
- if the input type is "*" and the output type is any the connection is valid
- if the input type and the output type are strings representing full qualified names which can be loaded and the input type is assignable from output type the connection is valid
The types in the **Configuration** object are restricted to the following:
- TEXT - The data type for a UTF8 text value
- INTEGER - The data type for a signed integer value in the range of Integer#MIN_VALUE, Integer#MAX_VALUE
- DECIMAL - The data type for a signed floating point value (IEEE 754) in the range of Float#MIN_VALUE, Float#MAX_VALUE
- BOOLEAN - The data type for a boolean: true or false
- GET /rest/module-types - returns all registered module types.
- optional parameter 'type' with possible values: 'trigger', 'condition' or 'action' - filters the response to include only module definitions of specified type.
- optional parameter 'tags' - filters the response to include only module types which have specified tags.
- GET /rest/module-types/{moduleTypeUID} - returned response includes only the content of the specified module type.
- GET /rest/rules - returns all registered rule instances.
- POST /rest/rules - adds new rule instance to the rule registry.
- DELETE /rest/rules/{ruleUID} - deletes the specified rule instance.
- PUT /rest/rules/{ruleUID} - updates the specified rule instance.
- PUT /rest/rules/{ruleUID}/enable - enable/disable specified rule instance.
- PUT /rest/rules/{ruleUID}/runnow - executes actions of specified rule instance.
- GET /rest/rules/{ruleUID}/config - returns the configuration of the specified rule instance.
- PUT /rest/rules/{ruleUID}/config - updates the configuration of the specified rule instance.
- GET /rest/rules/{ruleUID}/triggers - returns the triggers defined for the specified rule instance.
- GET /rest/rules/{ruleUID}/conditions - returns the conditions defined for the specified rule instance.
- GET /rest/rules/{ruleUID}/actions - returns the actions defined for the specified rule instance.
- GET /rest/rules/{ruleUID}/{moduleCategory}/{id} - returns module instance with specified id and category {triggers/conditions/actions} of the specified rule.
- GET /rest/rules/{ruleUID}/{moduleCategory}/{id}/config - returns the configuration of the specified module instance.
- GET /rest/rules/{ruleUID}/{moduleCategory}/{id}/config/{param} - returns the value of specified module configuration parameter (media type is text/plain).
- PUT /rest/rules/{ruleUID}/{moduleCategory}/{id}/config/{param} - updates the value of specified module configuration parameter (media type is text/plain).
`automation importModuleTypes [-p] <parserType> [-st] <url>` - Imports Module Types from given url. If parser type missing, "json" parser will be set as default.
`automation importTemplates [-p] <parserType> [-st] <url>` - Imports Templates from given url. If parser type missing, "json" parser will be set as default.
`automation exportModuleTypes [-p] <parserType> [-st] <file>` - Exports Module Types in a file. If parser type missing, "json" parser will be set as default.
`automation exportTemplates [-p] <parserType> [-st] <file>` - Exports Templates in a file. If parser type missing, "json" parser will be set as default.
Rule templates can simplify the definition of rules with similar behavior by providing additional configuration properties. Then rule instance definition only refers the rule template and provides the values of the configuration properties.
The rule template is used only once when the rule is imported in the Rule Engine.
After that the reference from the rule instance to the rule template is removed and a given rule may exist even if the rule template is removed or modified.
This will not have any impact on the already imported rules.
The rule engine is pluggable - any OSGi bundle can provide implementation for triggers, actions and condition module types and their corresponding metatype definition in JSON format.
The composite module type can also have inputs and outputs and can use a reference to map them to inputs and outputs of the nested system module type(s).