Why is my MQTT message getting filtered or altered?


I have Node-Red running on two Raspberry Pi3's.
Pi#1 receives commands from Alexa Local and sends them to Pi#2 by MQTT.

Problem: the MQTT message data is changing in the transmission from Pi#1 to Pi#2

This is what the MQTT-out node is sending:
7/7/2018, 7:29:51 PMnode: c0b7a852.9458d8
msg : Object
bri: 50
on_off_command: false
payload: "on"
change_direction: 0
bri_normalized: 0.5
on: true
device_name: "Kitchen Light"
light_id: "e96501e42186e"
port: 39391
_msgid: "e47ef54f.4c7c28"

This is what MQTT-in node is receiving:
7/7/2018, 7:29:51 PMnode: c10dd4c3.df39e8
downstairs/kitchen/light : msg : Object
topic: "downstairs/kitchen/light"
payload: "on"
qos: 0
retain: false
_msgid: "87ad00a3.517d5"

What happened to the rest of the data?

Here is my sending node (Alexa Local and MQTT)
[{"id":"e96501e4.2186e","type":"alexa-local","z":"c70d6534.cd3978","devicename":"Kitchen Light","inputtrigger":false,"x":210,"y":2740,"wires":[["bac3f894.020ad8","c0b7a852.9458d8"]]},{"id":"bac3f894.020ad8","type":"mqtt out","z":"c70d6534.cd3978","name":"Kitchen Light","topic":"downstairs/kitchen/light","qos":"0","retain":"","broker":"db845b13.2b1628","x":720,"y":2740,"wires":[]},{"id":"c0b7a852.9458d8","type":"debug","z":"c70d6534.cd3978","name":"","active":true,"console":"false","complete":"true","x":690,"y":2820,"wires":[]},{"id":"db845b13.2b1628","type":"mqtt-broker","z":"","broker":"","port":"1883","clientid":"","usetls":false,"compatmode":true,"keepalive":"60","cleansession":true,"willTopic":"","willQos":"0","willPayload":"","birthTopic":"","birthQos":"0","birthPayload":""}]

Here is my receiving nodes (MQTT and Debug)
[{"id":"447121c.a9001e","type":"mqtt in","z":"f08f8988.eb7768","name":"Downstairs Kitchen Light (nzw31 Dimmer switch)","topic":"downstairs/kitchen/light","qos":"2","broker":"a5f4b39c.527e6","x":220,"y":820,"wires":[["8813c18c.657de","c10dd4c3.df39e8"]]},{"id":"c10dd4c3.df39e8","type":"debug","z":"f08f8988.eb7768","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","x":580,"y":820,"wires":[]},{"id":"a5f4b39c.527e6","type":"mqtt-broker","z":"","name":"Marvin","broker":"","port":"1883","clientid":"","usetls":false,"compatmode":true,"keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","closeTopic":"","closeQos":"0","closePayload":"","willTopic":"","willQos":"0","willPayload":""}]

Help would be greatly appreciated.




The MQTT node only sends msg.payload and msg.topic.

Any other message properties are ignored.

So you'll need to get all the data you want to send under msg.payload.



Thanks for pointing me in the right direction.

With lots of reading and experimenting, my control over MQTT is working. It turns out all I really needed was the "bri" value that I got using a function node:

var bri = msg.bri;
msg.payload =   bri;
return msg;

However, for future reference, is there a simple process to package all of the properties in an object into a payload, then unpackage them on the other end?

Steve Mann



You could use a Function node to create a new message object whose payload is the received message:

return { payload: msg }


Though if you do that, you should be cautious about what the msg contains. If, for example, it is the result of a web request, you might find that the data is rather large! And circular too.



Are you sure you really want to do that? Put not only the payload but the topic and the node id into mqtt? Plus any other properties that happen to be in the message. I would have thought better just to put the properties you want there, or even split them into different topics on mqtt, if that is appropriate.



That's what I ended up doing since all I need is the bri value. On the other hand, have you used the msgpack node?



Sending just the properties I need was my solution, but other than a little additional overhead, what problem do you see with simply packaging the whole payload into a single msg.payload property, then unpacking the properties on the other end?



It all depends on what properties you have on the message; if there are lots of properties you have no need of, then its unnecessary overhead to transport them between NR instances.

For example, a flow that starts with an HTTP In node will have a lot of data associated with the HTTP request that you don't need.