A new Rule can be created in the following ways:

• Define a Rule in a JSON file. The format of such JSON file is described with the Rule JSON Scheme.
  • The JSON file can be provided packed into a bundle. The bundle simply can be a resource bundle, providing resource directory /src/main/resources/OSGI-INF/automation/rules.
  • The JSON file can be provided into the local file system in the default automation directory /runtime/osgi/automation/rules or in a directory, configured by the customer. Refer to the "Configuration Properties" section from the Setup Guide.
  • The JSON file can be provided with console command load from atm command group.

  Refer to Rule JSON Examples

• Use Java API to create rules. The rule instances can be injected to the system by using AutomationAdmin functional item service, that provides addRule method for this purpose. Use the Automation Rule Admin Demo (refer to Automation Demos or find it in ../osgi/demo installation folder ) to see how to work with the AutomationAdmin service when dealing with rules.
• Use Functional Items Management JSON-RPC API or REST API to pass a rule remotely.
• Use a Template to create a Rule. This is done from a dialog box of te Web Console, which allows you to enter an Id for the rule and values for the variables.

       •         You can load a modifiable rule with the atm.load <path_to_json_file> -r command.
       •         You will have unmodifiable rule with loading a file via File Watcher service. Its json file is in the folder you have created in advance: ../<bosch.iot.sdk_home>/runtime/osgi/automation/rules. Changes you make to the file apply to the rule. Deleting the file removes the rule from the automation module. The /automation folder must be manually created and present before the automation.core bundle is started otherwise the service will not work.

Automation Rule State Transitions

Bindings between Rule Instructions

Instructions can consume/produce static or dynamic data by virtue of their inputs and outputs. For the needs of the dynamic data there are bindings defined, which follow certain rules as described below.

An input binding is defined by:

• id – the identifier of an input
• type – the type of the source that will feed the input with value
• source – the path representing:
  • a binding to a system output
  • a binding to an output of another instruction belonging the same Rule or Template
  • a binding to a variable of Template
  • a binding to a static predefined value (constant)

    The source format depends on the binding type:

    • For Type.CONSTANT – should be a static value, i.e. source := value
    • For Type.INSTRUCTION – should be an instruction output, i.e.source := instruction-id '/' output-id (reference)*
    • For Type.SYSTEM – should be a system output, i.e. source := system-output-id
    • For Type.VARIABLE – should be a variable, i.e. source := variable-id,

    where using a reference allows accessing value of complex data type and its format could be an array or list index, e.g. [0] to refer the element at zero index id if the source value is of type array or list index

    • a map key, e.g. /id to refer the value that is associated to "id" map key if the source value is of type map
    • a bean field, e.g. /name to refer the value of "name" bean field if the source value is of type bean

It is possible to chain these references in one bigger expression, e.g. [0]/id/name.

The source of the bindings from type Type.CONSTANT must follow the proper rules:

• The value can be a string representation of JSON primitive – boolean, number or string.
• The value can be a string representation of JSON array or JSON object that not include any type information.
• The value can be a string representation of JSON object that includes the type as "Object Name", e.g. {"@com.prosyst.mbs.services.units.quantity.Dimensionless": { "unit": "%", "value": "40" } }}.

The bindings between inputs and outputs of instructions must follow the proper rules:

• If the input is required, it must be connected to an output from appropriate type as described in the tables below.
• If the input type is ParameterMetadata.Type.ANY, it can be connected to an output from any type.
• If the input type differs from ParameterMetadata.Type.ANY, then consider the supported type conversion or add a custom one via registering a custom handler to handle the conversion.

An exception to the above rules is made only in case a reference is defined.

The condition or action inputs can be connected to triggers' or preceding conditions' or actions' outputs.

Supported Container Conversion

Supported Type Conversion

Legend

• + – the conversion always applied with success
• Exception – the conversion applied fails and the rule is not accepted