Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added and explained an example configuration


Section


Column
width400px

Introduction

This page will go into the technical depths about the timing of data acquisition in general.Some abbreviations will be used for the sake of simplicity.

DA = Data Acquisition

Publish strategy

Include Page
Publish Strategy
Publish Strategy

Passive modules without polling and timeout

These modules are not polling and are also not waiting up to a timeout time. They just listen and forward a result, when present.

DA moduledescription
trapdSNMP trap daemon
gps_tcp_clientlisten to GPS NMEA packet received from a TCP connection
gps_serial_clientlisten to GPS NMEA packet received from a serial port



Column
width400px


Panel
borderColorlightgrey
bgColor#f0f0f0
titleOn this page:

Table of Contents



...

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.

unitminmaxdefault

milliseconds

1000 msundefined

undefined

timeout

Mandatory parameter which defines the maximum amount of time that the scan is allowed to run, in milliseconds.

unitminmaxdefault

milliseconds

1000 msundefinedundefined

...

Include Page
Upload Strategy
Upload Strategy

Example

Code Block
languagebash
titleExample snippet of the SiteController.cfg
collapsetrue
[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
languagexml
titleExample

...

component template for polling and upload configuration
collapsetrue
<?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.

Image Added

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.

Image Added