| Section | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Action messages
Actions are executed by actuator modules. The actuator modules execute an action if they receive an action message.
topic
The topic of an action message has a structure like this: cloud/VM1-Priem/exec_action/Padlock
payload
The payload of an action message must be in JSON like this:
...
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.
| Code Block |
|---|
<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 | ||
| VirtualSensorProvider | publish calibrated result | |
| http_server | get images | |
| gpio_dio | set digital outputs | |
| snmpgetd | ||
| simonsvoss | door lock things |
The fallback of an 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.
...
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
...
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.
...