B ut the ID is consistent with the Topic that I enter in the MQTT node, ie:
shellies/shelly1-E8DB84D4D51C/relay/0/command
Ok, it's still not clear so I'll say....
If you use the same client Id in more than one client connection you will experience disconnections. In short, don't use the same client Id in your shelly and in the node-red connection settings if you are.
OK, I understand what you're saying now. I'm using a unique client id for each MQTT device, so there should'nt be a problem. So this doesn't explain the strange behaviour. I attach my MQTT log below, which indicates that the Shelly device is connected:
pi@wrapit-hub:~ $ sudo tail -n 200 /var/log/mosquitto/mosquitto.log | grep shelly
[00:22:06]: Client shelly1-E8DB84D4D51C already connected, closing old connection.
[00:22:06]: New client connected from 192.168.1.69:22108 as shelly1-E8DB84D4D51C (p2, c1, k60, u'pi').
pi@wrapit-hub:~ $
What's thw significance and implication of the error on the nodered log:
31 Jan 23:41:51 - [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)
at processTicksAndRejections (internal/process/task_queues.js:83:21)
Node-red runs on port 1880 and the log tells you it is in use. It can only be in-use if something is occupying that port....: node-red. Meaning you are trying to run node-red, while it is already running. Thus you should stop it first, before trying to (re)start it.
The other question Steve asked, which you have also not answered, was
Looking at the node-red log I suspect you have configured an MQTT server node for each device. That is not necessary. You should have just one for each MQTT Broker that you use, so if you are only connecting to mosquitto on the pi then you should have just one. Delete all but one of them (using the node red hamburger dropdown menu - Configuration Nodes) and adjust the mqtt in/out to use that one. Leave the client-id blank.
Also you still have not shown us what you see when you do
node-red-stop
node-red-start
Get rid of all the extra server nodes first though. If that doesn't fix it then show us the stop/start output.
That is confirmation that you have two mqtt server nodes with the same client-id. Note that client-id is the id that node-red uses to connect to mosquitto, not the id of the shelly. Mqtt in and out nodes do not connect to the shelly devices, they connect to mosquitto, and you should only have one server node configured in node red as I explained in my previous post.
Oh, I see what you have done. You have configured the shelly devices thenselves with client ids and then, in node red, configured an mqtt server node for each shelly device also, and given them the same client ids as the shellys. The result is that mosquitto sees the shelly device connect with its id, then it sees node-red connect with the same id, so it disconnects the shelly and connects node-red. Then the shelly reconnects with that id so mosquitto disconnects node-red and connects the shelly, and so on.
The solution is that already posted, have just one mqtt broker node that all your mqtt in/out nodes use and either give it a unique id or leave it blank so that node-red will create a random one.
Hi Colin, I'm not sure that I completely understand your comment but yes you are right on the issue of me specifying two MQTT servers. This was not on the flow that I posted but on another flow in the NodeRed. I thought they were the same but one was entered as localhost:1883 and the other was Localhost:1833 (just the first capital letter). I've changed that now so all are using localhost:1883 and I deleted the unwanted one, as suggested.
However, I don't understand your comment in the last post [27]. The Shelly device requires that you use the ShellyID (it's MAC) and expects MQTT messages to have it's address in the topics together with the device type (relay) and mode (command).
BTW I have already posted the output of when I execute a node-red stop then start at post #14, as attachments. But, I've deletd the aditional broker, rebooted the pi and am posting the new log when I do a n ode-red stop/start. It still shoes the error "EADDRINUSE: address already in use 0.0.0.0:1880" BUT the flow now appears to be stable. So, your analysis was correct but why do I stil the the error?
pi@wrapit-hub:~ $ node-red stop
1 Feb 18:20:21 - [info]
Welcome to Node-RED
===================
1 Feb 18:20:21 - [info] Node-RED version: v3.0.2
1 Feb 18:20:21 - [info] Node.js version: v14.21.3
1 Feb 18:20:21 - [info] Linux 5.15.84-v7+ arm LE
1 Feb 18:20:23 - [info] Loading palette nodes
1 Feb 18:20:32 - [info] Dashboard version 3.6.5 started at /ui
1 Feb 18:20:33 - [info] Settings file : /home/pi/.node-red/settings.js
1 Feb 18:20:33 - [info] Context store : 'default' [module=memory]
1 Feb 18:20:33 - [info] User directory : /home/pi/.node-red
1 Feb 18:20:33 - [warn] Projects disabled : editorTheme.projects.enabled=false
1 Feb 18:20:33 - [info] Flows file : /home/pi/.node-red/stop
1 Feb 18:20:33 - [info] Creating new flow file
1 Feb 18:20:33 - [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.
---------------------------------------------------------------------
1 Feb 18:20:33 - [warn] Encrypted credentials not found
1 Feb 18:20:34 - [error] Uncaught Exception:
1 Feb 18:20:34 - [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)
at processTicksAndRejections (internal/process/task_queues.js:83:21)
pi@wrapit-hub:~ $ node-red start
1 Feb 18:25:47 - [info]
Welcome to Node-RED
===================
1 Feb 18:25:47 - [info] Node-RED version: v3.0.2
1 Feb 18:25:47 - [info] Node.js version: v14.21.3
1 Feb 18:25:47 - [info] Linux 5.15.84-v7+ arm LE
1 Feb 18:25:48 - [info] Loading palette nodes
1 Feb 18:25:54 - [info] Dashboard version 3.6.5 started at /ui
1 Feb 18:25:55 - [info] Settings file : /home/pi/.node-red/settings.js
1 Feb 18:25:55 - [info] Context store : 'default' [module=memory]
1 Feb 18:25:55 - [info] User directory : /home/pi/.node-red
1 Feb 18:25:55 - [warn] Projects disabled : editorTheme.projects.enabled=false
1 Feb 18:25:55 - [info] Flows file : /home/pi/.node-red/start
1 Feb 18:25:55 - [info] Creating new flow file
1 Feb 18:25:55 - [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.
---------------------------------------------------------------------
1 Feb 18:25:55 - [warn] Encrypted credentials not found
1 Feb 18:25:55 - [error] Uncaught Exception:
1 Feb 18:25:55 - [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)
at processTicksAndRejections (internal/process/task_queues.js:83:21)
As already stated. This error means that something else is already using that IP port. Since that port is generally only used by Node-RED, it means that you have another instance of node-red running.
On a linux device, run the command ps -ef | grep node-red to see that after the error, you still have Node-RED running.
Ok I get the following:
pi@wrapit-hub:~ $ ps -ef | grep node-red
pi 347 1 3 18:17 ? 00:01:03 node-red
pi 1815 1616 0 18:48 pts/0 00:00:00 grep --color=auto node-red
What does tha tell us?
The ps command gives you a list of currently running processes ("process status"?)
grep nodered ("global regular expression print", of course!) filters the output to show only those lines of output including "nodered", including the grep command itself.
The first line of output indicates an instance of Node-red is already running.
In addition, it tells us that the parent PID (the id of the service that ran node-red) was 1 which is systemd - e.g. it was run by the startup. And that node-red's pid is 347 which also shows it was started reasonably early in the startup.
In other words, you have a "standard" install of node-red running and if you want to restart it, you should probably do something like sudo systemctl restart nodered.service. Not use the node-red start/stop commands.
Not node-red stop but node-red-stop and the same for start.
If you click the server drop down in one of the mqtt nodes. How many do you see? There should be only one.
Oops sorry about that - thanks. Now I only see one mqtt broker.
Yes, I have the nodered startup on reboot. Are you saying that node-red-stop won't work because it was automatically executed at startup. Just for my understanding, why is that it's still just a process after all?
OK this is what I get now when I run node-red-start ..node-red-stop
pi@wrapit-hub:~ $ node-red-stop
Stop Node-RED
Use node-red-start to start Node-RED again
pi@wrapit-hub:~ $ node-red-start
Start Node-RED
Once Node-RED has started, point a browser at http://192.168.1.75:1880
On Pi Node-RED works better with the Firefox or Chrome browser
Use node-red-stop to stop Node-RED
Use node-red-start to start Node-RED again
Use node-red-log to view the recent log output
Use sudo systemctl enable nodered.service to autostart Node-RED at every boot
Use sudo systemctl disable nodered.service to disable autostart on boot
To find more nodes and example flows - go to http://flows.nodered.org
Starting as a systemd service.
1 Feb 22:51:21 - [info]
Welcome to Node-RED
===================
1 Feb 22:51:21 - [info] Node-RED version: v3.0.2
1 Feb 22:51:21 - [info] Node.js version: v14.21.3
1 Feb 22:51:21 - [info] Linux 5.15.84-v7+ arm LE
1 Feb 22:51:25 - [info] Loading palette nodes
1 Feb 22:51:33 - [info] Dashboard version 3.6.5 started at /ui
1 Feb 22:51:35 - [info] Settings file : /home/pi/.node-red/settings.js
1 Feb 22:51:35 - [info] Context store : 'default' [module=memory]
1 Feb 22:51:35 - [info] User directory : /home/pi/.node-red
1 Feb 22:51:35 - [warn] Projects disabled : editorTheme.projects.enabled=false
1 Feb 22:51:35 - [info] Flows file : /home/pi/.node-red/flows.json
1 Feb 22:51:35 - [info] Server now running at http://127.0.0.1:1880/
1 Feb 22:51:35 - [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.
---------------------------------------------------------------------
1 Feb 22:51:35 - [info] Starting flows
1 Feb 22:51:36 - [info] [remote-access:f9e763c3dbf3f906] Server: nodered02.remote-red.com InstanceHash: p8twv55a965ji9gpubrvg12sbl0hjeub5jbgkjsqrzyx0b9wlwcddxrqptb7k4cg
1 Feb 22:51:36 - [info] Started flows
1 Feb 22:51:37 - [info] [mqtt-broker:139256cf.e38f11] Connected to broker: mqtt://localhost:1883
1 Feb 22:51:37 - [info] [remote-access:f9e763c3dbf3f906] Using nodered02.remote-red.com on port 50561
1 Feb 22:51:37 - [info] [remote-access:f9e763c3dbf3f906] starting ssh process
pi : PWD=/home/pi ; USER=root ; COMMAND=/usr/bin/systemctl status set-tz.service
pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1000)
pam_unix(sudo:session): session closed for user root
The terminal output seems to just stop there and the flow appears to be now working just fine. Should the response to node-red-start finish and show me a terminal prompt at this stage?
You used node-red stop which runs the command node-red telling it to use a flows file called stop. The command to stop the node red service is node-red-stop and the command to start it is node-red-start.
So now, with only one mqtt server node, with it's client-id field empty, is it all working as it should?
Sorry, I never use node-red stop so I don't know if it understands systemd. But it doesn't look like it given the error you are seeing.
@pinode was using node-red stop instead of node-red-stop.
node-red-stop stops the systemd service. node-red-start starts the systemd service, then shows the log on the terminal.
1 Like
