The SARA-N2 supports 2 sets of commands that I assume are both based on CoAP.
Section 14 titled “Datagram Messages” describe commands for sending and receiving data on port 5683 (CoAP) using +NMGR and +NMGS.
Section 15 titled “Constrained Application Protocol” (CoAP) describe other commands e.g. +UCOAPC to get/put/post messages.
Has anyone used the latter commands?
Is there an advantage of using one set of commands over the other?
If your operator has a CDP/IoT Platform (such as Nokia Impact, Huawei Ocean Connect) it can is advantageous to use the NMGR/NMGS messages, because everything is already setup and you can start quickly, which is always nice. Also, depending on the use-case, these platforms may have useful functionalities or data.
Some issues that could make this not so attractive or feasible might be:
- your operator does not have such a platform or you plan to use/sell your product in markets where no operator has such a platform
- your operator has such a platform, but charges extra for it and you don’t want to pay
- you want to be able to use modules with chipsets that do not have these AT commands
Regarding 1 and 2, you could create your own “light CDP” (like described here: https://bearmetal.eu/theden/sending-oma-lwm2m-coap-messages-with-quectel-bc68/ ). But this doesn’t solve 3.
Unfortunately, using the UCOAPC commands you mentioned doesn’t solve point 3 either. It seems there are even less modules with AT commands for CoAP (ex. the newer u-blox T410 doesn’t have this command). Also, after trying the UCOAPC commands I found that it does not deal well (“well” as in “according to RFC7252”) with the multipart paths and queries (eg. the path “rooms/421/light” consists of 3 parts and the query “?device=sensor&id=1234&key=5678” also consists of 3 parts).
If anyone knows how to do this with the N211, or if a this becomes possible with a new FW, please let me know.
Until now it has been our experience that all these higher level commands (NMGS, UCOAPC, QLWULDATA, UMQTTC etc) seem very appealing at first, and then there is some downside. Right now we are “back to basics” and prefer to use UDP or raw IP and then build whatever we need on top of that.
Thanks very much for the informative reply and link.
Until OMAs LwM2M protocol becomes readily accepted by the industry I’ll keep using UDP for the time being.