-
Notifications
You must be signed in to change notification settings - Fork 1k
umqtt.robust dies when MQTT broker gets restarted #102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
In the screenshot above, I have restarted the broker after two successful MQTT publish messages (two temperature values in this case) |
I use code to avoid such problem:
def connect_and_subscribe(): You need to upgrade the robust by this PR: [https://github.com//pull/117] |
Is there a better way to go about handling this situation where the broker 'disappears' and then 're-appears' at some later time? The current implementation of umqtt.robust is not robust at all, even with the reconnect. check_msg never works even though it seems the client reconnected. Should the umqtt.robust object include a list of subscribed topics to auto-resubscribe in the reconnect() function? |
That last message as a microPython newby worries me... I don't want to start coding in microPython on the basis of unreliable MQTT as we have reliable MQTT in C...... Can someone give an example of this "robust" code which WILL stay connected and which will resubscribe on reconnection - i.e. so that it just works in the background. Is this possible? |
Yes, the current implementation of umqtt.robust does not handle the case when the broker is restarted and forgets all of its state (at least the state related to your client).
Prehaps. This is indeed how other libraries work (eg https://github.com/fusesource/mqtt-client). The robust MQTTClient class would need to override the "subscribe" method to record the topics (and qos), and then in the reconnect() method it would call subscribe() again after reconnecting. |
See #186 for a fix which will resubscribe to all existing topics if a reconnect is made. |
Damn, I was in the process of writing a fix for this. You win the day, sir! |
@craftyguy I'd be interested to see your solution. And also if you want to test my solution and give feedback that would be great. |
I literally started about less than an hour ago, but my approach was pretty much the same as yours. Your solution looks to be more elegant/robust. I'll give this a shot possibly as early as tomorrow, since I'm tired of hacking together a more robust robust mqtt 😄 |
I tried your patch (#186), and it doesn't seem to work with this simple test program:
I should note that I am invoking the main() function here from main.py. When I restart the mqtt broker, I get an If my test is an invalid use of umqtt, please let me know since I am relatively new to using mqtt! |
@craftyguy for your example to work I think you need to connect with clean_session=True, because you'll be explicitly resubscribing upon reconnection. |
@dpgeorge I see, thank you for pointing that out. I also see the PR was merged :) |
@craftyguy No it wasn't, so you'll need to pull the PR explicitly to test it. |
Ugh, I guess I misinterpreted a notification I received, now I see it
was you just modifying the PR. Sorry!
…On Tue, Jun 06, 2017 at 09:53:05PM -0700, Damien George wrote:
> I also see the PR was merged
@craftyguy No it wasn't, so you'll need to pull the PR explicitly to test it.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#102 (comment)
|
I tried the PR and it does recover from a broker restart but when the broker loses power and comes back, it doesn't recover. It is completely reproducible, happens every time I take the power out from my raspberry pi zero running the mosquitto broker. Does anyone else face this behaviour? |
After `reconnect()`, MQTTClient.socket is blocking by default. This commit aims to fix that for when `check_msg()` sets the socket to non-blocking. May fix errors reported in micropython#102 and micropython#192. This fix: * avoids using an additional instance attribute to record the intended state of the socket * only adds two additional lines of code to one file in the codebase * depends on socket's `__str__()` method to retrieve the current timeout value: `<socket state=0 timeout=-1 incoming=0 off=0>` - not ideal
After `reconnect()`, MQTTClient.socket is blocking by default. This commit aims to fix that for when `check_msg()` sets the socket to non-blocking. May fix errors reported in micropython#102 and micropython#192. This fix: * avoids using an additional instance attribute to record the intended state of the socket * only adds two additional lines of code to one file in the codebase * depends on socket's `__str__()` method to retrieve the current timeout value: `<socket state=0 timeout=-1 incoming=0 off=0>` - not ideal
After `reconnect()`, MQTTClient.socket is blocking by default. This commit aims to supplement that behaviour at times when `check_msg()` sets the socket to non-blocking. It may fix errors reported in micropython#102 and micropython#192. This fix: * avoids using an additional instance attribute to record the intended state of the socket * only adds two additional lines of code to one file in the codebase * depends on socket's `__str__()` method to retrieve the current timeout value: `<socket state=0 timeout=-1 incoming=0 off=0>` - not ideal
After `reconnect()`, MQTTClient.socket is blocking by default. This commit aims to supplement that behaviour at times when `check_msg()` sets the socket to non-blocking. It may fix errors reported in micropython#102 and This fix: * avoids using an additional instance attribute to record the intended state of the socket * only adds two additional lines of code to one file in the codebase * depends on socket's `__str__()` method to retrieve the current timeout value: `<socket state=0 timeout=-1 incoming=0 off=0>` - not ideal
Is this still an issue on latest MicroPython and mqtt.robut? If so, we need minimal example code on how to reproduce. |
Hi,
the umqtt.robust module is pretty reliable but I found a case when it stops sending:
As soon as I restart the MQTT broker, I have to connect via WebREPL and press CTRL+C.
I use the following minimal test code:
https://github.com/phieber/uPython-ESP8266-01-umqtt
Can you reproduce this issue when restarting the broker?
br
Patrick
The text was updated successfully, but these errors were encountered: