BG96 AT+QMTOPEN? responds on USB, but not on UART

Trying to track down an unexpected behavior with a BG96 design. I have not yet been able to test the behaviors with the BG95-M3 module.

When using the AT+QMTOPEN? command via the USB-AT port, the results are the expected behavior, the response is the like below with the TCP connection ID, hostname, and port displayed.

+QMTOPEN: 0,“iothub-a-prod-loouq.azure-devices.net”,8883

OK

But, if I issue the identical command via the UART-AT port there is no response. I have not seen any other deviation in AT command behavior based on USB vs. UART ports, like is present on the AT+QMTOPEN?. Note the AT+QMTOPEN write command works the same USB-AT or UART-AT.

This hinders checking validity for an existing connection if the system containing the module is restarted and the embedded application is attempting to reuse existing connections or is attempting to get the host name of the MQTT server after opening it.

Anyone seen this? Anyone have a workaround?
Thanks
Greg

AS you said , if you send the AT+QMTOPEN via UART AT port , no response .

  1. How about the other AT cmd ? Do all the commands from uart-at port not respond, or only this command does not respond?
  2. normally , there is no difference between this two way to sent AT

As far as I can tell, only AT+QMTOPEN? Yes, only the ? option of the command fails to respond. Really strange.

I was intending to use the Read version of the command to test for an open connection and to verify the host name. Now I use AT+QMTCONN and test for a State value of 2 (connecting) or 3 (connected).

The LooUQ cloud has multiple instances, so the ability to validate the host address would have been useful, but not a critical need.

Agreed, this seems not normal and very much an edge case. I had to go through the testing multiple times before I believed it.