The problem arose publishing to the AWS IoT Core get shadow topic to receive and updated config.
We found that we needed to publish twice In order to receive a reply straightaway. If you only send it once, the reply can sometimes be caught much later (2+ minutes). But obviously we shouldn’t have to wait for the network for this long because the double publish causes the reply to come almost instantly.
I tried sending AT commands to increase the qos form 0 to 1 (2 is not supported my AWS). AWS gets the message published and replies straight away in either case. Furthermore with qos=1 it generally doesn’t reply twice or more (as seen in IoT Core test screen) indicating it got an ACK from the device. There is a default timeout of 5 seconds with 3 retries that can be configured by at commands but this only applies to packet delivery from the client. You can see the messages appear on AWS instantly. Whatever the case, raising the timeout arbitrarily high doesn’t help.
I have unsuccessfully tried variations of reading from the the serial buffer before function calls, as well as breaking up publishing and catching the reply into two high level function calls, in the off chance there was some weird memory, cache line level problem.
I looked into configuring a last will and testament message to determine if the connection was lost. But the connection remains active and it wouldn’t help anyway since AWS has a connection timeout of 2min by default between heartbeats. Plus AWS seems to have gotten an ACK after sending the shadow anyhow (and we know it can arrive straightaway).
I tried unsuccessfully tried sending a AT+QRECV message immediately after publishing, this is meant to read from the input buffer, even though the data is meant to be spat out (and is for messages with no reply) straight away a publish by default.
This seems to be a crazy core BG96 bug and the only workaround I can see at the moment is using a dummy publish (so we don’t get 2 shadow replies as before) to a topic that doesn’t reply straight after a publish. This will force the BG96 to give up the reply from the previous publish straight away instead of making us wait for it.
I can’t find anything in the docs or online yet that addresses this problem.
Anyone else run into this?