MQTT doesn't seem to be happy of late

[knolleary]

@Trying_to_learn

Do you mean this one?
I've just looked and none of the nodes at which I looked have anything in there.

Yes. That is the Name field.

@Trying_to_learn

On another thing: So how do I then get rid of the list of the same node in the list after I give the node a name?

Right now, you have a list with multiple entries in that you cannot tell apart because they all probably use the IP address as their label.

If you give each a unique name you will be able to tell them apart.

Once you've done that, you can, if you want, edit each mqtt node in your flow and set it to use the same broker config node.

Eventually, you'll have all the nodes using the same config node and the others will be unused. Once they are unused, they can be deleted.

[Colin]

@knolleary

Once they are unused, they can be deleted.

To save having to look at each one, if you change the ip address in the ones you want to delete to something that does not exist then you will more easily see all the ones that use it as they will show the red not connected status.

[krambriw]

@Trying_to_learn

That node (well part of the flow) is duplicated on many machines

Classical error when just copying & pasting without understanding consequences. If you happen to have the same mqtt client id defined for several clients, they will all do reconnects/disconnects all over

I have unfortunately experienced this myself (but it happened before I started with NR)

[knolleary]

@krambriw

Classical error when just copying & pasting without understanding consequences. If you happen to have the same mqtt client id defined for several clients, they will all do reconnects/disconnects all over

But that is only the case if you've manually set the clientid field in the node. By default, that field is blank and uses the node's id as part of the clientid it connects with. When you import a config node, it will get a new node id so it shouldn't cause a conflict.

[Colin]

@knolleary

By default, that field is blank and uses the node's id as part of the clientid it connects with.

That's what seemed odd to me in the log, they appear to be autogenerated client ids and are all from the same ip address.
I wonder whether this effect could be seen if the network keeps dropping out. @Trying_to_learn run in a terminal tail -f /var/log/syslog and see if anything untowards is logged there. I presume you are not seeing any obvious network problems on the machine.

@knolleary

When you import a config node, it will get a new node id so it shouldn't cause a conflict.

If one copied a whole flows file to a different machine and ran it there would you end up with duplicated node ids and so could get duplicated auto generated client ids? Even if yes then this is not the problem here as they are all from the same IP address, assuming that there are not two machines with the same IP address.

[krambriw]

@knolleary

But that is only the case if you've manually set the clientid field in the node

True
(I was more thinking of the rude way of copying parts directly from the flow file in a text editor, maybe not recommended but useful sometimes)

[Trying_to_learn]

Thanks for the replies.

In answer to

@Colin

tail -f /var/log/syslog

pi@TimePi:~ $ tail -f /var/log/syslog
Jan  7 14:38:22 TimePi ntpd[20179]: Soliciting pool server 116.66.161.4
Jan  7 14:38:23 TimePi ntpd[20179]: Soliciting pool server 103.76.40.123
Jan  7 14:38:24 TimePi ntpd[20179]: Soliciting pool server 27.124.125.250
Jan  7 14:38:25 TimePi ntpd[20179]: Soliciting pool server 2406:da1c:b32:4000:b0c5:3cb7:5730:226
Jan  7 14:38:31 TimePi Node-RED[213]: 7 Jan 14:38:31 - [info] [mqtt-broker:24d4eb05.8b883c] Connected to broker: mqtt://192.168.0.99:1883
Jan  7 14:38:31 TimePi Node-RED[213]: 7 Jan 14:38:31 - [info] [mqtt-broker:24d4eb05.8b883c] Disconnected from broker: mqtt://192.168.0.99:1883
Jan  7 14:38:50 TimePi Node-RED[213]: 7 Jan 14:38:50 - [info] [mqtt-broker:24d4eb05.8b883c] Connected to broker: mqtt://192.168.0.99:1883
Jan  7 14:38:50 TimePi Node-RED[213]: 7 Jan 14:38:50 - [info] [mqtt-broker:24d4eb05.8b883c] Disconnected from broker: mqtt://192.168.0.99:1883
Jan  7 14:39:05 TimePi Node-RED[213]: 7 Jan 14:39:05 - [info] [mqtt-broker:24d4eb05.8b883c] Connected to broker: mqtt://192.168.0.99:1883
Jan  7 14:39:05 TimePi Node-RED[213]: 7 Jan 14:39:05 - [info] [mqtt-broker:24d4eb05.8b883c] Disconnected from broker: mqtt://192.168.0.99:1883
Jan  7 14:39:20 TimePi Node-RED[213]: 7 Jan 14:39:20 - [info] [mqtt-broker:24d4eb05.8b883c] Connected to broker: mqtt://192.168.0.99:1883
Jan  7 14:39:20 TimePi Node-RED[213]: 7 Jan 14:39:20 - [info] [mqtt-broker:24d4eb05.8b883c] Disconnected from broker: mqtt://192.168.0.99:1883
Jan  7 14:39:23 TimePi ntpd[20179]: error resolving pool 0.tic.telstra.net: Name or service not known (-2)
Jan  7 14:39:24 TimePi ntpd[20179]: error resolving pool 1.toc.ntp.telstra.net: Name or service not known (-2)
Jan  7 14:39:33 TimePi ntpd[20179]: Soliciting pool server 2403:2500:9000:1::bbb
Jan  7 14:39:34 TimePi ntpd[20179]: Soliciting pool server 2404:cc80:220::220
Jan  7 14:39:35 TimePi ntpd[20179]: Soliciting pool server 2001:19f0:5801:1daa:5400:1ff:fe95:cf80
Jan  7 14:39:35 TimePi Node-RED[213]: 7 Jan 14:39:35 - [info] [mqtt-broker:24d4eb05.8b883c] Connected to broker: mqtt://192.168.0.99:1883
Jan  7 14:39:35 TimePi Node-RED[213]: 7 Jan 14:39:35 - [info] [mqtt-broker:24d4eb05.8b883c] Disconnected from broker: mqtt://192.168.0.99:1883
Jan  7 14:39:36 TimePi ntpd[20179]: Soliciting pool server 2001:418:3ff::1:53
Jan  7 14:39:37 TimePi ntpd[20179]: Soliciting pool server 2001:44b8:60:12::157
Jan  7 14:39:38 TimePi ntpd[20179]: Soliciting pool server 2001:418:3ff::53
Jan  7 14:39:39 TimePi ntpd[20179]: Soliciting pool server 2407:f100:4:1::3
Jan  7 14:39:50 TimePi Node-RED[213]: 7 Jan 14:39:50 - [info] [mqtt-broker:24d4eb05.8b883c] Connected to broker: mqtt://192.168.0.99:1883
Jan  7 14:39:50 TimePi Node-RED[213]: 7 Jan 14:39:50 - [info] [mqtt-broker:24d4eb05.8b883c] Disconnected from broker: mqtt://192.168.0.99:1883
Jan  7 14:40:10 TimePi Node-RED[213]: 7 Jan 14:40:10 - [info] [mqtt-broker:24d4eb05.8b883c] Connected to broker: mqtt://192.168.0.99:1883
Jan  7 14:40:10 TimePi Node-RED[213]: 7 Jan 14:40:10 - [info] [mqtt-broker:24d4eb05.8b883c] Disconnected from broker: mqtt://192.168.0.99:1883
Jan  7 14:40:25 TimePi Node-RED[213]: 7 Jan 14:40:25 - [info] [mqtt-broker:24d4eb05.8b883c] Connected to broker: mqtt://192.168.0.99:1883
Jan  7 14:40:25 TimePi Node-RED[213]: 7 Jan 14:40:25 - [info] [mqtt-broker:24d4eb05.8b883c] Disconnected from broker: mqtt://192.168.0.99:1883
Jan  7 14:40:28 TimePi ntpd[20179]: error resolving pool 1.toc.ntp.telstra.net: Name or service not known (-2)
Jan  7 14:40:30 TimePi ntpd[20179]: error resolving pool 0.tic.telstra.net: Name or service not known (-2)
Jan  7 14:40:40 TimePi Node-RED[213]: 7 Jan 14:40:40 - [info] [mqtt-broker:24d4eb05.8b883c] Connected to broker: mqtt://192.168.0.99:1883
Jan  7 14:40:40 TimePi Node-RED[213]: 7 Jan 14:40:40 - [info] [mqtt-broker:24d4eb05.8b883c] Disconnected from broker: mqtt://192.168.0.99:1883
Jan  7 14:40:55 TimePi Node-RED[213]: 7 Jan 14:40:55 - [info] [mqtt-broker:24d4eb05.8b883c] Connected to broker: mqtt://192.168.0.99:1883
Jan  7 14:40:55 TimePi Node-RED[213]: 7 Jan 14:40:55 - [info] [mqtt-broker:24d4eb05.8b883c] Disconnected from broker: mqtt://192.168.0.99:1883

Checked the flow. None of those nodes are disconnected. All happy green.

But, I am going to have to check a couple of lines with their errors.

[Colin]

Is mosquitto running on the same pi as node-red ( 192.168.0.99 )?
I thought you were going to give all your broker config nodes names so you could more easily identify them, and get rid of duplicates.

[Trying_to_learn]

Hi Colin,

Yes MQTT is on .99

@Colin

I thought you were going to give all your broker config nodes names so you could more easily identify them, and get rid of duplicates.

I'm not sure from where you got that idea. Was it:

@Trying_to_learn

And does that mean I have to do it to ALL MQTT nodes?

Sorry, but I have a very poor imagination and when I build flows I don't name every node.
Their function name is usually suffice.

Be that good or bad, at this stage I have no intention of naming every node differently.

[Colin]

@Trying_to_learn

Be that good or bad, at this stage I have no intention of naming every node differently.

This is specifically about the mqtt config nodes (the ones with the client id in). By naming them then you can more easily see if you have duplicates and the mosquitto and node red logs will be much easier to read if they are named. @knolleary suggested that you do this back in comment #21.

[Trying_to_learn]

Ok...

The "names"......

(My reply #17)
As you may have seen in my screen shots I name the MQTT nodes to their function, but didn't have names given to them to help me know what is either going out of them or coming into them.

In #19 I was told:

@knolleary

To make it easier, edit the broker config node and set its 'name' field - that will be used in the drop-down list if set, rather than having a list of identical-looking entries of the same IP address.

In post #20 I checked the field I need to which I add the name.

The mqtt nodes all have relevant names. As I just said.

I added the name as Nick said. The problem - for now - has gone away.

So, I am still a bit confused in: do I have to open all my mqtt nodes and change the broker id to the "new" one for which I have just created a name?
Which is the same as (all) the existing ones in the list, but different in that it is a name and not the same IP number repeated in a big list.

[knolleary]

@Trying_to_learn

do I have to open all my mqtt nodes and change the broker id to the "new" one for which I have just created a name?

This not complicated. I'm sorry, but it really isn't.

You have multiple mqtt-broker nodes all pointed at the same broker. That means you have multiple connections going from Node-RED to the broker.

I suggested you may want all of your MQTT nodes use the same connection. To do that, you would need to ensure all your MQTT nodes use the same mqtt-broker config node.

To help you do that, I suggested you name the mqtt-broker config nodes. Why did I do that? Because without a name, you'd have a dropdown-list of entires all saying 127.0.0.1 - or whatever IP address your broker is on. That would make it hard to ensure you picked the same config node each time. You could pick just one of the broker config nodes, set its name field to 'USE THIS ONE' - and then edit your MQTT nodes and ensure 'USE THIS ONE' was selected in the dropdown.

Once you had all of the MQTT nodes using that config node, you'd be able to delete the now-unused config nodes.

But you don't have to do any of this. It was merely a suggestion to simplify your flow a bit. If you still don't understand what I'm trying to explain, then don't worry. If your flows are working, then great.

[Trying_to_learn]

Nick,

(Yikes)

Thanks.

I too was only asking so I know/understand it in my mind before I set off and do something which may or may not need to be done.

I probably will put that in the list of things to do though because if it will get rid of the multiple lists of the same one in the drop down, then: good.

[TotallyInformation]

I've been through that exercise myself more than once over the last few years. Especially if you end up doing export/import of flows including MQTT nodes as the config nodes will be copied and brought over as well.

You want to aim for 1 single config node though you may later end up with a couple due to requiring different settings even though it is the same broker. And absolutely, the configs should be well named.