@Hans-Liefting: Can you please send me the IMEI of your device to firstname.lastname@example.org? I will check the logs to understand when uplink and downlink messages are received and when downlink messages are sent by the udp server.
We were thinking in that direction (sending version)
Another reason why I asked is that since I started sending downlinks to a (devkit) device for testing purposes, the device now is extremely slow in sending messages. It takes minutes, sometimes hours to send a single message (uplink).
Could that be linked to not “collecting” the downlink messages?
@Yassine-Amraue : thank you for explaining that there is a GUI and an API user. I’ve been banging my head trying to send a downlink message via API and always getting an ‘unauthorized’ error. But after registering a callback URL for the API user as well I can now send downlink messages via API to my device. Thanks again.
@magnatron : I am using a SIM7020 based device and previously via API sent downlink messages are getting delivered to it as soon as the device sends an uplink message.
Currently the API supports the following for functions/URLs to send downlink messages to the device
Sends regular queued downlink messages to device when uplink is received.
Sends queued binary data blob message to device when an uplink is received. The function expects base64 encoded payload from the applaction as input into this function. Before the message is sent to the device it is decoded back to binary and sent to the device.
Same like downlinkMsg/0/data but without queuing.
Same like downlinkMsgBase64/0/data but without queuing.
you are right, that the UDP server of IoT Creators doesn’t send back an acknowledgment for a received messages.
BUT: The CoAP/Leul server of IoT Creators acknowledges a received messages with a “2.05 Content” acknowlegment.
Be aware that CoAP/Leul is the Huawei flavor of CoAP and it is supported by Huawei chipset such as HiSilicon which are used in moduls such ublox N211 or Quectel BC95.
For many customers it is not enough to have an acknowledgment between the device and the IoT middleware. The implement an asynchronous acknowledgment between the application and the device on the basis of a downlink message. If you would need the asynchnronous application acknowledgment it wouldn’t make a difference between CoAP/Leul and pure UDP.
There is no option to query the status of a downlink message. Buffering of downlink messages may occur on different places in our solution it is hard to give an clear response to such a request due to the asynchronous nature of the protocols.
Note: after sending an uplink message we will try to downlink all buffered messages.
@sopwafel You could, but be aware of using PSM and expected latency. Your device might be sleeping again before it had the chance to receive a downlink message. I don’t know if it’s possible to use in combination with the T-Mobile CDP but you might want to take a look at LWM2M and CoAP. These protocols have acknowledgements build in.
The term “latency” relates to one-way, downlink or uplink communication. It does not include the time needed to establish a connection between the server and the device. If the device is in power saving mode, it will only receive or send data after it wakes up. According to measurements on current test setups with pre-commercial radio modules, data transmissions typically exhibit a latency of less than a second. In scenarios involving deployments in poor coverage areas, latency may increase up to 7-10 seconds. That said, NB-IoT technology is continuously being enhanced, so current figures are expected to improve with successive releases of the specification.