Node-Red integration with microPython ESP8266 via MQTT

I'm interested in linking an ESP8266 running microPython with Node-Red on Windows 10 PC via MQTT protocol. My initial question is can a single Node-Red app running on the PC function both as an MQTT broker and a client, or would I need two instances of Node-Red?

The MQTT broker is a different thing to Node-Red and you should be able to run both on a PC.

As @Trying_to_learn says, it is best to use a separate MQTT broker. Mosquitto is the one most commonly used.

It depends what you want to do with your esp data, but it makes sense for your mqtt broker to be running 24/7.
Since my pc is only switched on when I'm looking at it, I run mosquitto, mysql and node-red on a raspberry pi with no screen or keyboard.
Data continues to be exchanged and logged, devices are managed etc while the pc is off.

And there is an mqtt broker which runs in Node-Red, Aedes. It has less capability than mosquitto but it's easier to install. I have not run it or node-red on a pc though.

jbudd

The PC that I'm using runs 24/7 so from what you say I should be able to run Broker & Client through Node-Red. Would you recommend that I run two separate Node-Red instances, as opposed to one?

Also, I have read about references to Mosquitto, but generally associated with Raspberry-Pi. However, in checking their website I see they do have a version for Windows.So I suppose I could go that route, having Mosquitto as the broker, and Node-Red as a client on the same PC.

Thanks, X.

If you really want to use a broker built into node red (which I advise against) then you only need one node-red instance. The server node is completely separate from the client nodes.

If you install mosquitto then in order to allow access from external devices (such as the ESP) then you need to edit the mosquitto configuration file and add to the end

listener 1883
allow_anonymous true

Thanks for the information; it looks like Mosquitto is the way to go for a broker. I'm actually revisiting the use of MQTT for my application as I don't see the need for peer-to-peer communication. In my application, clients only need to interact with the server, not with each other.

MQTT isn't peer to peer, it is peer to mqtt server (broker).

MQTT makes communication between devices so much simpler, even if the broker runs on one of the devices sending and receiving data.

I don't understand why you are considering two Node-Red instances.
It doesn't matter where the MQTT broker is, so long as each device can connect to it, they can exchange data. If it's on the PC your Mqtt-In node is just set to connect to Localhost.

The device which runs the broker should have a static IP.

Colin, I understand, I know peer-to-peer implies direct communication while MQTT is essentially a STAR topology. But, if you consider the broker as transparent, to the peers it seems like a peer-to-peer network; that's all I meant.

jbudd, With both broker & client running in the same application, and not knowing exactly how Node-Red is internally implemented, I was concerned about potential conflict resolution issues if both disparate functions were simultaneously running in the same app. Having the broker in one instance, and the client in another would allow the OS to manage conflicts. UPDATE: Correct me if I'm wrong, but It appears that Node-Red is a client of a Node.js server. If that's the case having separate client instances may not matter.

Regarding MQTT, given it's advantages, I've decided to stick with that approach.

There shouldn't be a conflict, except for system resources. By running the broker in the node-red process you are removing resources from node-red. It is better to run it in a separate process.
Also Aedes does not support Retained topics, which is a significant feature.