...
...
...
...
...
...
...
...
...
...
...
Modules with interval and timeout
http_server
The http_server works passive regarding incoming notifications (no polling, no timeout) and is driven by actions to request images. These requests have a configurable timeout. If this timeout is exceeded the action ends up with an error.
| unit | min | max | default |
|---|---|---|---|
| seconds | 1s | undefined | 60s |
GPIO DIO
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 |
da_external_checker
The da_external_checker is a data acquisition module that periodically invokes an external script.
interval
Mandatory parameter with the period in milliseconds to wait until try to launch the script again. This value is expected to be bigger or equal to 1000 (1 second)
| unit | min | max | default |
|---|---|---|---|
milliseconds | 1000 ms | undefined | undefined |
timeout
Mandatory parameter with the amount of time in milliseconds that a script could run.
| unit | min | max | default |
|---|---|---|---|
milliseconds | 1 ms | undefined | undefined |
ble_scanner
The ble_scanner is a data acquisition module which listen to advertisements sent by BLE (Bluetooth Low Energy) devices.
alive_timeout
Mandatory parameter with the amount of time in seconds that a BLE device should be kept in memory and marked as alive (or in the neighborhood).
| unit | min | max | default |
|---|---|---|---|
| seconds | 1s | undefined | undefined |
AP (wifi) scanner
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 |
PLC engine interface
poll_interval
If not configured, the default is taken.
| unit | min | max | default |
|---|---|---|---|
milliseconds | 50 ms | undefined | 1000 ms |
In difference to the other DA modules the poll_interval is configured for the complete module but not separated in the sensor gateways.
Modules with scheduled polling
The
...
modules, listed in this section use a configuration schema to control the scheduling, which is defined in the XML schema definition (XSD).
...
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. |
...
|
| 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. |
retry_algorithm
is a value of following enumeration
| retry algorithm | description |
|---|---|
| linear | linear timing steps |
| binary_exp | binary exponential timing steps, like the following set: 1,2,4,8,16,32,64,... |
| Warning |
|---|
Only the linear retry algorithm (which is the default) is used for now. As linear is the default, there is no need to put it to the configuration. |
da_rest_client, da_icmp, snmpgetd
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 |
retry_interval_before_alert
time for which a query could be retried, after that an error is reported and it need to wait for the next query cycle.
| unit | min | max | default | remark |
|---|---|---|---|---|
milliseconds | 1000 ms 1 | undefined | undefined | rounded to seconds |
fixed_timeout
timeout for each query try
| unit | min | max | default | remark |
|---|---|---|---|---|
milliseconds | 1000 ms 1 | undefined | undefined | rounded to seconds |
1 It is possible to configure a minimum value >= 0 milliseconds. This misconfiguration is intercepted by the DA modules.
These three DA modules essentially calculate
and perform the query up to trials times until they either get the result or specify the error of the query. This is done each polling_interval cycle.
Example
The following configuration example for the scheduling configuration
| Code Block | ||
|---|---|---|
| ||
...
<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>
... |
means: All 15 seconds the module tries 3 times to do the query. Each trial is limited to 3 seconds.
modbusd
The DA module modbusd uses the parameters
- polling_interval
- retry_interval_before_alert
fixed_timeout
with the same resolution (rounded to seconds) and limitations as in the tables above in this section. Usually the modbusd is configured with a polling_interval only. The difference to the other three DA modules of this section is the error handling, if configured. In case of a failed primary query in the polling_interval query cycle the modbusd continues to poll with the retry_polling_interval until the retry_interval_before_alert is reached.
Configuration of the data export to the cloud
| Include Page | ||||
|---|---|---|---|---|
|
Example
TODO add heartbeat mode example.