influxdata / influxdata/telegraf
MQTT Consumer: Support Reading User-Properties
- Dominant language
- Go
- Stars
- 17.8k
- Forks
- 5.8k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 161
Description
## Feature Request
Opening a feature request kicks off a discussion.
### Proposal:
If the internet connection dies, our device will remember the unsent messages, and when the internet connection comes back send all of them.
Since Telegraf is adding the timestamp, all of those messages would get wrong timestamps once they reach the server.
Instead, we want to use a user-property “time”, which is the time when we measured our actual sensor. Once they reach Telegraf, we want Telegraf to use that timestamp for the InfluxDB insert.
### Current behaviour:
Telegraf does not support reading data from [user-properties ](https://www.hivemq.com/blog/mqtt5-essentials-part6-user-properties/) within a MQTT payload.
### Desired behavior:
Provide the ability to parse user-property data. Similar to how we parse topics.
### Use case:
we want to use a user-property “time”, which is the time when we measured our actual sensor. Once they reach Telegraf, we want Telegraf to use that timestamp for the InfluxDB insert.
The alternative is to use json_v2/timestamp_key. It seems Telegraf is using paho.mqtt.golang, there is this fork which supports mqtt 5, but it seems to be a bit different [GitHub - eclipse/paho.golang: Go libraries](https://github.com/eclipse/paho.golang), for example there is no ClientOptions. Therefore it is not a drop-in replacement.
Community link: https://community.influxdata.com/t/handling-mqtt-5-properties-in-telegraf/25255/2
Contributor guide
Research direction
Start with Telegraf's MQTT consumer and its use of paho.mqtt.golang, then compare how topic data is currently parsed. Define completion as exposing MQTT user-property data, including the proposed “time” property, so it can be used as the timestamp for InfluxDB inserts; review the existing MQTT-related tests if available.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- data
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100