MQTT vs CoAP protocol

Hello all,

I’m writing to understand the criteria used by you all for deciding usage of MQTT vs CoAP. This is many a times decided by many other factors such as familiarity, available firmware stacks, IoT cloud platform support, security support and so on. Also asking because LwM2M which was until recently only CoAP based has lot’s of device management support taken care of as an open standard.

Thanks and regards, Prithvi

Hi Prithvi

It will be good for you to invite specific companies who are likely to benefit from this solution to hear their feedback. As a registered member, you can invite other energy access practitioners.

Thanks
Aarti

Hi Prithvi,

Which of the following interoperability scenarios are you focused on? There are different initiatives with different objectives for each of these currently, I believe:

  1. Device to Device interoperability. Currently, GOGLA has a connector standard discussion active on providing a standard electrical connection between devices. There is OpenPaygo Link, which provides a transport/link layer access that can run on single-wire links between between devices. And there is Nexus Channel, which runs on top of a link layer (such as OpenPaygo Link) to provide standard resource interaction between devices (it uses CoAP, as Nexus Channel is a subset of the OCF device interoperability standard, ISO/IEC 30118-1:2018, which specifies a CoAP-based interaction model between device ‘resources’. Here is an example of a Nexus Channel ‘battery’ resource, showing the optional/required parameters to expose - but the format allows for any proprietary model to be introduced or new attributes to be expanded as needed Nexus Channel Redoc Wrapper).

  2. Device to IOT Cloud interoperability. I’m not aware of significant standardization here currently, but there are a number of different ways / providers that different manufacturers are using here (some proprietary, some off-the-shelf like AWS/Google, etc). I suspect that your mention of LWM2M is primarily around this layer of interoperability (is that right)?

  3. Account Management Platform interoperability. This relates to sharing customer/loan info between different platforms, and is probably not what you’re after (let me know if thats incorrect, though!)

  4. Device Management Platform interoperability. This relates to being able to manage device state (PAYG state is often discussed, but this includes parameters like threshold settings, operational parameters, etc) via standard APIs when the ultimate connection ‘to the device’ is done from another provider/service. As an example, Angaza provides this for units that implement Nexus Keycode firmware via the Nexus API, and I believe that Solaris has developed a standard for interchanging usage data between platforms/servers as well. I want to highlight the difference between this interoperability (management ‘platforms’ sharing information/commands) and the interoperability in item #2 (an IoT cloud sending commands to a device, and receiving responses - via MQTT, CoAP, a higher layer standard like LWM2M, some custom protocol, etc). For a simple example, this item relates to a platform requesting that another platform ‘generate a keycode’ or more complex binary command for some unit, but getting that keycode to the unit would be the responsibility of a system in item #2 above (sent via SMS? LoRAWAN? How are retries handled? etc).

I can comment more on the device-to-device management, as I’m working on Nexus Channel with active integrations right now, but am probably not the best person to comment on the other scenarios.