Suchen Sie etwas anderes?
The MTX-Tunnel firmware has MQTT support as of version 9.25. It is possible to send data stored in the internal datalogger (LOGGER_mode: mqtt) using MQTT as well as the DNS data (DNS_mode: mqtt). It is also possible to send AT commands (to check modem status, make configuration changes, change relay status, etc.).
The main advantage is that being a standard MQTT protocol you can use a large number of applications that exist for your Android or IOS mobile. All regardless of whether the SIM card used has or does not have a public or private IP address.
Table of Contents
MQTT_enabled
Description: Enables the MQTT service of the MTX-Tunnel. It is imperative to enable it in case you want to use this service for Logger, DNS or AT commands.
Possible values:
- on, off
- Default value: off
MQTT_server
Description: Any MQTT device acting as a “client” must be connected to an MQTT broker. Here you must specify the connection URL or IP as well as the connecting TCP port.
Possible values:
- tcp://xxx.xxx.xxx.xxx:puerto
- Default value: none
Additional notes:
- An example url for an MQTT broker can be tcp: //2.3.4.5: 1883
- On the Internet there are many free and paid MQTT broker services. For example you can test for your tests: tcp://test.mosquitto.org:1883
MQTT_id
Description: Each MQTT device that communicates with an MQTT Broker should have a different identifier. By means of this property it is possible to establish said identifier.
Possible values:
- String up to 32 characters
- Default value: none
Additional notes:
- If you use the same equipment identifier in two devices, the broker will disconnect one of them, because only one unique ID is allowed
MQTT_login
Description: Some MQTT Broker services require that the client device be authenticated using a username and password system. By means of this parameter you can specify, if necessary, the username.
Possible values:
- String up to 32 characters
- Default value: none
Additional notes:
- If your MQTT broker does not specify it, do not use this parameter
MQTT_password
Description: Some MQTT Broker services require that the client device be authenticated using a username and password system. By means of this parameter you can specify, if necessary, the password.
Possible values:
- String up to 32 characters
- Default value: none
Additional notes:
- If your MQTT broker does not specify it, do not use this parameter
MQTT_attopic1, MQTT_attopic2, MQTT_attopic3
Description: With these 3 parameters, you can specify the topics to which the MTX Tunnel will subscribe in order to receive AT commands from an application with MQTT (for example to be able to send AT commands from a mobile phone).
Possible values:
- String up to 64 characters
- Default value: none
Additional notes:
- For example, an appropriate value could be:
MQTT_attopic1: midispositivo/comandosAT/mtx1
This would imply that all the AT commands that you send (for example from a mobile phone) to the topic device/commandAT/mtx1 of the Broker to which the modem is connected will arrive to the MTX-Tunnel and therefore will be executed. - If you include the [IMEI] tag it will be replaced by the actual IMEI of the modem. It will be very useful in the case of having a significant number of MTX-Tunnel devices. For example, you could configure:
MQTT_attopic1: [IMEI]/AT
And the MTX-Tunnel would subscribe to the MQTT broker with the appropriate topic (eg 354740050182909/AT). This way you could put the same configuration file in all the devices. - Up to 3 tracks available for AT commands, so you can specify groups. That is, if you wanted to change the configuration of all the MTX-Tunnel modems located in Barcelona, you could do it by configuring them with the following command:
MQTT_attopic2: grupo/Barcelona
So every time you send an ATcommand from your MQTT application (for example, from your mobile phone) to the MQTT broker with the topic “group/Barcelona,” any MTX-Tunnel subscribed to that topic would execute that same AT command.
You could also configure the third topic (MQTT_attopic3) to execute an AT command on all MTXTunnel devices, as long as you set the MQTT_attopic3 parameter identically in all the config.txt files in all the MTX-Tunnel.
MQTT_atrtopic
Description: This parameter allows defining the topic that the MTX-Tunnel will use to send the responses to executed AT commands. That is, if the MTX-Tunnel receives an AT command through the topics MQTT_attopic1, MQTT_attopic2 or MQTT_attopic3, the answer will be returned in this topic.
Possible values:
- String up to 128 characters
- Default value: none
Additional notes:
- If you are going to use MQTT_attopi1, MQTT_attopi2, MQTT_attopi3 to send AT commands to the MTX-Tunnel you must specify a topic in MQTT_atrtopic for the response. Obviously you must subscribe to this topic on the device that you use to send AT commands in order to receive such a response
- Analogously to the above parameters, it is possible to include the [IMEI] tag and the MTXTunnel will replace that tag with the corresponding actual value. For example: MQTT_atrtopic: [IMEI]/ATResponse
- If your MQTT application allows you to send a message (AT command) with a given ID (message identifier mqtt), the MTX-Tunnel will respond to the AT command with the same ID
MQTT_qos
Description: This parameter allows to establish the quality of service of the MQTT communications used.
Possible values:
- 0, 1, 2
- Default value: 2
Additional notes:
- The value 0 implies that the message will be sent once and there will be no response message to check if the message arrived correctly or not to the Broker
- A value of 1 ensures that the message reaches the MQTT broker at least once (although it may arrive more often)
- The value 2 ensures that the message will reach the MQTT broker once and only once
- MQTT_qos is just used with LOGGER. DNS and answers to AT commands sent via MQTT use qos 0
MQTT_keepalive
Description: It is possible to define the seconds of keepalive with this parameter, that is, the seconds of waiting for the client to make a connection with the MQTT Broker to verify that the connection is still established.
Possible values:
- 10… 3600
- Default value: 300 (5 minutes)
Additional notes:
- It is highly recommended to set a reasonable value for that value, such as 300. If you specify a maximum value of 1 hour you should keep in mind that in the event of a loss of connectivity with the mqtt broker (without socket closing signal) you could keep MTX-Tunnel disconnected from it during the same time period
MQTT_persistent
Description: This parameter allows to establish the persistence of the data for the data sent by MQTT from the LOGGER_ or by the DNS_ frames.
Possible values:
- on, off
- Default value: on (persistent data)
Additional notes:
- Let’s say you are sending a DNS_ frame via MQTT each time a digital input changes. To do this, you have configured the DNS_mqttTopic: [IMEI] / DNS parameter to send a JSON with the modem I / O data to that broker topic each time a digital input changes. If the persistence is “off” the data (actually the last data received) are NOT stored in the broker. That means, for example, if you are going to query the MTX-Tunnel status (I/O) from a mobile phone with an MQTT client, you would only know the current MTX-Tunnel I/O status if the MTX-Tunnel sent the data to the broker MQTT you had connected the mobile phone to the broker at that time
- If you want the MQTT broker, when you connect with the mobile phone or your application, to send you the last status received from the MTX-Tunnel, simply set this parameter on
MQTT_filetopic1
Description: this parameter allows to send a file to the modem via MQTT. The modem will subscribe to this broker TOPIC to receive files. This way, any file sent from this topic will be downloaded by the modem. It can be useful to change completely the configuration file config.txt for instance.
Possible values:
- Text up to 128 characters
- Default value: none
Additional notes:
- The format we need to send the file to this TOPIC so it’s received and processed by the modem is this:
path/nombreFichero,<array de bytes> - For instance, to change the configuration file “config.txt,” it will be similar to:
config.txt,COMM_baudrate: 9600[0x13][0x10]COMM_bitsperchar: 8[0x13][0x10]…
(where [0x13] and [0x10] represent hexadecimal values of ENTER after each parameter in the
configuration file) - Check the parameter MQTT_filertopic to know the answer from the modem to this topic
- This parameter is only available from MTX-Tunnel 9.39 on
MQTT_commrxtopic
Description: this parameter allows to configure the mqtt TOPIC to which the modem will subscribe to. All data the modem receives will be resent through the mail serial port (the one configured with the COMM_ parameters).
Possible values:
- Text up to 128 characters
- Default value: none
Additional notes:
- To use this parameter we need to configure additionally the modem with the parameter MTX_mode: mqtt
- All the bytes received on this topic will be resent through the main serial port of the MTX modem. If we need to resend them through the secondary port (RS485 in most MTX modems) we need to configure the parameter MTX_invertedCom: on
- This parameter is only available from MTX-Tunnel 10.09 on
MQTT_commtxtopic
Description: this parameter allows to configure the mqtt TOPIC to which the modem will send all data received through its main serial port (the one configured with COMM_ parameters).
Possible values:
- Text up to 128 characters
- Default value: none
Additional notes:
- To use this parameter we need to configure additionally the modem with the parameter MTX_mode: mqtt
- All the bytes received on the main serial port of the MTX modem will be resent via MQTT to the topic configured on this parameter. If we need to use the secondary port (RS485 in most MTX modems) we need to configure the parameter MTX_invertedCom: on
- Remember we have the MTX_msToSend parameter. It may be necessary to use it if you need to receive the data in your MQTT platform in just one package (without any fragmentation)
- This parameter is only available from MTX-Tunnel 10.09 on