...
...
...
...
...
...
...
...
...
| Section | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
|
...
|
Modules with interval and timeout
...
The GPIO DIO waits for input changes with a timeout parameter. The timeout for that is configurable with the attribute polling_interval, with a default of 10000ms (10s). If the corresponding sensor_gateway is configured to publish_strategy="always" then a raw_result of the GPIO input/output states will be generated all "polling_interval" milliseconds.
polling_interval
| unit | min | max | default |
|---|---|---|---|
milliseconds | 1 ms | undefined | 10 000 ms |
...
The ap_scanner is a data acquisition module which scans Wireless Access Points on the neighborhood.
interval
Mandatory parameter which defines the interval in milliseconds between each scan.
| unit | min | max | default |
|---|---|---|---|
milliseconds | 1000 ms | undefined | undefined |
timeout
Mandatory parameter which defines the maximum amount of time that the scan is allowed to run, in milliseconds.
| unit | min | max | default |
|---|---|---|---|
milliseconds | 1000 ms | undefined | undefined |
...
Modules with scheduled polling
The DA modules, listed in this section use a configuration schema to control the scheduling, which is defined in the XML schema definition (XSD).For completeness this schema definition is shown here:
Schema
| Warning |
|---|
This complex schema definition is currently only partially used in the DA modules, which are listed in this section. Different DA modules use this definition in a different way. It is planned for future to implement a common software module, which supports all DA modules in time scheduling in the same way. |
| Note |
|---|
The timing resolution of these modules is limited to a second. Even though the units are milliseconds the values get rounded internally to seconds. |
...
These three DA modules use the schema definition above in the same way.The used parameters are:
polling_interval
time between each query
| unit | min | max | default | remark |
|---|---|---|---|---|
milliseconds | 1000 ms 1 | undefined | undefined | rounded to seconds |
...
| Include Page | ||||
|---|---|---|---|---|
|
Example
| Code Block | ||||
|---|---|---|---|---|
|
...
| |||
[data_store]
...
# default upload strategy (never, on_change, interval, always)
upload_strategy = interval
# upload interval to server in seconds
upload_interval = 60
... |
The SiteController.cfg is on default regarding the upload_interval (60s) and the upload_strategy (interval).
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<component_template config_version="1.0" schema_version="1.5.16-Aspirator">
<description>DA rest client</description>
<class>multi-sensor</class>
<vendor>azeti</vendor>
<version>1</version>
<sensors>
<!-- REST sensors -->
<sensor sensor_id="rest_temperatures_sensor/cooler">
<sensor_class>unknown</sensor_class>
<sensor_gateway sensor_gateway_id="rest_temperatures_gw">
<demux>
<keys>
<key>cooler</key>
</keys>
</demux>
</sensor_gateway>
</sensor>
<sensor sensor_id="rest_pressures_sensor/tire">
<sensor_class>unknown</sensor_class>
<upload>always</upload>
<sensor_gateway sensor_gateway_id="rest_pressures_gw">
<demux>
<keys>
<key>tire</key>
</keys>
</demux>
</sensor_gateway>
</sensor>
</sensors>
<devices>
<device device_id="rest_server">
<rest_client_device>
<host>http://192.168.118.26:7088</host>
<form_auth>
<uri>/rest/login.php</uri>
<form_data>
<form_key_value>
<pair_key>username</pair_key>
<pair_value>operator</pair_value>
</form_key_value>
<form_key_value>
<pair_key>password</pair_key>
<pair_value>LetMeIn</pair_value>
</form_key_value>
<form_key_value>
<pair_key>t</pair_key>
<pair_value>OK</pair_value>
</form_key_value>
</form_data>
<method>post</method>
</form_auth>
</rest_client_device>
<sensor_gateways>
<sensor_gateway publish_strategy="always" sensor_gateway_id="rest_temperatures_gw">
<rest_client>
<uri>/rest/temperature.php</uri>
<scheduling>
<polling_interval>15000</polling_interval>
<error_handling>
<retry retry_interval_before_alert="9000"/>
<timeout_handling>
<fixed_timeout>3000</fixed_timeout>
</timeout_handling>
</error_handling>
</scheduling>
</rest_client>
</sensor_gateway>
<sensor_gateway publish_strategy="always" sensor_gateway_id="rest_pressures_gw">
<rest_client>
<uri>/rest/pressure.php</uri>
<scheduling>
<polling_interval>15000</polling_interval>
<error_handling>
<retry retry_interval_before_alert="9000"/>
<timeout_handling>
<fixed_timeout>3000</fixed_timeout>
</timeout_handling>
</error_handling>
</scheduling>
</rest_client>
</sensor_gateway>
</sensor_gateways>
</device>
</devices>
</component_template>
|
In the example configuration above are 2 sensors configured, each with an own sensor gateway at the data acquisition device. Usually more then one sensors are using the same sensor gateway, which would be possible also here.Both sensor gateways are configured to have the publish_strategy always (default is on_change).
In the example configuration the sensor rest_pressures_sensor/tire is configured to have the upload_strategy always. The other sensor rest_temperatures_sensor/cooler remains with the default upload_strategy interval.
Both gateways of the device 'rest_server' emit their raw results all 15 seconds, regardless if there was a change in the values, because both gateways are configured with the publish_strategy="always"
The sensor rest_pressures_sensor/tire is configured with the upload strategy <upload>always</upload>. This way in the cloud the sensor data are present with a difference in their timestamps of 15 seconds.
The sensor rest_temperatures_sensor/cooler has no specific upload strategy in its configuration, so it uses the default upload strategy interval which is set to 60 seconds (see the Example snippet of the SiteController.cfg above). Herewith the sensor data are present in the cloud with a difference in their timestamps of 60 seconds.
| Info |
|---|
In both cases additional values are uploaded to cloud, if there is a change in the value. |