inputs.modbus support string holding registers

[tacuna]

Feature Request

Support reading (fixed size) strings from holding registers.

The documentation states:

The field data_type defines the representation of the data value on input from the modbus registers. The input values are then converted from the given data_type to a type that is apropriate when sending the value to the output plugin. These output types are usually one of string, integer or floating-point-number. The size of the output type is assumed to be large enough for all supported input types. The mapping from the input type to the output type is fixed and cannot be configured.

However string does not seem to be accepted, or at least i did not manage to get it to work. If this is possible this issue should be converted to a "documentation clarification/bug" issue instead.

Proposal:

Add support for data_type = "string"

Current behavior:

There is no way to read strings without custom post-processing?

Desired behavior:

Be able to read (fixed size) string holding registers out of the box.

Use case:

The device i'm reading out has string data in its holding registers.

[steynovich]

@tacuna have you been able to implement a workaround in the meanwhile? If so, are you willing to share it here? Might be helpful :) Much appreciated

[roykrikke]

@tacuna tacuna) I'm interested as well like @steynovich already asked you.

[tacuna]

Unfortunately i have not. I was lucky enough that the string field is not mandatory information for my use-case thus simply do not read it out for the time being.

[KE-PaulBright]

A bit late to the party but a +1 for me

[srebhan]

Can you please test the binary in PR #14145 available once CI finished the tests successfully!? Let me know if this fixes the issue!

[KE-PaulBright]

Firstly, thank you so much for this. This is going to be a game changer for us in terms of device monitoring.

Haven't had a lot of time to play with this, but at first glance I'm having a slight issue when polling an M580 Schneider PLC.

The byte order does not seem to apply to the string, I tried them all. Might be something I'm doing wrong.

This is a development instance of influx running in parallel to the production instance on a Wastewater Treatment works plant.

Here's the telegraf:

[[inputs.modbus]]
   name = "casa"
   timeout = "1s"
   interval = "10s"
   controller = "tcp://192.168.100.180:502"
   transmission_mode = "auto"
   debug_connection = true
   configuration_type = "request"

   [[inputs.modbus.request]]
   byte_order = "CDAB"
   slave_id = 1
   register = "holding"
   measurement = "casa_Aerobic"

   fields = [
     { address=2540, 	name="XZVT_45_AE_107_HZ",     	type="FLOAT32"},
     { address=2530, 	name="XZVT_45_AE_107_VFLT",     type="STRING",	length=8 },
     { address=2544, 	name="XZVT_45_AE_107_VER",	type="STRING",	length=8 },

   ]

Here's the debug stream:

2023-10-23T09:20:40Z D! [inputs.modbus] trying to read holding@2530[8]...
2023-10-23T09:20:40Z D! [inputs.modbus] modbus: send 00 01 00 00 00 06 01 03 09 e2 00 08
2023-10-23T09:20:40Z D! [inputs.modbus] modbus: recv 00 01 00 00 00 13 01 03 10 6f 4e 46 20 75 61 74 6c 00 00 00 00 00 00 00 00
2023-10-23T09:20:40Z D! [inputs.modbus] got holding@2530[8]: [111 78 70 32 117 97 116 108 0 0 0 0 0 0 0 0]
2023-10-23T09:20:40Z D! [inputs.modbus]   field XZVT_45_AE_107_VFLT with offset 0 with len 16: [111 78 70 32 117 97 116 108 0 0 0 0 0 0 0 0] --> oNF uatl

PLC currently showing "No Fault" for those registers, and you can see the bytes are all swapped form the result "oNF uatl".
Most of the SCADA systems we use will have an option to "reverse order on strings" which swaps the high and the low byte. This could be easily rectified with a modern day SCADA such as ignition, but we favor using influx as our single source of truth on the plants we commission so would be awesome if we could do it on ingest from our data producers (PLC's) and avoid any extra steps.

Thanks again

[srebhan]

@KE-PaulBright first of all thank you for testing and thank you for reporting the, otherwise unnoticed, issue! I pushed a potential fix to PR #14145. Can you test once CI finished the tests!?!

[srebhan]

@KE-PaulBright any chance you can give the PR a test with your device?

[KE-PaulBright]

Sorry about the delay in getting back to you.

Initial tests are positive,

Getting "No Fault" & "KE MVI 1.0" as expected now when I swap the byte order. Will leave it running, add some more registers and report back after some more testing. Only Caveat is the Float value is now reversed as I can't specify the byte order per item in Modbus request as far as I know. Could create another request for strings only, but it would be awesome if there was a reverse word order option for strings that could be configured somewhere to prevent a clumsy conf. We already have two requests per PLC on the plant, one for high resolution metrics like levels, flows, frequencies, etc and one for low resolution metrics like flow totalizers, motor run hours, etc. That is obviously all a "nice to have" and this is already a huge leap forward for me. Thanks again for all your effort!

2023-11-07T05:48:54Z I! [inputs.modbus] Got 0 request(s) touching 0 inputs registers for 0 fields (slave 1)
2023-11-07T05:48:54Z I! [inputs.modbus] Got 0 request(s) touching 0 discrete registers for 0 fields (slave 1)
2023-11-07T05:48:54Z I! [inputs.modbus] Got 0 request(s) touching 0 coil registers for 0 fields (slave 1)
2023-11-07T05:48:54Z D! [agent] Connecting outputs
2023-11-07T05:48:54Z D! [agent] Attempting connection to [outputs.influxdb_v2]
2023-11-07T05:48:54Z D! [agent] Successfully connected to outputs.influxdb_v2
2023-11-07T05:48:54Z D! [agent] Starting service inputs
2023-11-07T05:49:00Z D! [inputs.modbus] Reading slave 1 for tcp://192.168.100.180:502...
2023-11-07T05:49:00Z D! [inputs.modbus] trying to read holding@2530[8]...
2023-11-07T05:49:00Z D! [inputs.modbus] modbus: send 00 01 00 00 00 06 01 03 09 e2 00 08
2023-11-07T05:49:00Z D! [inputs.modbus] modbus: recv 00 01 00 00 00 13 01 03 10 6f 4e 46 20 75 61 74 6c 00 00 00 00 00 00 00 00
2023-11-07T05:49:00Z D! [inputs.modbus] got holding@2530[8]: [111 78 70 32 117 97 116 108 0 0 0 0 0 0 0 0]
2023-11-07T05:49:00Z D! [inputs.modbus]   field XZVT_45_AE_107_VFLT with offset 0 with len 16: [111 78 70 32 117 97 116 108 0 0 0 0 0 0 0 0] --> No Fault
2023-11-07T05:49:00Z D! [inputs.modbus] trying to read holding@2540[2]...
2023-11-07T05:49:00Z D! [inputs.modbus] modbus: send 00 02 00 00 00 06 01 03 09 ec 00 02
2023-11-07T05:49:00Z D! [inputs.modbus] modbus: recv 00 02 00 00 00 07 01 03 04 00 00 42 34
2023-11-07T05:49:00Z D! [inputs.modbus] got holding@2540[2]: [0 0 66 52]
2023-11-07T05:49:00Z D! [inputs.modbus]   field XZVT_45_AE_107_HZ with offset 0 with len 4: [0 0 66 52] --> 1.8746570855737403e-41
2023-11-07T05:49:00Z D! [inputs.modbus] trying to read holding@2544[8]...
2023-11-07T05:49:00Z D! [inputs.modbus] modbus: send 00 03 00 00 00 06 01 03 09 f0 00 08
2023-11-07T05:49:00Z D! [inputs.modbus] modbus: recv 00 03 00 00 00 13 01 03 10 45 4b 4d 20 49 56 31 20 30 2e 00 00 00 00 00 00
2023-11-07T05:49:00Z D! [inputs.modbus] got holding@2544[8]: [69 75 77 32 73 86 49 32 48 46 0 0 0 0 0 0]
2023-11-07T05:49:00Z D! [inputs.modbus]   field XZVT_45_AE_107_VER with offset 0 with len 16: [69 75 77 32 73 86 49 32 48 46 0 0 0 0 0 0] --> KE MVI 1.0```

[srebhan]

@KE-PaulBright thanks for testing! Just as a hint, the length setting is in registers, i.e. 16-bit. So if your text has 8 characters the length needs to be set to 4.

[KE-PaulBright]

@KE-PaulBright thanks for testing! Just as a hint, the length setting is in registers, i.e. 16-bit. So if your text has 8 characters the length needs to be set to 4.

Thanks, I figured. We standardised on 8 registers for all strings on our PLC DFB's.