Question

Problem: Reading data from a external Modbus slave, publish it as topic on the MQTT broker and subscribing on that topic.

This is kind of bread and butter of the RUT956, however I can not get this working. I have checked the forums, the tutorials, documentation, used different tools, external brokers - it's just seems impossible.

Setup: 

1. External Modbus TCP slave --> "Modus TCP Master" --> "Data to Server" --> "MQTT Broker" --> External client
2. Modus TCP Master: slave id = 1
3. Data to Server: protocol = MQTT, url = 127.0.0.1, filter = slave id 1, topic = "voltair"
4. MQTT Broker: topic = "voltair"
5. External client: topic = "voltair" 

Verified: 

1. Modbus TCP Master can read all the 20 registers of the slave.
2. I can connect to the broker from external tools, however not see or subscribe to the topic "voltair".
3. I can connect to the broker from external tools and see the topic "$SYS/#" - it works and updates every 10 s.

What can I have missed? Images attached.

Answer 1

Hello,

I was able to recreate this setup, and here are the instructions on how to accomplish this:

• Modbus configuration
  • In WebUI, navigate to Services → Modbus → Modbus TCP Master (if using Modbus RTU, the correct menu will be Modbus Serial Master). From here, configure the connected slave device with the following parameters:
    • Enable the slave device;
    • Slave ID must be the same as on the connected Modbus device;
    • IP address is the IP address of the connected slave device;
    • Port - TCP/IP port used on the slave device. The default is 502;
    • Period - the amount of time (in seconds) how often the requests should be sent to the slave;
    • Timeout - the amount of time to listen for the response before timing out.
  • Requests configuration will define what data will be pulled from the slave device:
    • Data type - the data type of the incoming data. It should either be customizable or pre-determined in the slave device configuration. The user manual of the slave device will help here;
    • Function - usually, the Read holding registers (3) is used, but this is entirely dependent on the slave device.
    • First register number will be the how far from the start of the register the data should start to be collected. This is once again defined by the slave device. However, sometimes +1 has to be added to the number to receive the correct data;
    • Register count/values specify how many registers should be read from the specified first register. This will not prevent data from being outputted, however, it might distort it if too much or not enough data is requested;
    • Brackets - if the program you'll be parsing the data on does not need brackets, the appropriate option can be selected;
    • And finally, enable the instance.
  • Scroll down a little more, and there will be a Request Configuration Testing tab. Here we can test if data is being requested correctly.
• After configuring Modbus, we can navigate to Data to Server configuration, found in the same Services tab. From here, the configuration will be as follows:
  • Create a new instance;
  • Enable it;
  • Data source: MODBUS data;
  • Protocol: MQTT;
  • JSON format: specify the desired data and its format. This is how the MQTT message will look like;
  • Segment count: the maximum amount of segments in one JSON string to the server;
  • Send as object: select this is your MQTT subscriber needs this;
  • URL / Host / Connection string: address of the MQTT broker. If your RUT device will act as a broker, 127.0.0.1 should be used;
  • Port: port number used by the broker;
  • Keep alive: can be left on the default values if not specifically needed;
  • Topic: The topic, that the publisher will publish on. Can be multiple layers deep (e.g. RUTX10/Modbus_device/sent_data)
  • Client ID: should be left blank. That way the router/gateway will autogenerate a random client ID.
  • Period: How often the data should be sent;
  • Data filtering: From which device the data should be sent.
• The only thing left is to configure the MQTT broker:
  • Navigate to Services → MQTT → Broker;
  • Enable the broker instance;
  • Specify the local port (or leave it on default values);
  • And enable remote access if it will be needed;
  • Bridge and its topics configuration are not needed if brokers are not going to be bridged!

And that should be it for the configuration side of things. Please keep in mind, that for the broker to be accessible from the internet, the router/gateway needs to have an external IP address!
I wrote the instructions for anyone who might encounter the same problem, but in your setup, I believe the set topic is what is causing the issues. Try removing it and seeing if that helps. In case it does not help, please try the Data to Server feature with an external broker. Flespi (encrypted, but more time to set up) or HiveMQ (unencrypted, but quicker to set up) are both great services. If RUT956 can publish to these external brokers just fine, then the problem is most likely on the MQTT broker side of things. Make sure that public IP is available and the port is not used by any other rule.  

Let me know if this helps!  

Best regards,  

DaumantasG  

Comments

Hi again,

Sorry to say, I still have the same issues and have tried a lot of things. The setup was - and is - identical to your description.

I suspect it is the Data To Server that is not working, because I can connect to the local broker from external clients and get the $SYS topic update each 10 s. Data to Server to external brokers don't seem to be working either.

I was about to try to use CLI and try mosquitto sub/pub but was kicked out, this goes for telnet and ssh as well.

---

Hi again,

Sorry to say, I still have the same issues and have tried a lot of things. The setup was - and is - identical to your description.

I suspect it is the Data To Server that is not working, because I can connect to the local broker from external clients and get the mosquitto $SYS topic update each 10 s. Data to Server to external brokers don't seem to be working either.

I was about to try to use CLI and try mosquitto sub/pub but was kicked out, this goes for telnet and ssh as well. Another wall!

Kind regards,
Björn

---

Hello,

I'm sorry to hear that you're still having issues!

If you believe, that the problem is in Data to Server service, then there are a few options to try:

• Don't leave the data field empty. You might have already changed it, but in your Troubleshoot file, I can see that the JSON string is not specified. you could put something like Date (Linux timestamp) - %t; Date (binary Linux timestamp, UINT32BE) - %T just to use for mock data.
• Set Data filtering to All data

If these options don't help, I suggest doing a factory reset and trying the configuration again, as this could be caused by a config file, that was corrupted during the update.

Regarding the CLI, how long were you connected before you were kicked out? Also, were you connecting from LAN or WAN?

Awaiting your response.

Best regards,

Daumantas G.

---

Hi Daumantas!

Finally - it works! It was just that tiny thing with an empty data field in the Data to Server. The placeholder text did fool me, it looked like a default text.

So many thanks! :-)

From WAN (LTE). CLI kicks right away. After sucessful login it immediatly disconnects "Session closed". Maybe no shell? I will try later to fiddle some more with Access Control , also try from WiFi.

Kind regards,
Björn

---

Hello,

Glad to hear that it's working!

Regarding CLI from WAN, this is the default behavior due to security reasons. It can be enabled by navigating to System -> Administration -> Access Control and enabling remote access for wanted protocol.

However as this is a security risk, I'd recomment at least using non-standard port. Ports can be changed in the same menu.

Best regards,

DaumantasG

Answer 2

Hello,

Thank you for reaching out!

Would you mind attaching the Troubleshoot file? It can be generated by navigating to System -> Administration -> Troubleshoot. It will only be visible to Teltonika moderators.

As for some notes:

• In Data to Server configuration, Client ID should be left blank if not necessary. In this example it might not help, but when connecting to a third-party broker, all clients must have unique IDs. When left blank, randomly generated client ID will be used, which greatly minimizes the chance for any collisions. Same goes for an external MQTT tools used.

Once I receive the Troubleshoot file, I'll be able to test out your setup and will let you know where the problem may lies.

Best regards,

DaumantasG

Comments

Hi! Thanks for quick response! Troubleshoot attached to orig. post.

Best regards,
Björn