Telegraf scale processor

Hi to All,
I’m studying the telegraf documentation to look if it’s the right choice in my case:
I need to collect some data from a ModBus TCP device. I’ve found an input plugin for telegraf that is in development that can import those data, but I haven’t found a way to scale/adapt it, something like a processor that can accept math formulas.
For example I need to convert a temperature read from an 7bit value (0-127) to a 0-100°C value, that is the real temperature that I want to save.
Any way of doing it? There’s any option or plugin for telegraf I’ve missed? Or im case I have to create my own?
Cheers Mix

The plan with the Modbus plugin will be to include some scaling functionality within the plugin itself, using the scale option. If the currently proposed support isn’t enough for your use case, I’d love to hear more about how exactly this conversion is done.

Thanks @daniel for the answer and your work :wink:

Yes, that scale attribute can work for some of my case, but I have some other case that are more complex:
For example I have a temperature sensor that return the measure in 10*K where K in the temperature in Kelvin, and I need to save that in Celsius, so the formula would be something like (IN-2730)*0.1
In this case the 0.1 part can be done with the scale attribute, but I need something like an offset adjust for the read value. (And that would probably be an useful additional parameters, if you would like to include it)

Speaking in general there’s probably some other case that can require a more complex math formula and I think would be great to have a processor that can do that or maybe some approximation.
Thanks again
Cheers Mix

Yeah, I agree that we need a processor for this. We do have an issue open for a math processor, but there are a few other possibilities for how this could be solved: we may introduce an exec processor that can run user scripts, or it could be a job for a flux processor.

Currently though the simplest solution would be to move this operation into the query:

SELECT (temp_kelvin - 2730) * 0.1 FROM mydevice

Thanks @daniel
I’ve found a little bit of time to do some other tests with some live equipment, and I’ve found some other problems that prevent me to have the results I want with telegraf. I would like to share that, because are probably based on a more advanced situation, and solving that permit to adapt the plugin to more systems.

First, about the temperature problem, I know I can elaborate the operation after in the query, but in my case I can’t, because I’m acquiring different type of data from the same device (some are like I said in kelvin, other are already in Celsius but on 7bit), and I need to normalize those data before saving it, so it’s all in the same unit, and to do that I need to elaborate the results with a scale, an offset and sometime some operation on the bit of the word I’m reading.

Using an exec operation could be interesting, but at this point, I would probably write a separate script to do all the work exactly how I want and more efficiently.

Another problem I’ve found with the modbus plugin, that maybe someone can experience is reading a coil status: In the device I use, for some strange reason, I couldn’t request the status of a single output or input module, but I have to request the status of the all outputs of the module with a coil that must have a length of 16 (or multiple) and pick the right bit in the returned word. So for example, if I need the 7th output I have to check the 7th bit in the word.
At the moment I couldn’t do that operation with the plugin, and it will probably require a different approach: the plugin need to aggregate those multi information word, request them to the modbus and then pull out the bits needed in the correct field.
At the moment I could probably require and save the raw word in a field, but then I need a processor that extract those bit.

Finally, I have another problem on the way the plugin work: In my case I have a device that’s a sort of PLC that control an entire building.
The first idea I had in mind was doing a request for the data of every room, and save that with some associated tag, like the room name or code, but with this plugin I can’t, because I have to define and acquire all the data from the same device together.
Here an example of what I would like to do:

name_override = “temperature”
tags = {building = “Build 4”, floor = “PT”, place_name = “Room 1”, place_type = “U”, place_code = “SCTU001”}

slave_id = 4
timeout = “1s”
controller = “tcp://”

discrete_inputs =
coils = [


holding_registers = [{ name = “setpoint”, byte_order = “AB”, data_type = “FLOAT32”, scale=“0.1”, address = [648]}]
input_registers = [{ name = “temperature”, byte_order = “AB”, data_type = “FLOAT32”, scale=“0.1”, address = [136]},]

name_override = “temperature”
tags = {building = “Build 4”, floor = “PT”, place_name = “Room 2”, place_type = “L”, place_code = “SCTL003”}

slave_id = 4
timeout = “1s”
controller = “tcp://”

discrete_inputs =
coils =

holding_registers = [{ name = “setpoint”, byte_order = “AB”, data_type = “FLOAT32”, scale=“0.1”, address = [645]}]
input_registers = [{ name = “temperature”, byte_order = “AB”, data_type = “FLOAT32”, scale=“0.1”, address = [133]},]

I don’t know if it’s a limit of this plugin or of telegram, but would be interesting for some complex devices.
I know that I can fix that using the unpivot processor, but it only does a part of the work (it doesn’t add the tags I want) and it’s inefficient…
To give some numbers, only for the heating system I have a building with about 70 rooms, and for every room I want to acquire the actual temperature (input reg), the setpoint (holding reg), the thermostat request (discrete input) and the scheduler activation (coil). Saving and processing that every time is really inefficient…

To close up, my first intention would like to be to modify the modbus plugin to support those features I need and send a pull request, but I have some doubts, and I want to ask, before start writing some code that would be discarded:

First doubt, would those modifications be accepted? An offset parameter for the numeric type, a cast from a word to a selected bit, an optimization to require the same register once and a way to define a single connection and make many requests on that.

Second doubt, I’ve noticed that the pull request for this plugin is still not accepted… Making other change in this moment have sense?

Third doubt, I have never used Go before… There will be someone that can check the code and see if it’s ok?