Why am I getting garbage in payload?

General
1

I have node-red v0.19.3 running on armbian on an orangepi zero.

I have a snap of mosquitto running on the orangepi zero, so it is running default settings with no fiddling by me.

I have a WEMOS D1 R2 MINI as client.

I sent a payload of 123456 as either string or number (I have tried byte buffer as well to no avail).

Even if I hand unpack the payload byte by byte at WEMOS end, I get chars 2,3,8,3,,r instead of 1,2,3,4,5,6 or bytes [49,50,51,52,53,54] so it looks like I am receiving [50,51,56,51,0,114] instead.

Payload is sent using out of the box inject node loaded with string 123456 as payload and sent by out of the box mqtt output node.

Unpacking at WEMOS end is otherwise the standard:

String resultString = "";

for (unsigned int i=0; i<length; i++) {

  resultString += (char)payload[i];
}

I am otherwise not having problems with the topics since, obviously, I need to catch a topic to see the problem with the payload.

Topic length is a mere 28 characters of the format:
/xxxxxxxxxxxxxx/yyyyyyy/z/f

xxxxxxxxxxxxxx is the app I am building and is there to set it apart from other app I am running through the MQTT server.

yyyyyyy will be the chipID of the WEMOS I am talking to

z is a relay index on the WEMOS

f is 0 for off or 1 for on

The errant payload is a time it milliseconds for the relay to turn on.

I have only one topic using the payload.

I am otherwise stuck at the moment as it is quite a straight forward payload unpacking problem, using code other people have used. The length being returned with the payload always appears to be the length of the string I have sent.

Any ideas please?

Cheers,
Ray

2

Not sure what this has got to do with Node-RED..
Did you try pointing the command line Mqtt client at the broker to check the payload ?
Can you just print the payload to serialport debug to check before unpacking ?

3

There is a chain of events, node-red, mqtt server, wemos client etc.

Why would I not start at the start?

And when the MQTT group let me know that I should toy with something node-red end I will let you know. It might be something like, node-red is not packing the data properly before sending it.

Not sure who the WEMOS group will point me to.

Otherwise, yes good I idea.

4

In Node-RED why not add an MQTT-in node connected to a debug node. Point the MQTT node to the same broker and topic and set th debug node to complete msg object.

Now you can send the data and see what it looks like in NR. If the data is fine, it has something to do with your WeMos code.

5

Yep, so have an in-node on two node-red servers, on on orange pi and on on pc, so the message seems to unpack fine on both orange pi server and pc server. That clears node-red, mosquito server.

As of today, the library author for the wemos pubsub code has remained silent. So, while the topics seem fine (since I can catch all the topics I set up). It is just the payload corrupted somehow. As you say, likely in the wemos side.

6

Since this looks to be a problem with your WEMOS, and not Node-RED, if you can post your WEMOS code here - maybe we could try and replicate your issue?

But probably best to try and find solution on a WEMOS forum now

7

Hello Bazmundi

I use the following setup for about 10 sensors/actors now:

ESP8266-device <---> MQTT-broker <---> Node-RED

The broker is mosquitto and runs on a Raspberry Pi together with Node-RED.

The communication works in both directions. I'm using the Arduino IDE for my programming. Currently I'm using the MQTT library from Joel Gähwiler https://github.com/256dpi/arduino-mqtt since it support TLS for encrypted communication.

I looked at your extracting code in your first post. I'm not really sure it is that complicated. If you're using the Arduino IDE too, then install the Joëls MQTT library and have a look at the examples.

Let me know if you have more questions afterwards, I might be able to help.

Kind regards,

Urs.

8

All good. A bug in the payload receipt code appears to be in the knolleary wemos library. I swapped wemos mqtt libraries from knolleary to Imroy. The Imroy library is a fork of the knolleary and has reworked the topic and payload delivery to clients somewhat. With a few tweaks my code now works.

There was, however, no need to change the payload unpacking code.

I have otherwise reported problem on knolleary code, but it appears that the fork by Imroy was because of support dropping off knolleary code.

Cheers,
B

9

Indeed - @knolleary has been busy with other things and doesn't have an endless supply of time and hardware to test the client on every possible system. It's great there are other clients out there.

10

Indeedle, weedle do. No needle to vindicate @knolleary

Like a good opensource citizen, you have otherwise lived up to the "as is" mantra of open source. No shame there, since there is no expectation that you do otherwise. As a good citizen, I am passing on review comments to the masses to ensure time wasting is reduced where it can be.

No harm done in any event, I wear a mouth guard now when using opensource, on dentist's recommendation - to avoid wearing down my teeth due to grinding.

11

Just to be clear, I know of others happily using the client on wemos. So there isn't some fundamental breakage here. I don't know why you're getting garbage, I don't have any wemos to try to recreate it myself. It would be great to get to the bottom of it, but it sounds like you've moved on already.

1 Like