Cannot subscribe to mqtt topics on api.emitter.io server

General
1

I have created a simple flow which contains two sequences. One to send text to a specific mqtt topic on the mqtt://api.emitter.io:8080 server. Another which subscribes to this topic in a more generic way using the syntax /Home/#/ and passes the returned results into the debug node. Note this server requires a topic that has a specific syntax as specified by the emitter. E.G. /topic/ This works great when sending mqtt messages from node-red to the emitter server but I cannot see any response from the emitter after I subscribe to the same topic i.e. /Home/MA/Main/Sensor/Temp/ or a more generic form of the topic. Can you suggest how I can debug what is occurring within the mqtt node which subscribes to this server?

Note: I can publish and subscribe just fine to mqtt://iot.eclipse.org:1883 which does not require a topic prefaced by a user key.

Thanks,
--Eric

2

Can you subscribe using an alternative client, such as mosquitto_sub?

3

Also please post a simple flow consiting of, for example, an Inject, MQTT Out, MQTT In and Debug nodes that show the publish working and the subscribe not.

4

I am running Node Red on a Raspberry Pi 3+ with recently upgraded software. I have setup a
mosquitto_sub session in a terminal via:
mosquitto_sub -d -h api.emitter.io -p 8080 -t 4qvhHk6Atzk2hCkQcfi7n2GuJil9w3bs/Home/MA/Main/Sensor/Temp/

The mosquitto_sub is receiving the mqtt messages just fine.
I also have the MQTTool running on my iPhone and see the temp posted there too.
Node-Red is not receiving anything. ??
Feel free to test it out yourself, if you can. Thanks for your help.

My Node Red example flow is:

[{"id":"f1e33237.f33cc","type":"tab","label":"Basic MQTT Test","disabled":false,"info":""},{"id":"e6f61deb.70ad8","type":"mqtt in","z":"f1e33237.f33cc","name":"","topic":"4qvhHk6Atzk2hCkQcfi7n2GuJil9w3bs/Home/MA/Main/Sensor/Temp/","qos":"0","broker":"a3815803.b22de8","x":341,"y":366,"wires":[["7abdc351.a1bf3c"]]},{"id":"7abdc351.a1bf3c","type":"debug","z":"f1e33237.f33cc","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","x":681,"y":363,"wires":[]},{"id":"50d3b1e4.64793","type":"inject","z":"f1e33237.f33cc","name":"","topic":"4qvhHk6Atzk2hCkQcfi7n2GuJil9w3bs/Home/MA/Main/Sensor/Temp/","payload":"88.0 Deg F","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":119,"y":108,"wires":[["9d97c3a5.30b45"]]},{"id":"9d97c3a5.30b45","type":"mqtt out","z":"f1e33237.f33cc","name":"","topic":"","qos":"","retain":"","broker":"a3815803.b22de8","x":499,"y":110,"wires":[]},{"id":"a3815803.b22de8","type":"mqtt-broker","z":"","name":"Emitter","broker":"mqtt://api.emitter.io:8080","port":"1883","clientid":"","usetls":false,"compatmode":false,"keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","closeTopic":"","closeQos":"0","closePayload":"","willTopic":"","willQos":"0","willPayload":""}]

5

Posted reply. Please see new posting.
Thanks.

6

Please see this post for how to share a flow. As it is it is not importable. Edit your previous post so we can try it.
https://discourse.nodered.org/t/how-to-share-code-or-flow-json/506/4

7

However I can see from just looking at the text that this looks wrong. In the mosquitto_sub command you have specified host as api.emitter.io and port as 8080, whereas in the flow you appear to have specified the host as mqtt:://api.emitter.io:8080 but I would have expected it to be just be api.emitter.io and the port as 1883 whereas it should be 8080.

8

Ok I corrected the setup by eliminating the port specification. The problem is still as described in the previous post.

The flow is now:

[{"id":"f1e33237.f33cc","type":"tab","label":"Basic MQTT Test","disabled":false,"info":""},{"id":"e6f61deb.70ad8","type":"mqtt in","z":"f1e33237.f33cc","name":"","topic":"4qvhHk6Atzk2hCkQcfi7n2GuJil9w3bs/Home/MA/Main/Sensor/Temp/","qos":"0","broker":"a3815803.b22de8","x":341,"y":366,"wires":[["7abdc351.a1bf3c"]]},{"id":"7abdc351.a1bf3c","type":"debug","z":"f1e33237.f33cc","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","x":681,"y":363,"wires":[]},{"id":"50d3b1e4.64793","type":"inject","z":"f1e33237.f33cc","name":"","topic":"4qvhHk6Atzk2hCkQcfi7n2GuJil9w3bs/Home/MA/Main/Sensor/Temp/","payload":"88.0 Deg F","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":119,"y":108,"wires":[["9d97c3a5.30b45"]]},{"id":"9d97c3a5.30b45","type":"mqtt out","z":"f1e33237.f33cc","name":"","topic":"","qos":"","retain":"","broker":"a3815803.b22de8","x":499,"y":110,"wires":[]},{"id":"a3815803.b22de8","type":"mqtt-broker","z":"","name":"Emitter","broker":"mqtt://api.emitter.io:8080","port":"","clientid":"","usetls":false,"compatmode":false,"keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","closeTopic":"","closeQos":"0","closePayload":"","willTopic":"","willQos":"0","willPayload":""}]
9

I don't know whether that has any chance of working, but normally, as I said in my previous post the broker would be api.emitter.io (not mqtt://api.emitter.io:8080) and the port would be 8080 (not empty).

10

If I set it up that way I can see in the terminal window that Node-Red fails to connect to the emitter server. But if I set it up as noted in the posted flow it will successfully connect to the server. I just can't seem to receive subscribed topic data.
Is there any other way to debug what Node Red is doing?

Thanks.

11

It connects fine for me specifying the port in the correct field (are you sure you are specifying port 8080 and not 1883?). See flow below. However, you are right the MQTT In node does not see published data whereas mosquitto_sub does, so it must be an issue with the MQTT In node. I suggest raising an issue at https://github.com/node-red/node-red

[{"id":"5c7ec7bf.a46778","type":"inject","z":"a04da025.0d514","name":"","topic":"4qvhHk6Atzk2hCkQcfi7n2GuJil9w3bs/Home/MA/Main/Sensor/Temp/","payload":"88.0 Deg F","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":119,"y":108,"wires":[["b1531acb.579c88"]]},{"id":"b1531acb.579c88","type":"mqtt out","z":"a04da025.0d514","name":"","topic":"","qos":"","retain":"","broker":"5351859b.60e574","x":499,"y":110,"wires":[]},{"id":"c39586f4.09735","type":"mqtt in","z":"a04da025.0d514","name":"","topic":"4qvhHk6Atzk2hCkQcfi7n2GuJil9w3bs/Home/MA/Main/Sensor/Temp/","qos":"1","datatype":"auto","broker":"5351859b.60e574","x":341,"y":366,"wires":[["9dd97618.29073"]]},{"id":"9dd97618.29073","type":"debug","z":"a04da025.0d514","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","x":681,"y":363,"wires":[]},{"id":"5351859b.60e574","type":"mqtt-broker","z":"","name":"Emitter","broker":"api.emitter.io","port":"8080","clientid":"","usetls":false,"compatmode":false,"keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","closeTopic":"","closeQos":"0","closePayload":"","willTopic":"","willQos":"0","willPayload":""}]
12

An issue was raised for this and here's my response - copied here for anyone finding this thread in the future:

The Emitter.io service takes an unusual approach to topics and security. You have to subscribe with a key prepended to the topic you want to subscribe to.

4qvhHk6Atzk2hCkQcfi7n2GuJil9w3bs/Home/MA/Main/Sensor/Temp/

But when the client receives a message, the topic on the message no longer has the key prepended:

Home/MA/Main/Sensor/Temp/

This is what prevents the MQTT nodes from 'seeing' the messages. When a message arrives in Node-RED, it looks for any MQTT In nodes that have a matching topic string and passes the message to those nodes. In this instance, because of the prepended key, none of the MQTT In nodes match.

If you add a second MQTT In node subscribed to Home/MA/Main/Sensor/Temp/ you will see it receives the message - however it also emits an message from emitter.io containing an error because there's no key in the topic.

This is a limitation of the MQTT nodes. The protocol doesn't have anyway other than the topic string to associate a message with a subscription. There is no way we can know the Home/MA/... message is destined for the 4qvhHk6Atzk2hCkQcfi7n2GuJil9w3bs/Home/MA/.. node.