Adding Metadata within MQTT client in order to be available for querying in InfluxDB

Question

Scenario

I wish to deploy sensor nodes that publish sensor data to a central MQTT Broker and then send this information to InfluxDB.

Requirements

Adding metadata to the Sensor nodes whilst publishing information to the broker. This requirement comes in lieu as the sensor nodes will be deployed in specific rooms and these information needs to be saved in the InfluxDB as tags which can help me for post processing. Scenario simplified as below.

Metadata

Example:

 measurement: sensors
 type: temperature, humidity
 location: GATEA

This metadata can be used as a query as follows:

  SELECT * FROM "sensors" WHERE "type"='humidity' AND "location"='GATEA' LIMIT 100

The above mentioned query provides me all humidity sensor values coming from GateA.

Question

How does one add such metadata when publishing information with standard MQTT?

Initial Understanding suggests:

I make topics based on Gates where each sensor nodes publish information to specific gate topic like GATEA, GATEB etc. I am not sure if this makes sense as then the InfluxDB might take the topic as a measurement and the query might look like:
```
   SELECT * FROM "GATEA" LIMIT 100
```
however this does not address the type tag that could be pushed as metadata.
Vice versa would be topic creation based on type of sensors e.g. temp, humidity for each sensor nodes

Is there any standard practice or architecture design advice for MQTT deployment in such scenarios? Or any advice as to what path should be selected in the context of this scenario?

References

MQTT, Docker, Grafana, InfluxDB, ESP32 Blog Post is a great blog post which I would like to start as a base point for such a setup

hardillb · Answer 1 · 2018-11-24T11:15:55.867

With MQTT version 3.x there is nowhere to include any meta data except in the message payload it's self. This means the sensors will need to build this in before they publish the message.

You can encode some information in the topic and this makes sense for certain things, e.g. having each sensor publish on their own topic and subscribe to wild cards. Topics are hierarchical for this reason e.g.

country/city/building/floor/sensor1/temperature
country/city/building/floor/sensor1/humidity

MQTT v5 (the new version of the spec 2017/18) spec supports user properties for each message as well as the payload which will probably be useful for including extra meta data as more things come to support it.