Broker regularly disconnects and connects?

General
1

Hi,

I am running Node-RED on a RPI, I have noticed that sensors I have around my house sometimes do not work.

On looking at the Terminal screen after i restarted Node-RED ... I see this

Welcome to Node-RED
===================

8 Nov 08:17:36 - [info] Node-RED version: v2.1.6
8 Nov 08:17:36 - [info] Node.js  version: v12.22.12
8 Nov 08:17:36 - [info] Linux 5.15.56-v7+ arm LE
8 Nov 08:17:39 - [info] Loading palette nodes
8 Nov 08:17:45 - [info] Dashboard version 3.1.7 started at /ui
8 Nov 08:17:47 - [warn] Missing node modules:
8 Nov 08:17:47 - [warn]  - node-red-contrib-aedes (0.6.0): aedes broker
8 Nov 08:17:47 - [warn]  - node-red-contrib-mqtt-broker (0.2.9): mosca in
8 Nov 08:17:47 - [info] Removing modules from config
8 Nov 08:17:47 - [info] Settings file  : /home/pi/.node-red/settings.js
8 Nov 08:17:47 - [info] Context store  : 'default' [module=memory]
8 Nov 08:17:48 - [info] User directory : /home/pi/.node-red
8 Nov 08:17:48 - [warn] Projects disabled : editorTheme.projects.enabled=false
8 Nov 08:17:48 - [info] Flows file     : /home/pi/.node-red/flows.json
8 Nov 08:17:48 - [info] Server now running at http://127.0.0.1:1880/
8 Nov 08:17:48 - [warn] 

---------------------------------------------------------------------
Your flow credentials file is encrypted using a system-generated key.

If the system-generated key is lost for any reason, your credentials
file will not be recoverable, you will have to delete it and re-enter
your credentials.

You should set your own key using the 'credentialSecret' option in
your settings file. Node-RED will then re-encrypt your credentials
file using your chosen key the next time you deploy a change.
---------------------------------------------------------------------

8 Nov 08:17:49 - [info] Starting flows
8 Nov 08:17:50 - [info] Started flows
8 Nov 08:17:51 - [info] [sqlitedb:71cf7c5fab68a227] opened /media/pi/Storage/RPI/Database/RPI - Home/Home - V2.00.db ok
8 Nov 08:17:51 - [info] [sqlitedb:61693413682a0187] opened /media/pi/Storage/RPI/Database/TEST/Test - V2.00.db ok
8 Nov 08:17:51 - [info] [mqtt-broker:52789754.032f7] Connected to broker: mqtt://192.168.1.65:1883
8 Nov 08:18:29 - [info] [mqtt-broker:52789754.032f7] Disconnected from broker: mqtt://192.168.1.65:1883
8 Nov 08:18:32 - [info] [alexa-remote-account:45cd036d.732c4c] intialising with the PROXY method and saved data...
8 Nov 08:18:44 - [info] [mqtt-broker:52789754.032f7] Connected to broker: mqtt://192.168.1.65:1883
8 Nov 08:58:29 - [info] [mqtt-broker:52789754.032f7] Disconnected from broker: mqtt://192.168.1.65:1883
8 Nov 08:58:44 - [info] [mqtt-broker:52789754.032f7] Connected to broker: mqtt://192.168.1.65:1883
8 Nov 09:58:29 - [info] [mqtt-broker:52789754.032f7] Disconnected from broker: mqtt://192.168.1.65:1883
8 Nov 09:58:45 - [info] [mqtt-broker:52789754.032f7] Connected to broker: mqtt://192.168.1.65:1883

There seems to be a pattern ?
I then looked at the mosquitto log and found this

pi@raspberrypi:~ $ sudo tail -n20 -f /var/log/mosquitto/mosquitto.log
1667914641: New client connected from 192.168.1.91:22920 as MQTT Module 91 (p2, c1, k15).
1667914670: Client MQTT Module 91 has exceeded timeout, disconnecting.
1667914693: New connection from 192.168.1.90:4918 on port 1883.
1667914693: New client connected from 192.168.1.90:4918 as MQTT Module 90 (p2, c1, k15).
1667914718: Client MQTT Module 90 has exceeded timeout, disconnecting.
1667914790: New connection from 192.168.1.91:5796 on port 1883.
1667914790: New client connected from 192.168.1.91:5796 as MQTT Module 91 (p2, c1, k15).
1667914814: Client MQTT Module 91 has exceeded timeout, disconnecting.
1667914868: New connection from 192.168.1.92:19537 on port 1883.
1667914868: New client connected from 192.168.1.92:19537 as MQTT Module 92 (p2, c1, k15).
1667914892: Client MQTT Module 92 has exceeded timeout, disconnecting.
1667914937: New connection from 192.168.1.91:27126 on port 1883.
1667914937: New client connected from 192.168.1.91:27126 as MQTT Module 91 (p2, c1, k15).
1667914964: Client MQTT Module 91 has exceeded timeout, disconnecting.
1667915085: New connection from 192.168.1.91:26629 on port 1883.
1667915085: New client connected from 192.168.1.91:26629 as MQTT Module 91 (p2, c1, k15).
1667915108: Client MQTT Module 91 has exceeded timeout, disconnecting.
1667915159: New connection from 192.168.1.92:16366 on port 1883.
1667915159: New client connected from 192.168.1.92:16366 as MQTT Module 92 (p2, c1, k15).
1667915186: Client MQTT Module 92 has exceeded timeout, disconnecting.
1667915232: New connection from 192.168.1.91:7078 on port 1883.
1667915232: New client connected from 192.168.1.91:7078 as MQTT Module 91 (p2, c1, k15).
1667915258: Client MQTT Module 91 has exceeded timeout, disconnecting.
1667915270: New connection from 192.168.1.90:1412 on port 1883.
1667915270: New client connected from 192.168.1.90:1412 as MQTT Module 90 (p2, c1, k15).
1667915294: Client MQTT Module 90 has exceeded timeout, disconnecting.
1667915380: New connection from 192.168.1.91:17561 on port 1883.
1667915380: New client connected from 192.168.1.91:17561 as MQTT Module 91 (p2, c1, k15).
1667915408: Client MQTT Module 91 has exceeded timeout, disconnecting.

I do have battery operated modules ( Module 90 ... 91 ... 92 ) that send data every 10 minutes and between that time they sleep. These are in the list above. Client MQTT Module 90 has exceeded timeout, disconnecting. etc

Is this the problem ?
Do i need to change the Keep alive time for the Broker, if so what time too ?

37
37647Ă—559 20.8 KB

Thanks

Gaz

2

It looks like you may be using the same client id for multiple connections. Don't do that.

1 Like
3

Hi Colin where would I find the client ID ?

Thanks

4

Or indeed what client library are you using. As part of the client connection you set a keepalive timeout. The client then has to send that keepalive or it will get dropped. Maybe your library isn't doing that ?

5

I must admit I am confused and I am not good at Node-RED etc.

My Node_RED project has been running successfully for 6 years on a 32bit linux pc and an early version of Node_RED. a guess would be version 0.7 ?

But I wanted to use Grafana so I had to use a 64bit machine, so i moved the project to a RPI 3 and use mosquitto broker and it is set to enable anonymous users.
All seemed to be working well although I didn't check the Node_RED terminal output as it has never been a problem.

But I have a PIR that turns on lights in the evening via Node_RED and ESP-8266.
I noticed recently, sometimes it would not turn ON or be delayed by about 20 seconds.
( Perhaps more noticeable because of the darker evenings, so it may have been doing this before !)

The not turning On or delay I think is caused by Node-RED reconnecting.

As I said this has worked perfectly for 6 years on the other PC.

So I am totally unsure where the problem is ?

Any tests i can do ?

thanks

Gaz ... sorry for the long ramble

6

I doubt if the problem with the PIR is related to the timeout.

Have you changed the battery in the offending device?
Also add a debug node showing the data received from the MQTT node. Set it to Output to the console. Then when it fails note the time and then you can look back in the log to confirm whether nothing was received or if the problem is something else.

7

Hi,

To try to find out the offending items ... overnight I turned off ALL battery operated sensors that communicate with Node_RED.

This morning looking at the mosquitto log I have multiple ...

1667979270: New client connected from 192.168.1.65:33248 as nodered_61d118136924eafd (p2, c1, k15).
1667979836: Client nodered_61d118136924eafd has exceeded timeout, disconnecting.

Using command sudo tail -n20 -f /var/log/mosquitto/mosquitto.log

  1. Where can I find out where Client nodered_61d118136924eafd is located on my system ?
  2. Also what does (p2, c1, k15). mean ?

Thanks for your help so far

Gaz

8

This is an auto-generated clientId from a broker connection in node-red. I think if you look further back in logs you will see a node ID associated with that client ID.

That is not something I've seen. Curious. Is it the name set in the config? Use Ctrl-f and search for that in node-red.

One suggestion would be try upgrading node-red to latest 2.x or better still v3.0.2

9

Hi,

Did search for (p2, c1, k15) and also K15 nothing found.

At the moment i would rather not change too many things like upgrading as it may confuse matters ?
Also this is a good time to find out what all these things mean instead of being a "black box" for me.

Hopefully with all your help we can track down the fault.

If we are stuck I will disable all of my tabs ( i have about 25 with lots of flows ) and see which one if any is causing the problem

I do appreciate ALL of your time to help me.

Gaz

10

A quick update ... I have changed the keep alive from 15 to 60 and after 20 mins, I have not seen any errors ?

45

I will give it another 30 mins then if still OK, I will turn ON my battery operate devices one at a time !

11

60 is the default that I see here. Did you change it away from that?

12

No it was 15 . I wouldn't have changed it from install ... it as i didn't know what it did ?

13

That is odd. If you create a new MQTT node, select Make a new broker, and look in there what is the timeout? You can then just cancel and Undo to remove the mqtt node. No need to deploy.

14

Hi Colin,

Yes is did that and yes it was ... 60

I think because these flows are from 6 years ago and I was using a very old version of Node-RED 0.7 ?
And i just copied across all my flows from then.

It may have been the default a long time ago.

15

Yes, that probably explains it.

16

Hi,

I attached the battery operated devices again, and it's been at least an hour now and no problems.

Thanks to you ALL for your help

Gaz

1 Like
17

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.