I need a global MQTT broker status variable for the project. Is this version of the code suitable for my task?
xMQTTStatus = MQTTSuccess;
xMQTTStatus = MQTTAgent_CommandLoop( &xGlobalMqttAgentContext );
and checking: if (xMQTTStatus == MQTTSuccess) ..do something
The xMQTTStatus value you’d be saving here would be the operation status. If you wanted to store that as a global, that would be fine. You’ll want to make sure your global xMQTTStatus won’t be accessed in a pattern that will lead to a race condition.
By MQTT Broker status you mean the MQTT connection status right i.e whether or not your application is connected with the MQTT broker or not. Or is it something else that you wish to maintain?
Hi @pistoletov1974, if you wish to know the MQTT Broker Connection Status, a new API is introduced for this exact purpose. Checkout MQTT_CheckConnectStatus.
You can use this API after pulling from the mainline on the coreMQTT github repository. Here is an example of how you could use this in your application:
if( MQTT_CheckConnectStatus( pMQTTContext ) == MQTTStatusConnected )
{
/* do what is needed */
}
Thank you! This is exactly what i want.
I have studied the behavior of this function and it is not quite correct. When disconnected from the broker, the status does not change to disabled. To check, I added this code and the status began to change.
if(eNetworkEvent == eNetworkDown)
{
LogInfo(("Network DOWN"));
xGlobalMqttAgentContext.mqttContext.connectStatus = MQTTNotConnected;
// pContext->connectStatus = MQTTNotConnected;
}
But this is not done quite correctly, it is probably worth adding the status assignment MQTTNotConnected to the code if you do not receive a response to the broker’s ping
Hey @pistoletov1974,
Thanks, you are right. We intend to make this update and raise a PR in the coming weeks.
Thank you. Please monitor the status of the broker by responding to the PINGREQ command
ICMP requests will not verify the broker operational, only the reachbility of the host that runs the broker.
Broker ping this is not the same not the same as icmp. Thie is the specific mqtt protocol commands PINGREQ PINGRESP. I made corrections in the previous post
Can you tell me the approximate time frame for solving the problem? Best regargds!
Hi, while we cannot provide an approximate time frame at the moment, we plan to address it as soon as possible. We appreciate your understanding. Best regards!
Hey @pistoletov1974, could you please let us know what does your application do with the error status MQTTKeepAliveTimeout (which is given out when the PINGRESP is not received within the specified timeout)?
Hi @DakshitBabbar i add this code to my MQTTAgentTask
xMQTTStatus = MQTTAgent_CommandLoop( &xGlobalMqttAgentContext );
xGlobalMqttAgentContext.mqttContext.connectStatus = xMQTTStatus;
broker_isConnected = FALSE;
LogDebug(("MQTT com loop: %d",xMQTTStatus));
if program return from MQTTAgent_CommandLoop( &xGlobalMqttAgentContext ) my code initialize new connection to the broker.
After adding this code
xGlobalMqttAgentContext.mqttContext.connectStatus = xMQTTStatus;
, this expression began to work correctly
if( MQTT_CheckConnectStatus( pMQTTContext ) == MQTTStatusConnected )
Hello @pistoletov1974,
The MQTT spec 3.1.1 says this: If a Client does not receive a PINGRESP Packet within a reasonable amount of time after it has sent a PINGREQ, it SHOULD close the Network Connection to the Server.
Thus, it is NOT compulsory (as is verified by lack of ‘MUST’ in the above statement) for the client to disconnect from the broker when it doesn’t receive a PINGRESP.
Following that, the coreMQTT library or the coreMQTT-Agent does not disconnect from the broker on its own. It simply returns an error code showing that there has been a timeout.
It is up to the application how it handles the timeout scenario. The application may as well decide to send a second PINGREQ to verify whether the broker is actually offline or it might decide that the connection should be terminated by calling MQTT_Disconnect() or MQTTAgent_Disconnect().
Also, a side note, it is best not to modify the internal members of MQTTContext_t. If there are other threads modifying the structure, there might be a race condition.
Let us know if that answers your questions/concerns.
Thanks,
Aniruddha
Hello @kanherea , thank you for reply. I changed the member of MQTTContext_t . only for the function MQTT_CheckConnectStatus( pMQTTContext ) to work correctly.
In my application, there are optional telemetry messages that I do not send until the broker is connected, so as not to overflow the message queue in case of a prolonged shutdown of the broker. When sending such messages, I check the broker’s availability through the function MQTT_CheckConnectStatus( pMQTTContext ).
That’s exactly how my code works. Close socket and try to reconnect.
Why not call MQTT disconnect also before closing the socket?
@pistoletov1974 i agree with @aggarg here. You should close the MQTT connection too by calling MQTT_Disconnect (or if you are using the agent, then MQTTAgent_Disconnect) before proceeding any further in case of a timeout. Then you can close the TCP connection and cleanup the socket before reconnecting again.
If you do this, then you will not need to modify the MQTTContext_t. I don’t want to modify how currently coreMQTT works as it seems in line with the specification as I mentioned above. Let me know if my interpretation seems wrong. 
Thanks,
Aniruddha
Hi @kanherea , @aggarg thank you for repley! I took the example MqttAgent example code as a basis. It turns out that the best option is not implemented here? I need to close the TCP connection after receiving a callback from executing the command MQTTAgent_Disconnect? How will this command behave in case of a physical disconnection?
Hey @pistoletov1974, You are right and we should update this example. You should call MQTT_Disconnect and not MQTTAgent_Disconnect as the agent is no longer processing commands. Add the following code here:
( void ) MQTT_Disconnect( pMqttContext );
There is no need to explicitly change the pMqttContext->connectStatus to MQTTNotConnected after calling this API as it handles this internally. You are free to close the network after this and then reconnect.
Let us know what you find.