u-blox / ubxlib

Portable C libraries which provide APIs to build applications with u-blox products and services. Delivered as add-on to existing microcontroller and RTOS SDKs.
Apache License 2.0
303 stars 92 forks source link

Unable to subscribe to topic #137

Closed alexmaron81 closed 11 months ago

alexmaron81 commented 1 year ago

Sometimes can't subscribe to topic if many messages are sent before. In the following log it is only a fraction of what was previously sent. But if only one or two messages were sent then there is often no problem with subscribing.

Sent message: "["8988228066603271762",[4478,200,Unable to bring up the device!]]". AT+UMQTTC=2,2,0,0,"log","["8988228066603271762",[4478,100,Could not transmit data!]]"

+UMQTTC: 2,1

OK Sent message: "["8988228066603271762",[4478,100,Could not transmit data!]]". AT+UMQTTC=2,2,0,0,"log","["8988228066603271762",[1695376593000,120,Box is online!]]"

+UMQTTC: 2,1

OK Sent message: "["8988228066603271762",[1695376593000,120,Box is online!]]". Subscribing to topic "8988228066603271762"... AT+UMQTTC=4,2,"8988228066603271762"

+UMQTTC: 4,1

OK AT AT

OK AT+UMQTTER

+UMQTTER: 0,0

OK AT+UMQTTER

+UMQTTER: 0,0

OK U_CELL_MQTT: error codes 0, 0. Unable to subscribe to topic "8988228066603271762"!. AT

OK U_CELL_MQTT: trying to disconnect... I (147334) CELL: >>>>>>>>>>>>SARA is alive<<<<<<<<<<<< AT+UMQTTC=0

+UMQTTC: 0,1

OK Taking down network... AT+COPS?

+COPS: 0,0,"Telekom.de 1nce.net",7

OK AT+CFUN=4

OK

+CEDRXP: 4,"0010"

+CGREG: 0

+CEREG: 0,,,,,,,, -1: NReg -1: NReg AT+CREG?

+CREG: 2,0

OK -1: NReg AT+CGREG?

+CGREG: 2,4

OK -1: OoC AT+CEREG?

+CEREG: 4,0

OK -1: NReg AT+CGATT?

+CGATT: 0

OK -1: NReg U_CELL_NET: disconnected. cellDeinitDevice Done. cellCloseConnection Done.

RobMeades commented 1 year ago

Hi Alex: seems as though the module is just not returning the +UUMQTTC: 4,x,y response to indicate that the subscription has succeeded within the time that we allow, U_MQTT_CLIENT_RESPONSE_WAIT_SECONDS; not sure what the value of this timeout is in your case: it is currently 120 seconds, increased from the 30 seconds it was about 5 months ago, which was already quite long enough in my view (it is only 5 seconds for a Wifi transport).

You could try increasing the timeout, or you could keep it as it is and try again on a failure? Not sure what would be better for your application, if it were me I would do the latter.

RobMeades commented 1 year ago

@philwareublox has pointed out that, from the log, your publishes aren't working either, the MQTT client inside the module has basically stopped. If I were you at this point I'd disconnect and reconnect it.

alexmaron81 commented 1 year ago

The messages from the log were sent correctly. I don't see any stopping there. But as recommended, I ran "uMqttClientDisconnect" and then "uMqttClientConnect" and the subscription could then be carried out correctly.

Thanks for the tip!

philwareublox commented 1 year ago

The messages from the log were sent correctly. I don't see any stopping there.

You should be seeing the +UUMQTTC URC after the OK, to show the message was sent - especially if the QoS is set to '2'

RobMeades commented 11 months ago

I think this was resolved Alex? I am going to close it, please re-open if required,