The flow is as follows.
I saw the mqtt log status in a state where no data came in from node red and no connection was made.
However, the content in the picture is as follows.
"socket error on client mosqsub|15797-raspberry, disconnecting."
It came out like this.
It seems that the subscribing side doesn't send a signal, so it seems to end the process because it doesn't come from the publishing place.
If you look at it like this, is it a node-red problem, which is a form of subscription in a node-red flow?
Is it possible to solve this problem?
As far as I know, in the case of paho-mqtt, it is said that there is no problem if loop() is given.
I would like to know if there is a way to do it in node-red, or if I can do it by writing Python code.
For reference, the keepalive time in node-red was 60 seconds and the session was initialized.
Looks like you're using a fixed client id
Daeho_2. These need to be unique for each connection or they will kick each other out and reconnect in an endless loop.
All these connections originate from localhost, so things to check:
- multiple MQTT configuration nodes (meaning multiple broker connections)?
- other local clients which use that client id?
- multiple instances of Node-RED?
Sometimes you end up with multiple config nodes when you imported flows with MQTT nodes.
I think this happens "always", it's very annoying and I have mentioned it several times long time ago to "Management" but the problem persists
We apologize for the fact that we cannot disclose the flow.
Several mqtt settings have been made. 5 mqtt subscribed at the same time..
The client ID is set the same.
There are a total of 7 node flows.
Probably, I think node red mqtt should send a signal, but I can't send it intermittently, so the process seems to be blocked ah.
Since node red cannot be restarted, there is no other choice but to reboot the raspberry pi again..
How many MQTT config nodes do you have?
Open them all one at a time. Do you have a fixed client id of
Daeho_2 more than once?
Alternatively, Do you have another application (another node-red, some other MQTT enabled software) with a fixed client id of
If the answer is yes to either question, then this is your problem.
no. I just checked and found only one.
Is that a "no" to all questions? ↓
Not at all. The Raspberry Pi is the only sensor used.
Clear out the Client ID in the mqtt config. It is not necessary to provide an ID, node-red will generate a random one for you. It should only be there in one config node. If you find it in multiple config nodes that that is the problem. You should just be using one config node for all mqtt nodes.
See what the log now shows.
For the future, if posting logs please copy/paste the text rather than a screenshot, it can be very difficult to read screenshots. When pasting use the technique described in this post to stop the forum from messing with the text - How to share code or flow json
For future reference, you can start node-red in safe mode, which restarts only the editor without running any flows. You can then fix any issues in your flow, and deploy it again to restart it from running. To do so, stop the running node-red process if you hadn’t done so already, then start it as
node-red --safe [flow.json]
@Athurian is your problem solved?
It hasn't been resolved yet.
It was configured with two Raspberry Pis, not a local configuration method.
One is with a sensor and is published.
One does not have a sensor, and I have tried subscribing to mqtt.
While reading sensor data, it still disconnects after a few hours.
The cause is unknown.
As a result of looking at the log records, it looks like this:
"socket error on client mosqsub|29288-raspberry, disconnecting"
What did you do to make the original problem go away.
Does it reconnect?
The only thing I found was that if you change the endpoint address in the sensor settings, the sensor data is transmitted again.
You original problem showed continual connection and reconnection, but that has now stopped apparently. Are you saying you did nothing to fix that?
First, I changed the mosquitto.conf configuration.
For example, I tried adding an allow_anonymous true item or increasing the keep alive setting.
I tried changing the nginx setting, which is executed because the sensor is automatically booted, but the same symptom appeared.
I am confused, first you say that it runs ok for some hours before disconnecting, now you say the original problem (continuous connect/disconnect) is still there.
Please start again. Describe your setup and tell us what the problem is. Without clear information no-one can help you.
I don't understand either.
The problem is that the sensor is connected and not.
In conclusion, there is an endpoint setting in the software provided by the sensor manufacturer, and when it is changed, the sensor data is transmitted again.
In a word, the subscription is suddenly canceled after data comes in.
What versions of node-red and nodejs are you using?