The "OK message should be at the last line printed after the command is issued. This way there is no way for a chat script or expect script to detect the end of the command output. Pretty much every interpreter expects the OK as the last line for processing AT commands.
Other modules like the EC25 does this in the correct order.
This is the correct behaviour for the EM12&EG12&EG18 modem series as documented in the AT commands manual.
The +QTEMP: readings are delivered as unsolicited results after the “OK” response.
We use these modems in the ROOter project, and there I simply wait for a couple of seconds for further characters after getting the “OK”, but only for the AT+QTEMP command as a special case.
Well, when you query this data, it is not unsolicited, as this response is only received, if I issue the AT+QTEMP command. Therefor this is a command-response message, and not unsolicited. If the documentation is also incorrect in this regard, that does not make this acceptable IMHO. The fact other Quectel modules - like the EC25 - does respond in the correct sequence also proves, that this might have been unintentional and in fact a bug.
“I guess you could wait for “tsens_tz_sensor4”, but that leaves a few characters in the buffer.”
That is not a solution, as if you wait a few more seconds, you can risk to parse real unsolicited messages, as there is no “EOL” sign for the script, which the “OK” message should be at the end of the response. Basic AT message structures are there for a reason. And the solution to this is no a customized script on the customer end, but the vendor fixing this issue. Otherwise, we can keep writing customization for each command like this, instead of parsing them with a generic model, which needs a clear sign to look for.
MOD: another Quectel module (RG50x) also does this correctly with the “OK” at the end:
The term “unsolicited” has a meaning in modem AT command dialogue which can differ from common-language usage.
There are other URC (Unsolicited Result Code) examples where no URC is generated unless it is solicited in the common-language sense.
The +CUSD (Unstructured Supplementary Service Data) command is one, where the use of a URC is enshrined in 3GPP 27.007, section 10.8.
I am well aware that other Quectel models handle AT+QTEMP differently.
You can prove that the temperature data returned by your modem is in the form of a URC by disabling URCs and observing that no readings are returned then.
AT+QINDCFG="all",0
AT+QTEMP is a Quectel-proprietary command. As such, Quectel can implement in any way they choose. Its behaviour is consistent with the documentation, so I’m at a loss to see how it can be considered as a bug.
That risk exists whether you wait or not, unless you run with URCs turned off. They can of course arrive between your running of AT commands, and be sitting in the buffer.
In ROOter, I turn them off for SMS only, with AT+QINDCFG="smsincoming",0,1
