...

<actions>
	<action action_id="Switch_LED_red" device_id="dev_X20BC0087">			# Here we define the name of the action and also which device is used to execute the command.
    	<commands>
      		<command command_id="ON">write_single_coil(12,[1])</command>	# Define the command ON and set the coil on the register 12 to 1.
        	<command command_id="OFF">write_single_coil(12,[0])</command>	# Same, although now we switch to OFF and set the coil to 0.
    	</commands>
    </action>
	.
	.
	.
</actions>

Actuator modules

actuators a the modules which do the action. All actuator modules are Data Acquisition Modules but the VirtualSensorProvider

...

...

...

...

The fallback of an action

Fallback action

An action command is configurable with a fallback_command_id and a fallback_time_ms. This does not mean an error handling but a following a fallback, which allows to trigger an action after the first actionone has been executed. Here is an example of a flapping state:

 	<action action_id="Blink"

 device_id="VirtualSensorProvider">

    	<commands>
        	<command command_id="ON"

 fallback_command_id="OFF"

 fallback_time_ms="1000">publish_calibrated_result('Blinker', True)</

command>
    		<command command_id="OFF"

 fallback_command_id="ON"

 fallback_time_ms="1000">publish_calibrated_result('Blinker', False)</

command>
  		</commands>
	</action>

Sys messages about the action execution

The actuator modules, which execute an action (should) send sys messages about the action execution (success / failure etc.).

Actions, executed by the VirtualSensorProvider

It is mandantory to have a device_id with the name

...

definded for an action, which should be executed by the VirtualSensorProvider.

Other names are not recognized by the ConfigProvider. To complete the demands of the xml schema the following stub must be defined in the configuration xml too:

At the moment the VirtualSensorProvider is able to do the action: publish calibrated results.

Here is an example:

...

Execute an action on startup

There are many scenarios where you might want to execute an specific action at startup. It can be easily configured adding exec_on_startup="true" to the command parameters.

<command command_id="Activate_theft_check" exec_on_startup="true">publish_calibrated_result('CheckBatteryTheft', True)</command>

Actions, executed by the VirtualSensorProvider

The VirtualSensorProvider allows the operator to create sensors, which do not have a physical device attached to them. This is especially usefull for setting "States of Alarm" to an system.

Here we will see a small example to set the value of the sensor to true or false.

<action action_id="Alarms" device_id="VirtualSensorProvider">							# Definition of the action and the obliogatory device id. It is important that the device id is the "VirtualSensorProvider".
	<commands>
    	<command command_id="Reset">publish_calibrated_result('Alarm',False)</

...

command>
		command command_id="Set">publish_calibrated_result('Alarm', True)</

...

The exec_uid of an action

Actions can be fired (initiated) by

1. clicking an action button in the GUI of the server (cloud)
2. by the AutomationController

Actions fired from sever side

If the action is fired from server (1) it should get always an exec_uid like this:

...

The actuator of this action informs about the execution of this action by a sys_msg to server:

...

As expected the exec_uid in the returned sys_msg must be the same as in the action command.

Actions fired from AutomationController

It is a bit more complicated regarding the exec_uid, if the AutomationController (AC) fires an action to an actuator. The AC fires an action in case of a valid condition in a rule (if an action is configured there). The AC rules are triggered by the appearance of calibrated results or events (tiggering item). The triggering items may have a result_uid. This result_uid is taken as exec_uid for the action fired by AC.

Calibrated results and events, 'produced' by the AC have always a result_uid.

If a calibrated result with any action_ref leads via AC to an action, the server (cloud) could find the calibrated_result related to this action result.

Example: Since imgdata contain the exec_uid the server could find the calibrated result (e.g. 'Door_open') which caused this image.

Next Steps

command>
    </commands>
</action>

Actions, executed by an Automation Rule

An action can also be automatically be executed by an Automation Rule. These rules can be executed per example, if a special event is happening or specific values are reached.

More information about the Automation Rules can be found Automation Rule.

Next Steps