@hek I've done my best to try and do some data collection/troubleshooting as per your suggestion.
I tried to work out whether the problem was with the gateway or the client. I think I've established that it is the client receiving the message, but I've exhausted my limited c++/googling ability.
I threw in lots of debug statements all over the place. At first I was convinced there was a problem with the section of incomingMQTT in MyGatewayTransportMQTTClient that inserts a null byte at the end of the payload, however I have confirmed this is working using debug(PSTR messages.
I dumped the contents of the payload pointer at the start of that function and at the end. At the start the payload was equal to '6/+/+', however at the end, it was changed to '6' (this was the value I sent for debugging).
Instead I turned my attention to MyTransport.cpp, and verified that a) the correct length was being returned from mGetLength(message), and b) that the payload being sent was exactly the right length/right amount of data. I did this with debug commands in the transportSendWrite function.
Everything seems fine from the gateway point of view, however when I turned my attention to the client, I found that this seems to be where the issue is. I put some debug statements in the transportProcess() function in MyTransport, and could see that while the client logging that it had received the correct length message in mGetLength(_msg), the length of _msg.data is set to whatever the longest string that has been sent previously is. It doesn't seem like a new _msg object is being made for each message, and the value of _msg.data isn't being cleared/correctly assigned to be just the length of the incoming payload as per mGetLength(_message).
Adding the line reading 'Message payload...' in the MyTransport.cpp below
debug(PSTR("read: %d-%d-%d s=%d,c=%d,t=%d,pt=%d,l=%d,sg=%d:%s\n"),
sender, _msg.last, destination, _msg.sensor, mGetCommand(_msg), type, mGetPayloadType(_msg), mGetLength(_msg), mGetSigned(_msg), _msg.getString(_convBuf));
debug(PSTR("Message payload in MyTransport.cpp: %s\n"), _msg.data);
I get the following output:
read: 0-0-3 s=0,c=1,t=3,pt=0,l=1,sg=0:6
Message payload in MyTransport.cpp: 6.6.0-beta
Received message, type: 3
Message level: 6.6.0-beta
Message length: 10
Changing level to 6, from 0
As you can see, the l=1, shows that the client recognises the intended length of the message, but the message.data on which atoi() is called on by the example code for the Dimmable LED Actuator example (and also called on by the MyMessage::getInt() code), is then failing unpredictably based on previous messages.
I can't go any further because I don't know
- What assigns the value to MyMessage data
- Whether there is supposed to be some sort of clearing of this value between messages
- Enough about how the code/library works to do any further debugging.
I hope this has been helpful.