MQTT Node exhibits instability

I'm having what appears to be stability problems with the MQTT_out node. I have two issues:

  1. My flow appears to work and then at some point it loses connectivity (the green indicator turns red) and of course the flow ceases to work. If I make the slightest change, like adding a space in a comment line in an associated function node and "deploy", it connects and works again??
  2. The MQTT node show that it's connected (green indicator) but messages are neiher sent nor received.

Are you using the built-in MQTT nodes?

Do you have more than one broker connection in the drop-down selector?

Did you enter a client ID in the settings of the broker connection?

What type of deploy do you do (full, flows or nodes?)

What versions of node.js and node-red are you using?

What broker are you connecting to? Is it AWS or self-hosted or mosquito or? ???

Also look in the node red log to see what it shows.

Hi Steve,

  1. I'm using the Mosquitto broker on a pi zero-2W
  2. To fill in the picture, I'm trying to connect to a Shelly-1, which I have enabled for MQTT pointing to my pi IP_Add:1883. If I check the MQTT log I see that the Shelly1 is connected.
  3. I've used both modified flow and full deploy. Keep in mind that it sometimes works.
  4. Node.js is V14.21.3 and NodeRed is: node-red V3.0.2 on linux 5.15.84
  5. Mosquito

I

You don't seem to have answered all Steve's questions, nor shown us the log. You can see the log by running
node-red-stop
node-red-start

A couple more questions:

  1. Is Node-red running on the same Raspberry Pi as Mosquitto or somewhere else?
  2. Does the MQTT config point to 127.0.0.1 or to the Pi's LAN IP?
1 Like

This is no longer a valid version of node.js. Please update to a current version. v18 as a minimum. Best to update Node-RED at the same time.

`Here is the log after a node-red start:

'''pi@wrapit-hub:~ $ node-red start
31 Jan 22:21:45 - [info]

Welcome to Node-RED

31 Jan 22:21:45 - [info] Node-RED version: v3.0.2
31 Jan 22:21:45 - [info] Node.js version: v14.21.3
31 Jan 22:21:45 - [info] Linux 5.15.84-v7+ arm LE
31 Jan 22:21:46 - [info] Loading palette nodes
31 Jan 22:21:52 - [info] Dashboard version 3.6.5 started at /ui
31 Jan 22:21:53 - [info] Settings file : /home/pi/.node-red/settings.js
31 Jan 22:21:53 - [info] Context store : 'default' [module=memory]
31 Jan 22:21:53 - [info] User directory : /home/pi/.node-red
31 Jan 22:21:53 - [warn] Projects disabled : editorTheme.projects.enabled=false
31 Jan 22:21:53 - [info] Flows file : /home/pi/.node-red/start
31 Jan 22:21:53 - [info] Creating new flow file
31 Jan 22:21:53 - [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.

31 Jan 22:21:53 - [warn] Encrypted credentials not found
31 Jan 22:21:53 - [error] Uncaught Exception:
31 Jan 22:21:53 - [error] Error: listen EADDRINUSE: address already in use 0.0.0.0:1880
at Server.setupListenHandle [as _listen2] (net.js:1331:16)
at listenInCluster (net.js:1379:12)
at doListen (net.js:1516:7)t`
at processTicksAndRejections (internal/process/task_queues.js:83:21)'''

Also attached is the Mosquito log:
Mosquitto Log.txt (15.1 KB)

  1. NodeRed and Mosquitto running on the same pi.
  2. localhost:1883

That may be the case but it's been running fine to date. I will do but would like to undersdtand why this problem is intermittent.

I'm also attaching my flow. I'm demonstrating two methods of controlling the Shelly1 device:

  1. using http to push commands to the Shelly1 IP address, which works just fine, and
  2. using MQTT, which is intermittent as described earlier.
    Now, as I said this has worked before.
    Shelly1 Flow.json (14.3 KB)

I had a problem with Node-red continually disconnecting from Mosquitto.

I don't know if it's the same as your issue but I was on Node-red 3.0.2, the problem went away with NR 3.1.

Oh, look, you are on 3.0.2!

Your node.js is out of date, your Node-red is out of date and your Linux is out of date.
Your Mosquitto might be out of date too - mine is 2.0.11 but I'm not sure if that's up to date either

You could update the OS with sudo apt update && sudo apt -y full-upgrade, then re-run the NR installation script to update node.js and Node-red.

Alternatively get a new uSD card, burn the latest RPiOS 64 bit, install Node-red, Mosquitto and any other services then transfer your flows.

1 Like

You did not run node-red-stop first to stop node-red. It fails to start up again because the current one is using the port. Stop it then start it again so we can see the mqtt messages.

Yes, I realise that an update is well overdue but this system is part of an existing installation with one purpose only; to run the nodered environment to control monitor a few devices. There was no need for an upgrade (if it aiIt' broke ...) and it's been working fine with no problems but this new flow has been giving me grief. I will do an upgrade but first would like to understand what's been going on. The MQTT flow was working at som point and the green indicators show that's it's connected to the broker ???

I thought that I did but I'm attaching a new log with Mosquitto log as well.
Mosquitto Log2.txt (13.9 KB)
Node-red Startup Log.txt (13.9 KB)

I sympathise with you.

The best reason to update a system is so that the first response to a problem can't be "You need to update".

You might find clues in the code changes for NR 3.1 and the issues it refers to.
Or not, because we don't know if you see the same problem.

Yes Jbudd, I do fully agree. I was hoping that someone might be able to see something that I've missed. It's strange when a flow works and then just doesn't. I'm hoping someone might spot something stupid that I've done.

There is something really STRANGE happening here.
My debug messages are disappearing; I mean they just remove themselves from the debug screen one at a time. I've never seen this before.

If you have a lot of debug messages they will round robin drop off.

You never answered my question if you set a client Id from my original questions. If you did, it could be the reason for instability.

Sorry Steve, I missed that. Yes, I believe I did when I configured the Shelly1 switch. When I pobe it I get the following:

mqtt: object
enable: true
server: "192.168.1.75:1883"
user: "pi"
id: "shelly1-E8DB84D4D51C"
reconnect_timeout_max: 60
reconnect_timeout_min: 2
clean_session: true
keep_alive: 60
max_qos: 2
retain: false
update_period: 0