Hi,
my solar inverter provides several status flags that are combined to one 16 bit register.
With a windows based software I can read this register by using “Read Holding Registers”.
So I was thinking of using the following line to read the first status bit:
holding_registers = [
{ name = "State 1: standby", byte_order = "AB", data_type = "BIT", bit = 0, address = [32000] },
...
]
But when adding this line to the telegraf config, telegraf isn’t starting any more.
Even when debugging is set to true in the config file from the log file and from systemctl status telegraf I don’t get any idea what could be wrong on this line. On the web I also cannot find any example.
Does someone has experiences by reading bits from a device using modbus and can tell me what I’m doing wrong?
In addition: is there any source I can get additional debug information when telegraf isn’t starting?
@mattb as a general note, please provide error messages, your (redacted) config and the telegraf version you are using if possible. It’s hard for me and others to guess where the issue is with “with my config telegraf doesn’t start anymore” information only…
To the matter. Which version of Telegraf are you using? This feature was not released yet and is scheduled for v1.32.0 (due on Monday September 9th). So you have to use a nightly build to use the BIT datatype!
In addition: is there any source I can get additional debug information when telegraf isn’t starting?
If I try out new stuff and change my configuration I usually start Telegraf “by hand” in a console (ideally as the same user as systemd would start it) with all or a subset of configs. I usually run
telegraf --config ... --debug --test
as this will enable debugging and print all information including the produced metrics to the console after running all plugins once. There is the exception of non-triggered service plugins (e.g. MQTT) where this doesn’t work as the metrics are produced in an event-driven fashion. Another advantage is that metrics are not sent to any output, so you can test without messing up you production data. Usually that’s a good habit to verify your configuration is doing what you expect before breaking production.
