Scenario with MQTT nodes - No message received on debug node

Hi all,
I've build a NODE-RED flow with the following nodes:
1 node type INJECT
1 node type MQTT_OUT connected to SCP Cloud Platform IoT with TLS v1.2
1 none type MQTT_IN connected to SCP Cloud Platform IoT with TLS v1.2
1 node type DEBUG

The node INJECT sends a message with body JSON to node MQTT_OUT wich sends a MQTTS message to SCP Cloud Cloud Platform IoT. I see the message on IoT service cockpit.
The node MQTT_IN should be in listening on topic measures/# and send the message to node DEBUG but no message is received on the node DEBUG.
Nodes MQTT_IN and MQTT_OUT are both in connected state on port 8883.

The flow is reported below.
Please let me kow how to fix the issue.
Thank you.
Best regards.
Luigi Alboino

[{"id":"29f2095.76830f6","type":"tab","label":"Scenario Predictive Arima New - Node RED","disabled":false,"info":""},{"id":"26cc1407.e5326c","type":"mqtt in","z":"29f2095.76830f6","name":"Predictive_DF_Arima_New","topic":"measures/#","qos":"0","broker":"d6943a77.d06468","x":320,"y":200,"wires":[["c2fd9c8f.e1ed2"]]},{"id":"c2fd9c8f.e1ed2","type":"debug","z":"29f2095.76830f6","name":"Messaggio MQTT2","active":true,"tosidebar":true,"console":true,"tostatus":false,"complete":"payload","x":680,"y":200,"wires":[]},{"id":"70bdea82.759514","type":"inject","z":"29f2095.76830f6","name":"Device Predictive_DF_Arima_New","topic":"measures/386a6bac5ab9b137","payload":"[{\"capabilityAlternateId\":\"1701ccb4d05f3340\",\"sensorAlternateId\":\"c945befbb2737b89\",\"measures\":[{\"pieces_actual\": \"5\",\"time_forecast\": \"2019-09-04T13:30:15.123Z\",\"id_ordine\": 100000099, \"target_quantity\": 6000}]}, {\"capabilityAlternateId\":\"3f45db1218615d46\",\"sensorAlternateId\":\"c945befbb2737b89\",\"measures\":[{\"pieces_forecast\": \"7\",\"time_forecast\": \"2019-09-04T13:30:15.123Z\",\"id_ordine\": 100000099}]}, {\"capabilityAlternateId\":\"5df9154e7f90ae79\",\"sensorAlternateId\":\"c945befbb2737b89\",\"measures\":[{\"pieces_forecast_lowerbound\": \"2\",\"pieces_forecast_upperbound\": \"9\",\"time_forecast\": \"2019-09-04T13:30:15.123Z\",\"id_ordine\": 100000099}]}, {\"capabilityAlternateId\":\"e8467c8eefa7b1c1\",\"sensorAlternateId\":\"c945befbb2737b89\",\"measures\":[{\"rotate_actual\": \"400\",\"time_forecast\": \"2019-09-04T13:30:15.123Z\",\"id_ordine\": 100000099}]}, {\"capabilityAlternateId\":\"c49164248b1b3f27\",\"sensorAlternateId\":\"c945befbb2737b89\",\"measures\":[{\"rotate_forecast\": \"440\",\"time_forecast\": \"2019-09-04T13:30:15.123Z\",\"id_ordine\": 100000099}]}, {\"capabilityAlternateId\":\"0fc690e347856dae\",\"sensorAlternateId\":\"c945befbb2737b89\",\"measures\":[{\"rotate_forecast_lowerbound\": \"340\",\"rotate_forecast_upperbound\": \"540\",\"time_forecast\": \"2019-09-04T13:30:15.123Z\",\"id_ordine\": 100000099}]}]","payloadType":"json","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":340,"y":100,"wires":[["4dee48a.68b90b8"]]},{"id":"4dee48a.68b90b8","type":"mqtt out","z":"29f2095.76830f6","name":"IoT Service Preditive_DF_Arima_New","topic":"measures/386a6bac5ab9b137","qos":"","retain":"","broker":"d6943a77.d06468","x":770,"y":100,"wires":[],"inputLabels":["1"]},{"id":"d6943a77.d06468","type":"mqtt-broker","z":"","name":"IoT Service Preditive_DF_Arima_New","broker":"","port":"8883","tls":"fa8a7c9f.6fc9d","clientid":"386a6bac5ab9b137","usetls":true,"compatmode":true,"keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","closeTopic":"","closeQos":"0","closePayload":"","willTopic":"","willQos":"0","willPayload":""},{"id":"fa8a7c9f.6fc9d","type":"tls-config","z":"","name":"IoT TLS Config for Preditive_DF_Arima_New","cert":"C:\\Users\\lalboino\\Desktop\\Desktop\\Progetti_finanziati_regione_Puglia\\Device_Predictive_DF_ARIMA_NEW\\Predictive_DF_Arima_New-device_certificate_chain.pem","key":"C:\\Users\\lalboino\\Desktop\\Desktop\\Progetti_finanziati_regione_Puglia\\Device_Predictive_DF_ARIMA_NEW\\Predictive_DF_Arima_New-device_certificate_priv.pem","ca":"C:\\Users\\lalboino\\Desktop\\Desktop\\Progetti_finanziati_regione_Puglia\\Device_Predictive_DF_ARIMA_NEW\\certificate_iot_sap_CF_Exprivia.pem","certname":"","keyname":"","caname":"","servername":"","verifyservercert":false}]

Hi Luigi, can you please post your flow again following the instructions in this post? How to share code or flow json

Hi Afelix, I've inserted backticks between the json flow.

I hope the forum software didn't eat any of the characters like it does when editing like this... Going to see if I can see how you set up your debug nodes, will reply in a minute.

Okay what I can see now which I couldn't from the original way you posted the flow is that you only have exported the MQTT-In node. Can you export your flow again, and before select (drag around) the nodes that are related, such as the MQTT-In, and the debug nodes connected to it? Say those nodes you mentioned in your first post, the inject, mqtt-out, mqtt-in, and the debug node.

Right now I can only see that you have an MQTT-In node, with inside the broker and the locations where those certificates are on your computer. I'm unable to tell you anything with just that info I'm afraid :slight_smile:

Hi Afelix.
Sorry, now I've copied the whole node-red flow.
Please chek again.
It looks like the no message is received by node MQTT_IN even though the message is sent from node MQTT_OUT to SCP IoT.
Thank you.

There are MQTT clients for iOS and Android have you tried connecting one of those to your broker to ensure that they can receive something?

Hi Luigi,
I just tested your flow, setting the connection to my own local broker. Works exactly as it should. Have you tested the connection itself to your broker without node-red? For example by using a tool like MQTT Explorer?

MQTT Explorer v0.2.0 - MQTT swiss-army-knife
Setting up a connection in advanced mode should allow you to connect with TLS and local certificates with it. See if you can get it there to work first. if you press the inject button in Node-RED, you should see it appear in

Scratch that, I'm seeing in your opening post that you can already see it in the service cockpit... Based on those combinations and what I'm seeing here it should work, especially as your MQTT nodes show as connected.

Your flow shows that you have a folder on your desktop that is called Desktop. Is that folder indeed there? Take a look at the following reported issue on the MQTT core node and see if it applies to your situation, that would explain what you're seeing:
It uses the following path: C:\Users\lalboino\Desktop\Desktop\Progetti_finanziati_regione_Puglia\Device_Predictive_DF_ARIMA_NEW\Predictive_DF_Arima_New-device_certificate_chain.pem
Where C:\Users\<name>\Desktop is the normal path on Windows installations for the user's Desktop, so an additional Desktop in the path is something I notice :slight_smile:

In the meantime mentioning @knolleary for a potential bug as that issue never got responded to.

Hi Afelix,
yes I've a folder named Desktop on my desktop so the path should be correct.
I notice that if the nodes MQTT are configured on localhost both with 1883 the scenario works.
The MQTT_IN node listens on port 1883 while MQTT_OUT publish on the same port.
The problem rises when the nodes MQTT are configured on remote server with port 8883 ad TLS active.
In this case MQTT_IN should listen on port 8883 and MQTT_OUT publishes on the same port but the flow does not work.
I see that MQTT_OUT publishes the message on port 8883 but MQTT_IN does not catch it.

Hi @mirou_IoT,
I believe it would be better if you created a new topic for your issue. I can’t see how it is related to MQTT nodes with tls v1.2 not passing through messages.

1 Like

Different approach trying to figure out what's going on. Seeing how this exact setup work with a broker that's not set to a different port or using tls v1.2 it just works, it's worth figuring out what happens here... You mentioned being able to see the message in the IoT service cockpit. Are you able to use that same tool to send messages too? If so, can you try adding an MQTT-in node set to a testing topic, something like mqqt/test/nodered/debug or something equally unique that it won't get used for other things. Then publish something, not through node-red, but from a different tool, maybe the IoT service cockpit or an mqtt viewer like MQTT Explorer (the crossed out link from my earlier post). Payload doesn't matter, but see if it arrives in node-red when not using a wildcard topic first, see if it comes through on your broker configuration.

Something odd is going on here, either we're both missing vital clues, or it's something else. I'm not experienced enough with TLS protocols to dive into the code to see if I can spot something there, so I'm just approaching this from my test engineering days.

If you tried defining a MQTT-IN to listen on port 8883?

@zenofmud Based on the flow posted they use the same broker in both nodes, so that's not the issue. If you change the broker for both the nodes to a local broker with port 1883 and no tls it works fine. Which makes it a difficult situation :thinking:

Good Morning,

I've the same situation here: no debug messages
Running Node-RED + Mosquitto MQTT on the same Mac mini
• 1 Inject node
• 1 mqtt-out node set to localhost (no security for now)
• 1 mqtt-in node set to localhost (no security for now)
• 1 msg.payload debug node

[{"id":"d07a7475.6e9568","type":"debug","z":"217d4e8b.384e1a","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","x":1270,"y":1140,"wires":[]},{"id":"67dac90.0175cb8","type":"mqtt in","z":"217d4e8b.384e1a","name":"","topic":"stateTest","qos":"0","datatype":"auto","broker":"1d54e4e6.76fc53","x":820,"y":1340,"wires":[["d07a7475.6e9568"]]},{"id":"3b89553e.22f2b2","type":"mqtt out","z":"217d4e8b.384e1a","name":"","topic":"","qos":"","retain":"","broker":"1d54e4e6.76fc53","x":670,"y":1320,"wires":[]},{"id":"56fc9efb.2219c8","type":"inject","z":"217d4e8b.384e1a","name":"","topic":"stateTest","payload":"TEST","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":500,"y":1380,"wires":[["3b89553e.22f2b2"]]},{"id":"1d54e4e6.76fc53","type":"mqtt-broker","z":"","name":"","broker":"localhost","port":"1883","clientid":"Server","usetls":false,"compatmode":true,"keepalive":"60","cleansession":false,"birthTopic":"","birthQos":"0","birthRetain":"false","birthPayload":"","closeTopic":"","closeQos":"0","closeRetain":"false","closePayload":"","willTopic":"","willQos":"0","willRetain":"false","willPayload":""}]

==> Mosquitto console does reflect the connection: New client connected from as Server (p1, c0, k60).
==> An opened Terminal subscribed to "mosquitto_sub -t stateTest" does output the message injected using Node-RED --> "TEST"

==> Issue: Node-RED Debug panel never prints out anything :frowning: Note that I don't see "connected" under the mqtt node, so even this status is not reported.

That’s quite interesting, as the flow from the opening post does work when it is set to a local broker like that. I don’t have a computer at hand at the moment to test your flow, but can you please post your version numbers and the platform you run on?

So version of Mac OS, version of node-red, version of NodeJS, version of NPM.

Just reading the flow shows you have them set up to use one and the same broker, and I’m not seeing anything odd so far yet, beyond that it’s set to reuse the session, though that should not cause this as far as I know.

Try two things

  1. remove the client ID and try
  2. change the server from 'localhost' to the actual IP address

@afelix :
macOS: 10.13.6
Node-RED: 0.20.7
NodeJS: 12.10.0
NPM: 6.11.3

@zenofmud : not a single change by removing Client ID and setting IP.

Ohhh you are on an unsupported version of node.js - version 10.x is the latest version supported. That might be an issue, I'm running v10.15.3

I have a mac mini runing NR - what did you use to install mosquitto on the mac? (mine is on a Pi ZeroW)

brew install mosquitto :slight_smile:

Well I just installed mosquitto and ran your flow with no changes and it works fine. I'd suspect the node.js version. You might want to downgrade

1 Like

(After some sweating at downgrading node ==> nothing was working anymore, and blablabla…)