How it works
Sensorconnect continuosly scans the given IP range for gateways, making it effectively a plug-and-play solution. Once a gateway is found, it automatically download the IODD files for the connected sensors and starts reading the data at the configured interval. Then it processes the data and sends it to the MQTT or Kafka broker, to be consumed by other microservices.
If you want to learn more about how to use sensors in your asstes, check out the retrofitting section of the UMH Learn website.
The IODD files are used to describe the sensors connected to the gateway. They
contain information about the data type, the unit of measurement, the minimum and
maximum values, etc. The IODD files are downloaded automatically from
IODDFinder once a sensor is found, and are
stored in a Persistent Volume. If downloading from internet is not possible,
for example in a closed network, you can download the IODD files manually and
store them in the folder specified by the
IODD_FILE_PATH environment variable.
If no IODD file is found for a sensor, the data will not be processed, but sent to the broker as-is.
You can configure the IP range to scan for gateways, and which message broker to use, by setting the values of the parameters in the _000_commonConfig.datasources.sensorconnect section of the Helm chart values file.
The default values of the other parameters are usually good for most use cases, but you can change them in the Danger Zone section of the Helm chart values file.
|Additional sleep time between pollings for each active port
|JSON map of values, allows to slow down and speed up the polling time of specific sensors
|Enables the use of the fgtrace library. Not reccomended for production
|HTTP timeout in seconds for finding new devices
|Time interval in seconds for finding new devices
|Filesystem path where to store IODD files
|Any valid Unix path
|The IP range to scan for new sensor
|Any valid IP in CIDR notation
|URL of the Kafka broker. Port is required
|The encrypted password of the SSL key. If empty, no password is used
|Defines which logging level is used, mostly relevant for developers
|Time in milliseconds to define the lower bound of time between sensor polling
|Amount of errors before a sensor is temporarily disabled
|Name of the microservice (used for tracing)
|URL of the MQTT broker. Port is required
|Set to NO_CERT to allow non-encrypted MQTT access, or to USE_TLS to use TLS encryption
|Password for the MQTT broker
|Time in milliseconds subtracted from the polling interval after a successful polling
|Time in milliseconds added to the polling interval after a failed polling
|Amount of time in milliseconds before starting to request sensor data. Must be higher than
|Set to 1 to allow
LOWER_POLLING_TIME_MS of under 20 ms. This is not recommended as it might lead to the gateway becoming unresponsive until a manual reboot
|If enabled, the microservice will use a test IODD file from the filesystem to use with a mocked sensor. Only useful for development.
|Serial number of the cluster (used for tracing)
|Time in milliseconds to define the upper bound of time between sensor polling
|If enabled, uses Kafka as a message broker
|If enabled, uses MQTT as a message broker
ADDITIONAL_SLOWDOWN_MAP environment variable allows you to slow down and
speed up the polling time of specific sensors. It is a JSON array of values, with
the following structure: