-
Notifications
You must be signed in to change notification settings - Fork 7
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
The broker quit operation - "Keep alive time overdue". #35
Comments
In an attempt to isolate the problem I set up a separate system for one device measuring, a broker and a client only listening. After some time I intentionally reboot the device. After that it does not seem to (re)connect, I do not know the cause for that. But I do not expect the broker to quit because of that. The broker:
A client just listening to the broker fwiw:
|
Hi @ingoogni Thanks for reporting it - it sounds strange. I have tested the setup without any problems:
When the broker disconnects, the clients will try to auto-reconnect like this:
|
Thanks for looking in to it. When I simulate it like you do, I get the same results as you do. The problem that occurs with the rebooting of the Shelly device is reproducible. The Shelly device is a commercial one, build on an ESP8266 with Mongoose OS. That's all the info I have on that. It will take some time, I can try the device with an other broker if that helps. |
Ohh, I see. Your error message is also |
That is the nmqtt subscriber client. It does that when the broker is not online. Once the broker is on line again it connects fine. There is something I have not tried. It is a plug so I can just pull it from its socket, wait and see what happens. |
Pulling the whole device from the power socket so it stops sending data has the same result. After some time the broker quits. Another situation works fine. I start the broker and sub_client. After that I put the device in the socket. It connects fine and sends the data as to be expected. Broker log of pulling the plug:
nmmqt_sub client for plotting the values:
|
Without going through the whole process and would probably understand half of it I noticed: In |
Tested it today with Mosquitto, nmqtt_sub and the Shelly. No problem. I can reset the device, it goes off-line, comes back on-line and everything continues as it should. Same when I just pull the plug and put it back. Also tested it with HBMQTT broker (python). Same result, it works flawless. Hope it helps. |
When I stop (ctrl-C or taskmanager) a nmqtt client, the broker prints
The after ~60 seconds the broker prints: When I pull a shelly plug, or reboot it the
message from the broker is not there. The power to the client was cut so no "goobye message" could have been sent. Could this make the difference? |
Can you replicate it, if you only subscribe to a single topic per client?
Could you try to clone the repo and change the output message? Then we can inspect the client data.
I cannot recreate the scenario, so I can't force the error. But it could sound like, that the broker does not recognize that the client has disconnected, and then errors out on a dead client. |
A way to recreate the problem I tested today: run a listener client on a laptop connected with wifi, run the broker on an other machine. Then turn off the wifi connection on the laptop. After ~ 60 sec the broker will quit. Below the output of the patched broker:
|
in
and all seems to work fine now...? |
I'm still testing things. It is a strange problem and I have trouble following the flow. In what I did no |
A little step further,
Now, after this change unplugging the device seems to works flawless. More testing needed. But now the question is why does the server crash without the change?? There is a topic and there is a message that can be send, regardless of the flag. Is the something wrong in the sending of the LWT? |
Tested with a pristine install of nmmqt on win11. I wrote two clients. On standard one In the second client I added a modified 'set_will' that sets a will topic and message but with a As I do not understand the flow and big chunks of (n)mqtt that's about what I can figure out. The problem seems to be connected with the willFlag somehow.
server output serving
server output serving
|
it seems to met that the |
The following changes seem to fix the problem as far as I can test. Please test. First the fixed version:
Then sending a will fails and crashes the server if there are no subscribers to it: current version:
fixed version:
|
The broker quit operation after a client disconnects. It happened a few times, but it is not something I can reproduce. Below is all I could catch.
Using nmqtt-1.0.4, Nim 1.6.6, Windows 11
The text was updated successfully, but these errors were encountered: