Sub Read Mqtt String

[rddaz2013]

I need a little help to understand what this VI is for?

https://forums.ni.com/t5/Example-Program-Drafts/MQTT-Client-API-in-native-LabVIEW/tac-p/3703161#M12700

Because in my message the first two byte are missing because of this VI.

thy

[maovidal]

That VI extracts an string from a message. The first two bytes determine the length of that string.
Check the section 1.5.3 UTF-8 encoded strings of the specification http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf for more details.

[rddaz2013]

Thx

My Problem was if I send a message from a paho python client like '00test', my VI gets 'test'. If i "shut down" this sub-vi .-) i get '00test' but the topic wrong.

and on WIN the MQTT runs into Error 66 with the Read TCP but that is something else...

[maovidal]

May it be related to mixing the data types building that string?

'00test' may not be the correct string to send. The byte value for the symbol '0' is 0x30, so combining those two initials '0' will make the VI wait for 12,336 characters.

Actually 66 is a timeout error. I guess that if you were processing the received message treating the "Remaining Length" in the same way, you may have may have received that error while reading from the TCP port.

In this case, the correct data to send byte by byte is: 0x00, 0x04,'t','e','s','t'. Then the combined value for the first two bytes is 0x0004, then the VI will build the string with the next 4 characters: "test".

[rddaz2013]

'00test' may not be the correct string to send. The byte value for the symbol '0' is 0x30, so combining those two initials '0' will make the VI wait for 12,336 characters.

I think that is what is happening... python send a real '00test' string..but i think the VI handles the header of the mqtt (fix length or something else) quite different.

I guess that if you were processing the received message treating the "Remaining Length" in the same way, you may have may have received that error while reading from the TCP port.

Error 66 that is a problem if the loop..open close the TCP connection every time...if the timeout of the read is longer as the publisher holds the connection. I think if the keepalive timeout for default MQTT Broker > than the TCP timeout then it will work.