The objective is to be able to send data back up to an MQTT server using the Nordic NRF9160 hardware. Nordic staff is helpful but only writes back usually in the very early hours of the morning.
There are two methods I have tried to send data back to the MQTT server based on two separate Nordic examples - 1) the MQTT_SIMPLE sample which we have been using so far to at least receive messages from the MQTT server which is great for remote control of the product. 2) the LTE Serial Modem sample which is a more complicated system but allows for separate microcontroller AT commands to connect to the MQTT server, however it loses all the functionality of MQTT_SIMPLE which reconnects to the server if it loses connection and a whole array of other important features.
METHOD 1: PROBLEMS with MQTT_SIMPLE modified and now called MQTT_W_UART
note first and foremost that the filename and root directory/path must be short (MQTT_W_UART and not some longer name) otherwise the compiler blows up when it sees strings of more than 256 characters in length as it builds up mountains of build folders and files with concatenated strings, and this compilation takes about a minute or two running on a fast computer.
There was an old sample (not part of the core samples that ship with NRF Connect suite) based on MQTT_SIMPLE written by Simon and recently modified by Charlie so that it could be compiled on the latest NRF Connect SDK 1.7.0. This is to be called MQTT_W_UART and it would have all the features of MQTT_SIMPLE with the added bonus of being able to publish what it sees on a separate UART to the MQTT server. We have this working now (it compiles fully and then gets all the way through to claiming that it is connected to the MQTT server) except that now when we try to publish to the NRF9160's subscribe topic, unlike in MQTT_SIMPLE, we can no longer see the messages on the screen. This is supposed to come through as a LOG_INF which is working for everything else but no longer working for the important messages that are being subscribed from the subscribe topic (which I tested five times to make sure it is identical in the KCONFIG and PRJ.CONF files to wat we were using in MQTT_SIMPLE that actually works). The other problem is that no matter which UART I type data into, it doesnt seem to do anything like publish to the PUBLISH topic. This is bad.
METHOD 2: PROBLEMS with LTE_Serial_Modem (LSM) AT#XMQTT commands
In this method we use the LTE Serial Modem code which is part of the core set of samples (actually this is located in the applications folder - so maybe it isnt considered a "sample" but it compiles the same way as a sample). Ive got this working to the point of connecting to LTE and even connecting to the MQTT server using commands like AT#XMQTTCON, AT#XMQTTSUB, and AT#XMQTTPUB. There are two major problems - one: for whatever reason, just connecting to the server makes it download a bunch of old messages that the MQTT_SIMPLE fortunately ignores. Even before I tell it which topic to subscribe to, it just plops a whole bunch of useless old messages on the screen, and a buffer somewhere must be getting full because it doesnt show any new messages from after yesterday. Not sure how to fix this but might be something simple like a flag somewhere. Perhaps the bigger problem, however, is the AT#XMQTTPUB command. Even if we could fix the first problem, the AT#XMQTTPUB command is broken. Instead of being a nice clean command with a short text to send to the publish topic, it acts as though it turns the AT command input into some kind of data terminal that has no termination strings ( +++ does NOT work nor does CRLF ). So giving it this command like AT#XMQTTPUB="my/publish/topic","Sending text to the cloud at QoS 1",1,0 just results in chaos. There is no more control over the serial port - no more AT commands can get through - and then when you type something again, it will publish once to the MQTT publish topic but never again and you are completely locked out from that point onward.
So, in a nutshell, I cant get the MQTT two-way communications using NRF9160 to work trying two distinct methods
