Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Introduction

An action is a set of instructions that can be executed by the operator or even by an automated rule. An action can generate events, can use physical and virtual actuators and publish calibrated results.

On this page:


Writing a single coil

Here we have an example of writing a single coil to illuminate an LED, using the X20BC0087 ModBusTCP device from B&R.


<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

module
perfomend actions
comment
ModbusMaster

VirtualSensorProviderpublish calibrated result
http_serverget images
gpio_dioset digital outputs
snmpgetd

simonsvossdoor lock things

The fallback of an 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 action after the first action.

Here is an example of a flapping state:


</action>
 <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>


Please note that such a behavior can be easily configured with the Automation Controller (AC). Such a blinker would be stoppable.


Sys messages about the action execution

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

The modules are not sending events about the action execution


Actions, executed by the VirtualSensorProvider

It is mandantory to have a device_id with the name


device_id="VirtualSensorProvider"


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:


<device device_id="VirtualSensorProvider">
    <simulator/>
</device>


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

Here is an example:


<action action_id="Alarms" device_id="VirtualSensorProvider">
    <commands>
        <command command_id="Reset">publish_calibrated_result('Alarm', False)</command>
        <command command_id="Set">publish_calibrated_result('Alarm', True)</command>
    </commands>
</action>


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:


{
    "action_id": "SimulatedSensor",
    "exec_uid": "1bb083fc-8924-4324-8971-db22513ca78c",
    "origin": "SSCServices",
    "user_id": 70752,
    "command_id": "OK"
}


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


[
    {
        "code": null,
        "output_long": null,
        "output_short": "Action 'SimulatedSensor OK' executed by VirtualSensorProvider",
        "reference": {
            "action_id": "SimulatedSensor",
            "actuator": "VirtualSensorProvider",
            "command_id": "OK",
            "exec_uid": "1bb083fc-8924-4324-8971-db22513ca78c",
            "origin": "SSCServices",
            "user_id": 70752
        },
        "severity": 0,
        "timestamp": "2015-11-27T09:42:43.574Z+0000",
        "type": "action"
    }
]


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.

Attention

It the triggering item (e.g. calibrated result) has no result_uid the the Automationcontroller uses a timestamp as exec_uid for the action.

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

To let have a normal calibrated result and its event a result_uid simply add any action_ref to the configuration of the calibrated result.

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

  • Link to a further read
  • Link to other articles
  • and more links
  • No labels