| 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:
{"origin": "AutomationController", "sensor_id": "Access_Control_Door", "user_id": null, "exec_uid": "2016-04-22T14:22:24.428Z+0000", "action_id": "Padlock", "user_name": null, "command_id": "Release_lock"} |
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
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
- clicking an action button in the GUI of the server (cloud)
- 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
| Info |
|---|
|