Go Down

Topic: Strings, bytes, char arrays MQTT arghgh (Read 2 times) previous topic - next topic

Nick Gammon

As long as you are confident that this is OK. That payload and length are passed to you. Modifying one past the end of the payload may be corrupting memory.

ilium007


As long as you are confident that this is OK. That payload and length are passed to you. Modifying one past the end of the payload may be corrupting memory.


ahh OK - your way does may sense.

ilium007

Actually, when I try to do it with:

Code: [Select]
lcd.print(payload,length);

I see this error:

"call of overloaded 'print(byte* &, unsigned int&)' is ambiguous"

Nick Gammon

Assuming lcd is derived from Print, try:

Code: [Select]
lcd.write(payload,length);

ilium007


As far as I understand the MQTT format, the content of the payload variable is not defined (by MQTT) but can be anything. You seem to opt for an ASCII based protocol which is easy to debug and easily portable but not as efficient as a binary format would be.
If you choose an ASCII format, I would still strongly suggest to define standard structure of such a string, like "TYPE:POSITION:VALUE", so in your example it would not be "PUMP:ON" but "PUMP:1:1" or "VALVE:1:0" instead of "VALVE:1:OPEN". This makes it much easier to parse the incoming message and organise the call distribution. You can use strtok() then to split the message into the type, position and value. Position and value can be fed to atoi immediately after the split up and you already have integers.

The conversion from a byte array to a character array is simply a type cast:

Code: [Select]
char *cstring = (char *) payload;


I know this is an old thread now but I have resurrected this project and I am interested in the binary based format you mentioned above. I cant work out how to implement this. 

Go Up