IoT components removed in nRF5 SDK v17.0.0

[Michael Kreher]

Dear Nordic Support Team,

I was using the CoAP and MQTT components in nRF5 SDK v16.0.

So my device was able to do CoAP and MQTT via BLE 6LoWPAN. Adding a BLE service to my device was work in progress.

But I have seen the IoT components were removed in nRF5 SDK v17.0.0.

Do I now have to use the nRF5 SDK v17.0.0 in conjunction with nRF5 SDK Thread and Zigbee v4.1.0 to do CoAP and MQTT over Thread?

The downside of this solution is I have to use and setup a Thread network.

What is the prefered SDK / SDK combination to implement a device which "speaks" CoAP/MQTT (without the need of Thread or Zigbee) and additionally implement BLE services?

Thanks and Regards

Michael

[Jørgen Holmefjord]

Hi,

Is there anything preventing you from continuing to use SDK 16.0.0 for the IoT device? nRF5 Thread and Zigbee SDK v4.1.0 is also based on nRF5 SDK 16.0.0, so there is no difference.

Best regards,
Jørgen

[Michael Kreher]

Thanks Jørgen for your very quick response.

I think for prototyping my showcase it's OK to continuing on SDK 16.0.0.

But the question I'm asking is why the IoT components on the nRF5 SDK 17.0.0 were removed.

Is there a strategic reason for this decision?

Best regards

Michael

[Jørgen Holmefjord]

I believe it is a combination of that the libraries were in production quality in SDK 16.0. and that there were no plans to further develop the libraries for SDK 17.0.0. The libraries required comprehensive testing for each SDK release, so by removing the libraries from the release, the release-testing for the SDK could be reduced a lot.

With the move to nRF Connect SDK for newer products (nRF91/nRF53 series, and now support for nRF52 series), more resources will be put into developing this going forward. We will still provide you with support if you continue developing your IoT product using SDK 16.0.0.

[Michael Kreher]

I think you are right. The future belongs to the nRF Connect SDK .

In the near future I will start moving my stuff in this direction. A huge step, but the absence of the sdk_config.h attracts me ;-)

Thanks for answering my questions!