What happens if the ESP doesn't lose its wifi connection but the wifi router is no longer connected to the internet? When we unplug our router from the internet, the ESP is still happy about its connection and calls to mqtt.publish don't give any errors. After about 10 seconds and several calls to publish, it seems to hang in the publish call, and when we reconnect the router, the ESP unhangs and resumes normally after a similar period. It's like the mqtt client doesn't realize that it is not online, which is supported by the fact that when it finally comes back online it doesn't need to call mqtt.connect to be able to publish normally. (We are using version 2.0.4 of the mqtt client.)

I did a bit of work to improve the stability of the MQTT package on Friday. I will continue with it tommorow (Monday), and will have a look at your scenario.

Thanks 🙂

Fyi: I'm feeling under the weather, so I won't make any progress on this today.

Hi Florian. Any progress on this?

I'm going to work on this today.

That could explain it. What about QoS=0? (which is what we are using)

QoS=0 would just send into the void. So there wouldn't be any difference to the current behavior. The window size on the esp32 is relatively small so you can probably still detect it quite early with a

with_timeout

Hi Florian

with_timeout

solved the issue, but we could probably benefit from the changes you made to the mqtt package. Do you plan to make a new package release with the changes? /Tommy

Yes. Thanks for reminding me.

No problem 😄

Released

Thanks 🙂

It looks like the new mqtt package requires 2.0.0-alpha.41, do you remember what exactly is required from it? 🙂

Mostly minor things.

We are using 2.0.0-alpha.35 currently, but we do need to upgrade in the near future anyway, so we are just discussing atm 🙂

I'm pretty sure it should just work if there aren't any warnings during compilation.

I am getting

The SDK constraint defined in the package.lock file is not satisfied: v2.0.0-alpha.35 < ^2.0.0-alpha.41

when i try to build

I uploaded a branch with alpha.35 as requirement. Let's see if it the build goes green.

I'm not sure how to use a package from a specific branch 🤔

Looks clean.

Oh okay, you were trying it

Just fyi: if you want to experiment with a modified version of a package, the easiest is generally to check the package out, and then to install it with

jag pkg install --local --name mqtt ../mqtt

Okay thank you very much! 🙂

v2.1.1 should be live.

I will start testing now 🙂

Thanks for testing. Interesting. If you have the time to look into it a bit more, that would be great. Let me know when you want me to have a look.

I will have to push it to tomorrow, but here's some info: I am blocking the mqtt port 1883 to disconnect the esp from mqtt, and when I unblock it again, it reports this:

2022-11-30 11:48:39,808 DEBUG: Connected to broker
2022-11-30 11:48:39,814 DEBUG: Attempting to (re)connect
2022-11-30 11:48:39,825 Heap report @ out of memory:
2022-11-30 11:48:39,838   ┌───────────┬─────────┬───────────────────────┐
2022-11-30 11:48:39,843   │   Bytes   │  Count  │  Type                 │
2022-11-30 11:48:39,855   ├───────────┼─────────┼───────────────────────┤
2022-11-30 11:48:39,860   │    5256   │      4  │  external byte array  │
2022-11-30 11:48:39,866   │  102400   │     19  │  toit                 │
2022-11-30 11:48:39,871   │    8952   │     37  │  lwip                 │
2022-11-30 11:48:39,876   │    7992   │    723  │  heap overhead        │
2022-11-30 11:48:39,881   │    7864   │     51  │  event source         │
2022-11-30 11:48:39,886   │   32872   │    313  │  thread/other         │
2022-11-30 11:48:39,891   │   22304   │     21  │  thread/spawn         │
2022-11-30 11:48:39,896   │   23280   │    159  │  untagged             │
2022-11-30 11:48:39,901   │   33864   │     81  │  wifi                 │
2022-11-30 11:48:39,914   └───────────┴─────────┴───────────────────────┘
2022-11-30 11:48:39,921   Total: 244784 bytes in 685 allocations (82%), largest free 52k, total free 54k
2022-11-30 11:48:39,924 DEBUG: Connection established
2022-11-30 11:48:39,926 INFO: disconnect from server
2022-11-30 11:48:39,929 DEBUG: Attempting to (re)connect
2022-11-30 11:48:39,937 DEBUG: Attempting to (re)connect

It keeps giving the

Heap report @ out of memory

, so I think it tries to reconnect multiple times with the same client, and having multiple clients with same name will disconnect each other.

The new client is probably more aggressive in trying to reconnect.

Yup, the old one completely disconnects after some tries

There are a few things here: - the client uses a reconnection-strategy. That one is configurable, but is now (by default) the "tenacious" strategy, which will never give up. It just tries over and over again, incrementing the delay between attempts by 1 second. - as long as the reconnection strategy is trying, a

publish

call doesn't fail. However, the

publish

is blocked at that point.

We are now using

with_timeout

to catch, but I think we will go back to old strategy for connecting. I will look into the new strategy later, but for now we want the client to close.

In that context: the new client also has an option to set the maximum number of inflight packets.

Yeah the inflight packets is what we are excited for 🙂 but I dont know when I have time to look at it. A VC next week would be great I think, I will see tomorrow if thats okay

Sure. Just ping me.

Great thanks! 👍

Would it be possible to move it to a bit later?

Sure, when do you have time?

Anything after 10:00 works. Preferred is 11:00+

How about 13:00?

Perfect