The core of each data acquisition application is its configuration object.
This configuration snippet will create an
application object defined as
; ----------------------------- ; Data acquisition through MQTT ; ----------------------------- [amazonas] enable = true type = application realm = amazonas mqtt_topics = amazonas/# application = kotori.daq.application.mqttkit:mqttkit_application
This essentially spawns an application on the realm
The realm – here called
amazonas– designates the “tenant” or “vendor” by means of a multi-tenant system.
Kotori will subscribe to the MQTT topic
amazonas/#to receive all readings published to that topic.
When data is received, the data payload will be evaluated through the machinery defined through the software component
kotori.daq.application.mqttkit. This component is assembled from several baseline software components from the toolbox of Kotori.
Kotori will also signal Grafana in order to create some instant dashboards reflecting the telemetry fields of the measurement data just ingested.
One of the convention of the MQTTKit communication flavor is that is uses several MQTT topic segments implementing the »quadruple hierarchy strategy« in a wide-network addressing scheme like outlined within the MQTTKit addressing scheme:
realm / network / gateway / node
The main workhorse here is definitively MqttInfluxGrafanaService, which is spun up through mqttkit.py, essentially tying all things together.
The addressing scheme is implemented through the WanBusStrategy component used within MqttInfluxGrafanaService. It will take the responsibility of properly receiving and decoding message payloads arriving on the MQTT bus according to the specific conventions implemented in there.