Added sender with reconnect example #15
Conversation
|
|
||
| // call poll() regularly to allow the library to send MQTT keep alives which | ||
| // avoids being disconnected by the broker | ||
| mqttClient.poll(); |
There was a problem hiding this comment.
Can you please explain why this needs to be moved? What issue's where you seeing?
The idea is .poll() should be called very frequently and sending should happen on the interval
There was a problem hiding this comment.
See #14
Probably calling poll so frequently somehow gets my client disconnected after 2-3h. I didn't dig deeper, as moving the poll seemd to have fixed the issue, or at least reduce drastically the number of disconnections
There was a problem hiding this comment.
@5N44P thanks for the reply. At this time, I'm not keen to move forward merging this change until we further understand exactly why it fixes things.
There was a problem hiding this comment.
Do you have any suggestions on how or what to test?
There was a problem hiding this comment.
I would suggest to uncomment this line to start and enable debugging of the library: https://github.com/arduino-libraries/ArduinoMqttClient/blob/master/src/MqttClient.cpp#L22
We need to track down if there is something wrong at the WiFi or MQTT level.
There was a problem hiding this comment.
Can't we just merge this PR? It already contains the reconnect example
There was a problem hiding this comment.
Hi @5N44P 👋 Unfortunately not really ... even in your example code only you've moved the poll inside the timed function. As long as we don't understand from where exactly the problem originates hiding it is not a solution.
There was a problem hiding this comment.
@aentinger how can we debug this?
I'm aware that reconnecting doesn't fix the problem, but if it makes the library usable for everyone it should be at least proposed as an example.
What I'm thinking, by the way, is that random and erratic disconnections can be expected, and if handled with a reconnection are not an issue. The polling without delay just gives an higher number of disconnections per unit of time, keeping the frequency per request unaltered.
There was a problem hiding this comment.
What I would be doing is this: Solder a SWD connector to the bottom of your MKR board and connect your favourite debugger + graphical debugging front-end. Trying to get to the bottom of this issue via Serial.print(...)-debugging is probably going to be quite hard.
I'd do it myself but unfortunately there are a lot of high priority items on my list which is why I won't get to it anytime soon 😞 If you could help out here it would be greatly appreciated. Talking about debugging, the Arduino Pro IDE comes with experimental debugging support.
There was a problem hiding this comment.
Or of course uncomment the line suggested in #15 (comment) .
|
|
The poll() call is moved inside the non-blocking delay cycle, this fixes #14
Also, a reconnecting example is added