Which works great.
But now I’m trying to add a JSON formatted string to "willmessage" , so I need to add "" (double quotes) in there, which means I need to escape them in my command. But I have no clue if I can escape them or what the escape character is.
Things I tried: \" (backslash) and "" (double double quotes)
I looked in all of the BG96 datasheets, and I don’t see it mentioned anywhere.
Did you try the hex escape sequence \22 (according to V.25 ter)?
Of course you would need to escape that in C/C++ too, if that’s the language you use. In that case you would have ".....,\"willtopic\",\"{\\22willmessage\\22:\\22some text\\22}\"" in your code.
Any character value may be included in the string by representing it as a backslash (“\”) character followed by two hexadecimal digits. For example, “\0D” is a string consisting of the single character (IA5 0/13). If the “\” character itself is to be represented in a string, it shall be encoded as “\5C”. The double-quote character, used as the beginning and ending string delimiter, shall be represented within a string constant as “\22”. Standards that reference this Recommendation may prohibit use of this “\” mechanism if only displayable characters are permitted in string constants in that standard and if the double-quote character is not permitted within string constants; in this case, the “\” character shall be treated as any other IA5 character included within a string constant.
But no luck, it seems that the Quectel modem does not translate it to an actual double quote internally.
When trying your example, at the AWS side I’m receiving: {\22willmessage\22:\22some text\22}
same thing happens when using \x22 instead of \22
Great suggestion though.
So @forums.quectel, is it impossible to use double quotes in AT commands for your modems?
MQTT is not limited to alphanumeric or printable characters, so that sounds like a bug or a silly limitation, as serialized JSON is quite a common data format. What about binary data formats, like CBOR or MsgPack then? How would you enter those?
Note that the way you input data for a ‘normal’ MQT message is different from the way you input the body of your LWT message.
Normal MQTT message spec:
AT+QMTPUB=<tcpconnectID>,<msgID>,<qos>,<retain>,“<topic>”
After “>” is responded, input the data to
be sent. Tap “CTRL+Z” to send, and tap
“ESC” to cancel the operation.
Here you can use any character (except CTRL+Z) in the body of the message.
The way the LWT message is configured is just lacking. Which to me indeed sounds like a bug or silly limitation.