ESP32 stops subscribing after a while

[Bernard314]

I am using an esp32 to track my machine usage. it publishes the machine data using mqtt publish qos 1. i have also made the esp32 subscribe to a topic where i send in some inputs.

My issue is my code works perfectly fine but after a few hours it stops receiving messages. it still publishes the data so i know it is connected to mqtt without any problem, but why does it stop receiving these messages?
My code is really simple just subscribe (i unsubscribe and then resubscribe after every 30 minutes to try to see it that fixes it also. didint help) and publishes.

Any help?

[bertmelis]

That would be very odd behaviour. If it is connected, it means it sends and receives PING/PONG messages.

Are you able to get debug output via Serial? --> set core debug log level to "verbose".
Can you share your code?
Anything special in the log of the broker?

[bertmelis]

another option is to set the keepalive higher then the expected frequency you expect to send packets from the client (or receive qos >0 packets).

So if you send a packet every minute, set keepalive to 75 seconds or so.

[Bernard314]

ok so I ran a few tests. some at my place of work (where I intend to use my project) and some at home and now i can say for sure it has something to do with the Wi-Fi at work. At home I ran the test for 3 hours (twice) and have faced absolutely no interruptions in both cases. while at work, issues start showing up after about an hour.

this is the log of my aws mqtt broker, of when my client connected subscribed and disconnected. All the disconnected logs mention "MQTT_KEEP_ALIVE_TIMEOUT"

i increased the keepalive to 120 seconds. i send a pack every few hours. can i keep the timeout time that high? like i only send about 10 packets a day (i need a consistent connection because I am subscribing to receive some inputs randomly)

My home Wi-Fi is much better than my work Wi-Fi, but I don't think it's that bad. (It is pretty consistent, but it does have several cameras linked to its ethernet). But like mqtt is supposed to be lightweight. I am going to check some properties and investigate my work Wi-Fi tomorrow.

[bertmelis]

I can change the code but it's actually AWS that is messing up here. The spec says the broker should disconnect after 1.5x keepalive. I is allowed to disconnect whenever it wants to.
The client sends a ping on 1x keepalive.

Keepalive can be set to several hours but you lose "responsiveness". You don't know if the client is still online until keepalive expires.

I still wonder why you're the first one that suffers this issue. I also need a closer look into the log timestamps. Does it disconnect exactly at keepalive later?

[bertmelis]

Ok, I did some searching and reading. I don't know what is true as I don't use AWS myself. AWS is respecting the 1,5 keepalive according some Google sources but the minimum value is 30sec. So it might be the client itself that is disconnecting because it thinks keepalive is set at 15.

Can you confirm the 120s works on both locations?

[bertmelis]

Source of the keepalive limitation on AWS is here: https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.html#mqtt-differences

[Bernard314]

Ok, I did some searching and reading. I don't know what is true as I don't use AWS myself. AWS is respecting the 1,5 keepalive according some Google sources but the minimum value is 30sec. So it might be the client itself that is disconnecting because it thinks keepalive is set at 15.

Can you confirm the 120s works on both locations?
Yeah that's the thing. The code even with default value works perfectly at my home wifi. But not (even with 120s) at my work wifi. I'll check if there is any firewall issue or something idk?

While mqtt disconnects frequently at my work, the wifi-esp connection doesn't break that often

[Bernard314]

ok i ran some more tests. so i have 2 routers at work. i ran my code on the secondary router this time and faced much fewer disconnect-connect cycles (3 in 2 hours) which i feel is very reliable. also the device reconnected much faster. i believe its only my primary router that sucks after all. i'll change them and see how it goes.

sorry i ever questioned your greatness

[bertmelis]

question my greatness?

for me it's a matter of testing different environments and making the client more robust. Cases like yours I find interesting.

[Bernard314]

thanks! thats great. i think in a few days I will be able to change the routers (or maybe find an unused one to be used solely for my esp32s, i plan on installing around 5 of them). I'll update you on my progress!