Hi,
I’m trying to get going with the MQTT modbus gateway. I’m struggling to understand how to do it. I set up the gateway as follows:
And I send this command
I’m not sure I have understood how the request and respond topic works. I get no response on the response topic “gassieResponse”
/Tim
Good afternoon,
After looking into your configuration, here are a few observations :
Port 8883 is typically used for MQTT over TLS/SSL, but you have TLS/SSL set to off.
If your broker requires TLS, turn Use TLS/SSL on.
If your broker does not require TLS, try using port 1883 instead.
Ensure your MQTT client is publishing requests to gassieAck and subscribed to gassieResponse.
Topic names are case-sensitive.
The gateway expects a specific ASCII payload format for Modbus requests.
Example format:
<server_id> <count/values>
Example: `123456789 192.168.1.10 502 1 3 0 2
If the payload is not correctly formatted, the gateway will not respond.
Ensure the Modbus TCP server is reachable and responding to requests from the gateway.
Regards,
Arturas
Hi,
I use the Modbus TCP client and data to server and all this is working with no issues. It could be the MQTT server set up since it is diffrent from the one in data to server that looks like this:
From the manual it states:
0 COOKIE IP_TYPE IP PORT TIMEOUT SERVER_ID MODBUS_FUNCTION FIRST_REGISTER REGISTER_COUNT/VALUES
I write
0 1 0 192.168.1.3 502 5 1 3 6 1
I suspect there is something wrong with connection to broker or the MQTT string I send.
If you look at the configuration at both data to server and the modbus mqtt gateway settings for the broker. Does it seem to match?
Hi there,
Some observations from your provided setup :
Client IDs must be unique per MQTT connection. If both services run on the same device and connect to the same broker, this is correct. If not, using the same Client ID on two connections will cause one to disconnect.
Keepalive - This is not critical, but for consistency, you may want to use the same keepalive value, unless you have a specific reason.
QoS can differ depending on your reliability needs. Just ensure your broker and client handle the chosen QoS levels.
This is expected if the two services are publishing/subscribing to different topics. Just ensure your application logic matches these topic names.
Port 8883 is almost always for encrypted (TLS/SSL) connections. If your broker enforces TLS/SSL on port 8883, you must enable TLS/SSL in both configurations.
If you want to use unencrypted connections, use port 1883 instead.
The rest of the settings seem to be correct.
Regards,
Thanks, I tried it with the test.mosquitto.org over 1883 and it works so it must be the MQTT connection.
The setup of data to server is diffrent from this the MQTT modbus gateway. On the “data to server” I use the “use credentials” to supply a Username and password and this works fine over 8883.
Mqtt modbus gateway use a diffrent setup requiring certificates when using TLS but HiveMQ seem to use TLS with username and password only over 8883
I think that the mqtt modbus gateway has diffrent approach on connecting to the broker, why is this?
I’m using HiveMq and it provides the connection below and also the use of Username and password.
Any comment regarding:
Why is this? Something you plan on adding/changing?
/Tim
Hi there,
Data to Server
Uses a simpler MQTT client approach that supports username and password authentication over TLS (port 8883) without requiring client certificates.
This method is more straightforward and works with brokers like HiveMQ that allow username/password authentication over TLS without client certificates.
It is designed for pushing Modbus data to an MQTT broker in a relatively simple manner and supports basic MQTT security features like username/password and TLS encryption.
MQTT Modbus Gateway
Uses a more advanced MQTT client implementation that requires client certificates when TLS is enabled.
This setup is more secure and typical for scenarios where mutual TLS authentication is enforced by the MQTT broker.
The gateway expects certificates for TLS connections, which is why it differs from the “Data to Server” approach that does not require certificates.
This difference is because the MQTT Modbus Gateway is designed to act as a bridge translating Modbus TCP data into MQTT messages with more control over security and MQTT features.
Why the difference?
The two features serve different purposes and have different MQTT client implementations, leading to differences in how they handle authentication and encryption.
“Data to Server” is optimized for ease of use and compatibility with brokers like HiveMQ that support username/password over TLS.
“MQTT Modbus Gateway” aims for higher security with certificate-based TLS, suitable for brokers enforcing mutual TLS authentication.
Adittional observations :
Client IDs must be unique per MQTT connection to avoid disconnects.
Port 8883 is typically for TLS-encrypted MQTT connections; if your broker enforces TLS, certificates may be required depending on the client implementation.
Using port 1883 is for unencrypted connections, which worked in your test with test.mosquitto.org
Regards,
