Tunnel – Reading IEC counters, DLMS/Cosem, Modbus with protocols implemented in an MQTT platform

Scenario details:

• We want to read a large number of different meter boxes (IEC counters, counters with DLMS/Cosem protocol, modbus protocol network analyzers, etc.) All devices have an RS232 or RS485 serial port
• In order to make the system cheaper, economic devices with 2G/3G/4G connectivity will be used, such as the MTX-4G-JAVA-T modem, whose model has an RS232 and RS485 bus, making it suitable for all cases. The SIM cards used may be from any operator, so it is not guaranteed that the IPs are public or fixed. Therefore, connectivity must always be established from the counter to the platform
• The communication between platform and devices will be via MQTTS, which guarantees the connectivity required in the previous section and adds a layer of SSL security in the communications between platform and counter
• The modems will act as “Transparent gateways Series – MQTT,” therefore the interpretation of the protocols (ie. the IEC protocol intelligence, DLMS/Cosem, modbus…) will be on the platform. This allows that in case of adding new features it is not necessary to remotely update the firmware of the entire modem pool, with the risk it involves, but only to update the software in one place, that of the MQTT platform
• Likewise, in addition to being able to read from the platform the different meters, a “Device Manager” must be implemented, in order to be able to constantly visualize the status of the modems (status, coverage…) as well as to be able to change their configuration anytime
• The modems must also have communication enabled by SMS, allowing that, from several authorized telephone numbers, the status can be checked, changing configurations (for example, an incorrect APN that does not allow communication with the MQTT platform), executing remote reset or any other operation
• The modem must have the firmware (MTX-Tunnel) signed and locked. That is, it can’t be manipulated or changed physically. In addition, the configuration of the modem will be encrypted and for greater security, the memory blocked. It can only be unlocked, if necessary, from the MQTT platform or from an authorized telephone number
• The modem must have watchdogs that allow it to recover from problematic connectivity situations. Although it will not be used because it is not necessary, the modem must be ready to activate, from the MQTT platform or via SMS, a daily authorset every 24h

Solution: MTX-Tunnel firmware + MTX-Java-IoT/MTX-Java-T/MTX-Java-T2

Config.txt configuration file (master):

Configuration

Observations

COMM_baudrate: 9600 COMM_bitsperchar: 8 COMM_autorts: off COMM_autocts: off COMM_stopbits: 1 COMM_parity: none GPRS_apn: movistar.es GPRS_login: MOVISTAR GPRS_password: MOVISTAR GPRS_timeout: 0 MTX_PIN: 0000 MTX_mode: mqtt MTX_model: 199801445 MTX_ping: 35 MTX_pingIP: 8.8.8.8 MTX_invertedCom: off MTX_msToSend: 100 SMS_allPhones: off SMS_sendIP: off SMS_ATEnabled: on SMS_ATResponse: on SMS_validPhone1: +34666123456 SMS_validPhone2: +34666123457 FIREWALL_enabled: off MQTT_enabled: on MQTT_server: ssl://test.mosquitto.org:8883 MQTT_id: [IMEI] MQTT_attopic1: [IMEI]/AT MQTT_atrtopic: [IMEI]/ATR MQTT_keepalive: 300 MQTT_commrxtopic: rxmaster MQTT_commrxtopic: txmaster DNS_enabled: on DNS_mode: mqtt DNS_mqttTopic: [IMEI]/dns DNS_extended: off DNS_period: 300

Serial port baud rate 8 bit data No flow control No flow control 1 stop bit No parity GPRS APN from your network operator GPRS Login GPRS Password MTX-Tunnel is always GPRS connected If SIM card has no PIN security, use 0000 value MQTT serial gateways will be used MTX-Terminal modem model used One ping every 35 min. without communications Ping address Gateway port RS485 No fragmented networks Send SMS with commands from any phone Modem won’t respond to a missed call/SMS Commands can be sent to the MTX by SMS MTX responds with an SMS to a command SMS Authorized phone number 1 Authorized phone number 2 No firewall MQTT service enabled Broker IP/DNS specified, including identifying port Identifier MQTT topic to send AT commands Topic to send replies to commands to Connection keep alive (300 seconds) Data received will be retransmitted via serial Data received v/serial, retransmitted to this topic Status data sending activated MQTT sending mode Topic where status data are sent Extended data (E/S, ADCs…) are not sent One sending every 300 secs (5 mins.)

Details:

• The config.txt file shown corresponds to the modems connected to RS232 devices. If you need to use the RS485 port, you only need to change the MTX_invertedCom parameter to “on”
• Likewise, you must adjust the values of the COMM_ parameters, adjusting them to the configuration of the serial port of the connected device
• If you use SSL communications and need to incorporate the certificates of your broker, at the end of this document you will find an Annex with the procedure
• Remember that with this example the MQTT platform directly access the serial port of the device and it must be this one the one to interpret the protocol, because the modem treats the information transparently. In addition, the platform will monitor the status of modems (modems send their status every X minutes) and can also use the MQTT_ATTopic1 topics to send AT commands to the modem from the platform at any time (to make configuration changes, resets, etc.). Remember you can set up to 3 topics of AT commands for each device. If you put the same topic in all modems you can, executing a single command on your MQTT platform, execute an action (AT command) on all modems
• With this configuration, all the modems subscribe to the topic [IMEI]/rx. This causes all the data frames sent by the platform to this topic to be received by the corresponding modem and retransmitted, as is, by its RS232 or RS485 serial port. In the same way, all the data frames received by the RS232 or RS485 serial port of the modems are automatically retransmitted via MQTT to the topic [IMEI]/tx. Remember that it is not necessary to replace [IMEI] with the corresponding IMEI, the modem does it automatically
• Keep in mind that communication latencies can be somewhat greater than with direct communication (since there is an intermediary, the mqtt broker, and the speed of communications will depend on the power of the latter). Set the timeout if necessary.