Acquire heterogeneous data with telegraf via TCP

Hi all,

I have a device that sends a heterogeneous byte stream over TCP.
The goal is to write these data in the right format into influxDB.

The data I receive is in the following format:

Byte length Type
0 1 UINT8
1 1 char
2 1 char
3 1 char
4 1 char
5 1 char
6 1 char
7 1 char
8 1 char
9 1 char
10 1 char
11 1 char
12 1 char
13 1 char
14 1 char
15 1 char
16 1 UINT8
17 2 INT16
19 2 INT16
21 2 UINT16(16 boolean values)
23 1 char
24 1 char
25 1 char
26 1 UINT8(8 boolean values)
27 1 UINT8(8 boolean values)
28 4 UINT32
32 4 UINT32
36 4 UINT32

I’m trying to use the plugin socket_listener but I can’t figure out which format is suitable for my case

Is it possible to read these different data directly with telegraf? or is it better to create an interface software?
I ask so as to be directed in the right way.

If you send the data via UDP, you might directly use the binary parser to dissect the data. The `binary
parser is only available in master and nightly builds but is not yet released IIRC.
If you are not using UDP and your message isn’t terminated by a newline, you additionally need to use a binary found in PR #12187, Let me know if you have any issues!

Hi Srebhan,
Please excuse the delay, I noticed that binary parser is released now.

What Filename I should use if the data come to me via TCP?

@ATeam if data is sent via TCP you need to use the socket_listener input plugin to create a TCP server on Telegraf side.

It’s lack of good example and document, it’s go this way. Any complete example appeared in the document would be great help for who is new to influxdb.

service_address = “tcp://:2020”
splitting_strategy = “newline”
data_format = “binary”
endianess = “be”

metric_name = “some name as measurement”

entries = [
  { bits = 32, omit = true },
  { name = "VoltageA", type = "uint16" },
   selection = [{ offset = 0, bits = 8, match = "0xA2" }]

I believe @srebhan was involved heavily on the binary parser. and kudos to him.

but I do agree that the examples and documentation were hard to digest regardless of that it’s a very nice feature.

@DanielX and @fercasjr it’s usually hard to write good documentation if you wrote the code. Please open a PR and extend the documentation. Also feel free to add new examples, best would be as test-cases so we also increase code coverage…