According to the debug output seen in the serial monitor, messages are all sent successfully, but often there are long periods of time (30 minutes - few hours) of not receiving any messages on the queue at all.
After that long period of no messages received, the last message will fail ([rdResp]: ERROR). Then a reconnect is attempted (adaptation of the sketch to do the reconnect was mine). After the reconnect has been successful, messages will be received on the queue, usually for a long time (hours).
This is with the board stationary indoors, tested on two locations, the behavior is the same. The reported signal quality (from AT+CSQ) is ~20 in both cases.
Is there some idea as to what causes this and if/when it will be fixed? I’m aware that it’s UDP, but missing all messages for hours makes it impossible to conduct the tests I have planned.
I assume, you use the original ‘send message’ routine, correct? I don’t use this routine. Instead of this I’m creating a UDP socket by myself. And, doesn’t matter how bad the CSQ is, as long as connecting is possible, the message is going out.
Are the messages completely lost?
Or do all the messages come in at the same time?
Hopefully @EricBart from T-Mobile can help.
Maybe the T-Mobile backend can give us an indication what the problem is.
Thanks for your reaction Jan, the messages are lost. I sent sequence number in them to check. It is always a large number of consecutive messages that do not arrive (not just one or a few).
The network is still in a testing stage.
Both network and module are updated frequently.
Please let us and T-Mobile know about all the issues you have.
Together we can improve the nbiot experience
For the module updates we can check Git I guess, and is it possible to see somewhere when network updates are planned/completed and what was done? That would be a big help!
Today I received the first messages at 11:09 after having started two NB-IoT shields around 10:30. There were no message sending errors on the boards, so presumably the CoAP messages have been received OK. Probably the messages had not been forwarded from the T-Mobile network to the MQTT broker, because none had an earlier timestamp than 11:09.
Is there news on a fix for this issue?
Another question; Which qualityOfService settings are supported by the Allthinkstalk MQTT broker?