MQTT to cloud server

I have node-red running on a raspberry pi and about a half dozen esp32 devices with temp sensors and a couple acting as remote IO.... that has been working for quite a while. I just created a sever on digital ocean also running node-red. Trying to communicate with it via MQTT... no security at this point. I'm just using MQTT out node on the raspberry pi and MQTT in node on the cloud server. I've tried several variations on the MQTT out node on the raspberry pi but keep getting missing broker configuration. Is this doable or is there more to it than that.

Show us how you have configured the mqtt broker node and also the exact error that you see.

I'm using the actual ip address of the cloud server

Which node is the one giving the error, node 5abce... ?

Click on the node id in the debug pane and it should take you to it, or use the search feature (Ctrl+F).

Also which versions of node-red and nodejs are you using. The command
node -v
will tell you the nodejs version. The node red version is at the bottom of the dropdown menu in the editor.

Sorry I had an unconfigured node that was giving the error... got rid of it and got rid of the error.
It just does not connect.

nodejs v18.12.1
node-red 3.0.2


Try to tick the TLS box

Also, I assume you have configured settings in the Security tab correctly??

Install the very useful tool MQTTExplorer on one of your PCs and make sure you can connect to your broker using that.

I had just created the server on digital ocean and the default for mosquitto is local access only which was preventing the connection. My first attempt at running node red on a cloud server. I ended up using one of the esp32 devices configured to connect directly to the cloud server and monitoring it via thonny on raspberry pi.. it had code which would continually retry the connection to the broker if it was not successful. I did search for some utility to test connection to the broker and tried Paho MQTT Python Client running on the the thonny IDE but the esp32 seemed to be the easiest. I will try the MQTTExplorer.

I have a bit of a follow up and you can comment if this should go under a new topic. On my local network I have multiple esp32 devices and most have temperature sensors. I used an inject node to send a sync signal and the esp32 devices publish the temps when they receive this. I can also send msg to turn on or off IO pins on the esp32 devices. I read that once established the broker connection is bi directional. My esp32 device does connect to the cloud broker and publishes the temp every 30 seconds... but it does not respond to the sync msg from the cloud broker. My guess is that msg is not coming back through to my local network.

As I suggested previously:

Then you won't need to guess, you will know for certain whether it is coming back or not.

I did install it already... just haven't got that far

Another thing to considder is the code in your ESP32. If you have a "sleep" of some sort in your code then the ESP32 may not recieve the update request. Just a thought. I had this problem with my first weatehr station based on ESP8266.

Is your ESP32 actually subscribed to the topic that this message is being sent on?


I'm currently on the road but the esp32 is subscribed to the topic... dont really use sleep mode... I have code that would echo and print the msg in the IDE if it received a msg on that topic... the MQTT explorer does show the sync msg on the remote_io topic... I'm not sure that means its being received on my local network or just that it is being sent by the server on the cloud. It also shows a msg from the esp32 as well as a msg from node red on the raspberry pi.

Took some time off to go look at a sailboat in Charleston SC... I added a node on the raspberry pi to subscribe to the remote_io topic on the cloud server and that was working so I went back to the ESP32 and had some errors there was preventing responding to the remote IO sync msg... cleared that up and everything is working as it should. Thanks for every ones patience and support.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.