Thales IoT Developer Community
AT Command MQTT client
Showcase, January 22, 2019 - 4:37pm, 25865 views
This project allows you to use our, more recent, Java modules as simple MQTT clients.
Just use AT Commands - no Java programming needed.
The MQTT client is made possible via the Thales IoT Java AT Command Extensions (JAT).
Both Plain text :1883 and TLS 1.2 secure sockets :8883 Broker connections can be used (even AWS).
You can add new AT Commands to the ELS61 rel 1 "MR" / ELS61 rel 2 / PLS62-W rel 2 and EHSx rel 4 modules. URCs are generated showing broker connections, loss, and reconnections.
Publishing JSON formatted strings is supported, see the attached documentation for the syntax needed.
Publishing HEX formatted binary byte[] strings is supported, see the attached documentation for the syntax needed.
+PBREADY
at^sjam=1,"a:/ATSJMQTT.jad",""
OK
^SYSSTART_EXTENDED_AT
at^sjmqtt="tcp://broker.hivemq.com:1883","","","ATSJMQTTDemo","ATSJMQTTDemoListener","bearer_type=gprs;access_point=internet;username=;password=;timeout=30"
OK
at^sjmqtt="open"
OK
^SJMQTT: 'ATSJMQTTDemoListener'/****** - from your friendly broker :)'
at^sjmqtt="pub","The module says a big MQTT client Hello back to the broker"
OK
at^sjmqtt="pub","{'JSON style temperature': '35 degrees C'}"
OK
at^sjmqtt="close"
OK
at^sjam=2,"a:/ATSJMQTT.jad",""
OK
^SYSSTART
See related articles:
https://iot-developer.thalesgroup.com/tutorial/data-transfer-methods-mqt...
https://iot-developer.thalesgroup.com/tutorial/flash-file-system-access-...
https://iot-developer.thalesgroup.com/tutorial/flash-file-system-access-...
Hi,
As I understand, the MQTT AT command shall support ssl in addition to http. We are trying to connect to an Azure IoTHub an have difficulties figuring out how to set up the commant with necessary information to connect. Are there any documentation on this?
Looking forward to your reply!
Vidar
We are developing a board including a Cinterion ELS61. The goal is to transfer data to an Azure application using IoT hub. The two first boards were equipped with a Revision 2 module, which we expected the production series to be equipped with also. We downloaded the latest version of the MQTT Midlet, and after some days of work we managed to communicate with Azure via CloudMQTT (a MQTT broker). When we received the small production series, the boards were equipped with Revision 1 modules. When testing the new boards, the MQTT communication did not work as on the Revision 2 based boards. The MQTT Midlet is said to work for Revision 1 MR (Maintenance Revision) and Revision 2. We contacted our local distributer and received a new Revision 1 firmware (A-Revision 00.032.02). We are not sure if this is a MR revision (the distributer could not tell). The first difference we observed was that we did not receive ^SYSSTART_EXTENDED_AT as a response to the AT^SJAM=1,"A:/ATSJMQTT.jad","" command. When we try to connect to the MQTT broker we receive an error:
Connected to operator OK
Starting MQTT
AT^SJAM=1,"A:/ATSJMQTT.jad",""
OK
MQTT program started OK
Connecting to BeeCloudHub.azure-devices.net via CloudMQTT.com
Specifying broker
at^sjmqtt="tcp://kind-model.cloudmqtt.com:1883","",""
+CME ERROR: Unknown
We used AT^SJAM=4 to verify that the Midlet was installed –it was.
We used AT^SJAM=5 to verify that the Midlet was running – it was.
Can someone tell us why the MQTT Midlet does not work on Revision 1 with A-Revision 00.032.02 firmware? Or better, can someone tell us what to do to make it work?
Regards
Vidar
Hi,
There must have been some kind of publishing error (probably my fault). The correct file is definately published now dated 25.02.2019 and a JAR file size of 331,306 bytes.
Best regards
Simon