This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

MQTT Receives only on Ping or Publish

Is it expected that the MQTT API does not receive any events unless a message is published to the server? I'm noticing that without a ping event or any message transmitted, it doesn't receive anything new until the next ping/message. Is this observation accurate about how it works? Thanks!

Parents
  • I was playing around with my MQTT process thread. It looks like changing 

    err = poll(&fds, 1, mqtt_keepalive_time_left(&client));

    to

    err = poll(&fds, 1, 0);

    Seems to have done the trick. I'm going to play with it some more to make sure nothing funky is going on data usage wise CONFIG_MQTT_KEEPALIVE is set to 120. I'll re-open this if the issue persists.

  • Modifying the poll time does not seem to fix the issue. It seems to be related to how often mqtt_live is called plus what CONFIG_MQTT_KEEPALIVE is set to. Is there anything I'm missing here? The more often the pings, the more data is used which is not so great for our wallets!

  • Hey Jared, I was skimming over devzone and found this post. I think I might have helpful info to share:

    If you happen to have your device connected to LTE using PSM/eDRX, even when the negotiation with the network allows him to be absent at times and still maintain the connection (RRC Connected and RRC Idle), the device will not be reachable until it comes back (eDRX period or TAU depending on which one you're using).

    On the other hand, this network-device agreement does not keep the device from actually turning his radio on and exchanging information asynchronously from this absentee period. This is the case, for instance, when a keep-alive message is sent (which could be set to 60 seconds, whereas the idle interval could be, say, ~1 hour).

    Long-story short: you can confirm if this is your case by disabling both eDRX and PSM and re-testing your MQTT client code. Your device should now receive any notifications independent of the keepalive (as long as you're polling the socket).

    If it is, then you can play with these intervals to leverage the tradeoff between power consumption and acceptable delays and consciously choose your setting.

    I hope this is of any use in your journey!

    Best regards,
    LuisF

Reply
  • Hey Jared, I was skimming over devzone and found this post. I think I might have helpful info to share:

    If you happen to have your device connected to LTE using PSM/eDRX, even when the negotiation with the network allows him to be absent at times and still maintain the connection (RRC Connected and RRC Idle), the device will not be reachable until it comes back (eDRX period or TAU depending on which one you're using).

    On the other hand, this network-device agreement does not keep the device from actually turning his radio on and exchanging information asynchronously from this absentee period. This is the case, for instance, when a keep-alive message is sent (which could be set to 60 seconds, whereas the idle interval could be, say, ~1 hour).

    Long-story short: you can confirm if this is your case by disabling both eDRX and PSM and re-testing your MQTT client code. Your device should now receive any notifications independent of the keepalive (as long as you're polling the socket).

    If it is, then you can play with these intervals to leverage the tradeoff between power consumption and acceptable delays and consciously choose your setting.

    I hope this is of any use in your journey!

    Best regards,
    LuisF

Children
Related