Problem: TRB141 transmit current input value via MQTT

[s.heinrich]

Hello,

I’m currently working on a project where I want to transmit the measured value of a flow measurement (4-20 mA) via MQTT. For this, we’re using a TRB141 (FW 7.17.3). I’m using the integrated analog input and the MQTT Publisher. I’ve now encountered the following problem:

If I set the analog input to voltage via the web interface, the applied voltage is transmitted correctly via MQTT. If I use the input as a current input, a 2 is transmitted for a 4 mA signal, and a 3.25 for 20 mA. There seems to be a problem with the scaling. The current is always displayed correctly in the web interface.

It would also be useful if the value of the analog input could be transmitted not only via the Publisher but also via “Data to Server.” Here, the analog input can be queried, but only the configuration, not the current value.

[anon65719490]

Hello,

To better understand the issue, could you please share how you are currently reading the analog input (ACL) value and sending it to the MQTT broker? Are you using a custom script for this process?

Additionally, could you confirm if the current value is displayed correctly when running the following command on the device:

ubus call ioman.acl.acl0 status

As an alternative approach, this measurement can also be read with a Modbus client (TRB set as Modbus server) from Modbus start register 347 (register count: 2) with a 32-bit float type. You could then send it via Data to Server by selecting the data input type as Modbus.

Any further clarification or details about your current configuration would be highly appreciated.

Best regards,

[s.heinrich]

Hello,

I’m using the MQTT publisher as described in the configuration example Monitoring via MQTT - Teltonika Networks Wiki

I am sending requests to the topic prefix/get "analog”.

The TRB responds with prefix/analog “value”

This works perfectly as long as the analog input is used as a voltage input.

The error described occurs when using as current input.

I’ll test the alternative approaches as a quick fix.

Best regards

[s.heinrich]

Hello,

This is the output of “ubus call ioman.acl.acl0 status”:

{ "state": "active", "value": 20.041700, "cached_value": false, "custom_value": 20.041700, "current": "20.0", "percent": "100.0", "custom_name": "Flow", "custom_unit": "mA", "custom_mul": "1", "custom_off": "0", "custom_add": "0", "custom_div": "1" }

The solution with the Modbus server works perfectly. I will use it that way. Thank you very much!

However, reading the analog value via your MQTT publisher seems to be faulty.

Best regards Stefan

[anon65719490]

Hello Stefan,

Thank you for your update.

It seems that the current value shown from the ubus call output seems to be the correct one (20 mA), right?

Nevertheless, thank you as well for pointing out the issue with reading the value via the MQTT publisher, I’ll keep this in mind to forward it to programmers.

If you don’t have any further questions or need additional assistance, can we consider this thread as solved?

Best regards,

[anon65719490]

Update:

I’ve tested this analog input setup on my side, and it seems that the analog current value cannot be published via MQTT because there is no dedicated parameter for analog current. In your case, when the input was set as current, the values transmitted over MQTT were actually for voltage rather than current.

In short, you can’t directly read analog current values using the monitoring via MQTT as in the example. As mentioned earlier, the correct approach is to read the current via Modbus and publish it using Data to Server, or a more advanced and complex approach could be through the custom script using the mentioned ubus call method, then saving the current “value” parameter into some variable and publishing it to your MQTT broker using the openwrt mosquitto-client-ssl package.

Best regards,

[s.heinrich]

Hello,

Thank you for your help so far. The solution with the Modbus server works. However, we’ve noticed during operation that the current input is only very roughly resolved. While the value is displayed in the web interface with two decimal places, the Modbus server rounds it to one decimal place. This means that the current value is transmitted very imprecisely when using the Modbus server. I think this should be adjusted in future firmware versions.

Best regards