How can I find out *who* is publishing a message in MQTT?

I have MQTT explorer installed and running.

I am getting 3 message being published every..... so often, that are no longer needed.

Their TOPICs are STATUS/(device name)
They aren't retained and if I delete them, they come back fairly quickly.

I can't find a node (MQTT OUT) with that in the topic field.
So the device name is set before it gets to the node.
(And probably the whole topic.)

Yes, not really Node-red's problem.

I'm just looking for help to find who is sending the messages.


This is a screen shot - just to show you.

(red areas)

So I have 3 messages. Topics: STATUS/BedPi, STATUS/TelePi and STATUS/TimePi
The value changes - up and down - with each message.

So, thought 1:
STATUS/BedPi shouldn't be hard to find if I search for it in a MQTT OUT node.
All 3 machines searched. NOTHING!

Ok, not to be outdone:
Search for STATUS in MQTT OUT nodes and back track from there.

Nothing exciting there either.

I guess last option is to search for all topic empty MQTT OUT nodes and back track from them.

Open the search in flows and search for the topic, you should see all nodes with that content


Alas I seem to be missing something there.

Here is an example in pictures.

Screenshot from 2023-10-03 14-56-03

If I add BedPi to it (being it I am on that machine) I get no results.


It has to be an OUT node.

2 visible.

This isn't it. It only sends stuff if an IFF message is received. There aren't any going around.

And the last/second one:

Wrong extra stuff on the topic. :frowning:
I tried the other thing I mentioned.

No luck there either.

You sure it is from Node-RED it is published? I remember you also had some Pythonn scripts, could it be one of those?? Or some other sw

1 Like


No, not from python.

The old structure is the message was sent with the device's name to identify who sent it.

I've re-written the code and that/those message are no longer needed.

It isn't important to leave it, but to try and be tidy.

I'm trying to remove it from the echo system.

the python scripts were to control NeoPixel LEDs and send messages to a local LCD on the same machine. (That machine isn't online now anyway.)

It will not be simple to figure out if you have a complex setup with many publishers involved, you will in that case have to manually go through all

See also this:


I think I will have to find some time and disable flows and see if/when it stops.

If you know it is coming from a Node-RED instance, one way could be to search each flow file for the topics you are looking for. Use a text editor and do the search

But I fear the topic is not really defined.

It is constructed.

STATUS + global.get("myDevicename")

But if there are any spaces between the STATUS the + and the global.get() will make it harder.

How many search hits do you get for "myDevicename"?

Presumably one hit is where msg.topic is constructed for mqtt, either a function or a change node.

1 Like

Well, this is the result:

Screenshot from 2023-10-03 17-03-04

So 14 isn't impossible.

BUT - ooooh!

After a bit of digging....

I think I found it.

Alas it wasn't what I thought it was. :frowning:
But thanks for suggesting it @jbudd .

I had done it but hadn't dug this deep.


Alas it is something else so I can't delete it.

If someone REALLY did need to add traceability to your publishers, then MQTT V5 can help here.

You can add extra info in the publish packet WITHOUT affecting the original payload.


You can even supply the userProperties via the msg



That's good to know.

Honestly though I guess it was me who didn't name the topic as well a I should.
But I guess that is all part of actually learning.

I've re-written/structured a fairly big part of the working of my 3 main machines and their comms of what is going on with things.

Probably about 1 full day of man hours work.

And ITMT a fairly serious bit of Arduino programming done on another project.
Structures crossed up and mistaken between the languages.

How easy is it to install?
(Just since we are here)

you already have MQTT v5. Just select the option on the broker config node.

(assuming you are using a recent enough broker like Mosquitto v2+ which supports V5)

No, 3.11 :frowning:

Ah, Ok, select Version 5 in the drop down.


@Steve-Mcl without straying too far off topic... should users be generally using v5 by default now, even if they are not using its advanced features?

...and how does v5 affect external devices, such as Shellie's, etc.

It has other benefits like richer error reporting (so when something goes skewwhiff there is a chance you know why). Also, when you sub to multiple same topic, you dont start getting mutiple subs where you expected 1. It is also faster in cases where topic aliases are used. However, I dont think 3.11 is going anywhere just yet.

Most (if not all) brokers that support v5, also supports 3.11, so if the shellies only support 3.11, they can still play alongside your v5 connected Node-REDs


I really must update all of my flows to use this!

Though sadly, MQTT Explorer has never been updated to work with MQTT v5 so it would be hard to easily see the extra data.

Previously, I've always got round this issue by making sure that the output topic also has sub-topics that say where and when the topic update came from.


1 Like

I still use MQTT explorer but my other go-to is improving lots (has MQTT v5 as well):


Yes, I've just tried that. But it has a major flaw - it does not show a topic hierarchy like Explorer does which is a pain if you are trying to oversea your whole broker - this is what Explorer excels at. So you can't really monitor anything that has a high volume of updates very easily.

Looks like I need to revisit some ideas I had previously about creating something in Node-RED. :slight_smile: