[MQTT] Fix change in client.connected() behavior for pubsubclient #2811
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
See this issue where the changes in behavior for wificlient.connected() is discussed: esp8266/Arduino#6701 A change dating back to April 2018 ( esp8266/Arduino#4626 ) does have some implications on how to interpret the client.connected() result. It is very well possible there is still data in the buffers waiting to be read. So the loop() function of pubsubclient should first try to empty the received data and then decide what to do with the connected state. So reading is fine, if there is data available, but writing needs an extra check.
Use of connection failure threshold is now also trying to disconnect/reconnect a number of times before reboot.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See this issue where the changes in behavior for wificlient.connected() is discussed: esp8266/Arduino#6701
A change dating back to April 2018 ( esp8266/Arduino#4626 ) does have some implications on how to interpret the client.connected() result.
It is very well possible there is still data in the buffers waiting to be read.
So the loop() function of pubsubclient should first try to empty the received data and then decide what to do with the connected state.
So reading is fine, if there is data available, but writing needs an extra check.
Use of connection failure threshold is now also trying to disconnect/reconnect a number of times before reboot.