Mqtt-in repeated messages bug?

General
1

I see some weird behaviour with the mqtt-in node.

When I change the output to "a parsed JSON object" > deploy. inject something in mqtt-out node, i get a single response.
Change the output to "auto-detect" > deploy. inject something again, the messages are repeated.
Change it again to json, deploy, inject> triple messages output and so on.

If i select all nodes>ctrl-x, deploy, paste, deploy, single messages again.

I can reproduce it. Is this just me ?

2

This is really strange behaviour and it makes mqtt unusable for me.
Only the initial setup works, touch it and I am stuck with repeated messages until I remove the nodes, deploy and add them again.

@knolleary do I do something wrong or did I find a bug ?

3

Has the message been published with the retained flag set, meaning youll receive it each time the node subscribes?

4

No retain flag, I have cleared everything on the broker.
Looking at the subscription, only 1 message exists on the broker, gets repeated in node-red.

Test flow:

[{"id":"380b9424.fcc454","type":"mqtt in","z":"c0f7a95e.a66d08","name":"","topic":"test/testtopic","qos":"2","datatype":"auto","broker":"73843d1e.7f20dc","x":170,"y":160,"wires":[["a8b9efe1.03a4e"]]},{"id":"a75bc06d.f0bcd8","type":"mqtt out","z":"c0f7a95e.a66d08","name":"","topic":"test/testtopic","qos":"0","retain":"false","broker":"73843d1e.7f20dc","x":410,"y":260,"wires":[]},{"id":"a8b9efe1.03a4e","type":"debug","z":"c0f7a95e.a66d08","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","x":330,"y":160,"wires":[]},{"id":"cc1366c5.2d0998","type":"inject","z":"c0f7a95e.a66d08","name":"","topic":"","payload":"{\"test\":true}","payloadType":"json","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":180,"y":260,"wires":[["a75bc06d.f0bcd8"]]},{"id":"73843d1e.7f20dc","type":"mqtt-broker","z":"","name":"mqtt","broker":"10.0.0.202","port":"1883","clientid":"","usetls":false,"compatmode":true,"keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthRetain":"false","birthPayload":"","closeTopic":"","closeQos":"0","closeRetain":"false","closePayload":"","willTopic":"","willQos":"0","willRetain":"false","willPayload":""}]

Inject, single response.
Change mqtt-in to parsed JSON object, deploy, inject, 2 messages.
Change it again to auto-detect, 3 messages.

5

I could swear that there was a thread in the not too long past that talked about a MQTT broker monitoring tool. But do you think I can find it...nooooo....drat's I thought I had it bookmarked.

Anyway If you can find it, it might shed some light on what the broker is doing.

In addition thei shread might help: Issues in persisting messages in MQTT Broker using NodeRed MQTT Nodes

6

I am using MQTT Explorer

1 Like
7

I experienced the same thing. Restarting Node Red helped also. The broker wasn't the source of evil.

8

Restarting works temporarily unfortunately

9

Hi @bakman2

I can't reproduce this with the flow you've provided. I always get the expected one message.

What broker are you using?

10

I am using eclipse mosquitto.

It starts repeating once I change something to the mqtt nodes.

11

I have also seen multiple MQTT messages. In the end I just used an RBE node to handle it.

Should have reported it but suspected it was something I done wrong or an MQTT thing at the time.

Fwiw, I was using the most excellent EMQX broker and node-red v0.20 beta something at the time.

12

Then it is not me and it is not the broker.

Using an RBE node is not a "solution", it will work, but I'm not a fan.

13

When I switch from a parsed JSON object to auto-detect I get 2 messages:

3/29/2019, 9:31:03 AMnode: 48a51ca2.2426a4
livingroom/fan/uptime : msg : Object
object
topic: "livingroom/fan/uptime"
payload: 3493
qos: 0
retain: false
_msgid: "5d655259.c8ae2c"

3/29/2019, 9:31:03 AMnode: 48a51ca2.2426a4
livingroom/fan/uptime : msg : Object
object
topic: "livingroom/fan/uptime"
payload: "3493"
qos: 0
retain: false
_msgid: "956c5dae.87137"

1x Payload as number
1x Payload as string.

I strongly suspect this is node-red.

14

I can now reproduce. The missing step to recreating was you had to do a 'modified nodes/flows' type of deploy, rather than full deploy.

15

That lines up with how I often work. I change a small thing and only deploy node changes (not flow not full).

Now you can recreate it, have you raised an issue or should one of us?

16

That is correct, my apologies. At least this explains the inconsistent behaviour on my end.

17

I have raised an issue #2119

I use some API's that are triggered when the flows are deployed, causing them to complain about too many requests - this is why I use the modified flows most of the time.