Thingy91X unsuable with lwm2m_client

[cellular_iot]

Hello Nordic Team,

we’re evaluating nRF91 for our next product platform (being strong in LoRaWAN since years) and hoped to quickly run some first field trials with the recommended lwm2m_client.  Unfortunately, after several weeks, we are facing multiple blockers:

• Thingy91 with nRF9160 seems to be outdated and not reccomendet for new products
• The original Demo App Thingy91 is still shipped with, is not available in Source anymore
• Thingy91X with nRF9150 software seems like an early prototype, not much is working currently

• Debugging in the recommended IDE (VSCode, nRF Connect SDK extension) still doesn’t work reliably after three weeks of effort.

• It appears that the lwm2m_client was not actually developed or tested with the Thingy91X.

• No sensor is working out of the box

• Merging sensor configs back from Thingy91 is a dead end as well - some sensors have been changed or are not supported (e.g. accelerometer), but the software has not been updated accordingly.

This is surprising, given the Thingy91X is being actively promoted as the new poster child for nRF91. The current state of software support (especially for LwM2M, which is highlighted in documentation and marketing) makes it nearly impossible to evaluate the platform for real-world use.

Is there any way to get lwm2m_client fully running with debugging, sensor values, and low power on Thingy91X in the short term?

• Are there any upcoming updates, workarounds, or early-access branches that properly support the new board and sensor configuration?

• What’s the recommended path for teams that want to start field trials (not just hardware bring-up) now with the Thingy91X and LwM2M?

We’d really appreciate a clear statement or guidance on how to proceed – and ideally, some pointers to working example code for the Thingy91X.

Many thanks in advance for your support and any quick fixes or timelines you can provide.

[cellular_iot]

We've seen, there is another sample using LWM2M which seems to be way more up to date with Thingy91X: nrfcloud_multi_service. As we are a renowmned manufacturer of standard compliant products, a nordic-specific cloud is no option for our customers.

Questions:

• is it possible to use nrfcloud_multi_service for any generic LWM2M cloud backend first and foremost Leshan?
• Which way would you guys expect to be the less expensive for our new product platform of LTE-M/NB-IoT based battery driven IoT devices - extending and optimizing lwm2m_client or nrfcloud_multi_service?
  
  

Thanks a lot!

[Achim Kraus]

Yes, the nrf/samples/cellular/lwm2m_client seems to come currently with a bad user experience and an gap in the docu. 

I tried it with NCS 2.9.1 and a Thingy:91X. It builds and after adding the credentials in leshan it also connects to the leshan. So far, so good.

Now I tried to add an observe for the temperature (that's what lwm2m is). In order to get that effective, it requires a registration update from the device to receive that observe request.
There the sample_description.rst stops (line 266) and leave the users where ever. I'm sure, if someone is patient enough, the next registration update will be triggered by time ... but that hint is also missing after line 266.

> Which way would you guys expect to be the less expensive for our new product platform of LTE-M/NB-IoT based battery driven IoT devices

I'm an other user, but for which reasons did you chose lwm2m?

Quite a lot of applications may be less expensive just using CoAP/DTLS 1.2 CID instead of LwM2M. That depends much more on the intended functionalities.

[cellular_iot]

We had a similarly positive initial experience, which encouraged us to explore the LwM2M path on the Thingy91X as well.
We gave LwM2M an initial thumbs-up because it’s based on CoAP/DTLS 1.2, offers a standardized end-to-end specification and implementation, supports low power operation, FOTA, interoperability, and more.

As a hardware product company, our customers expect our devices to work seamlessly across multiple standardized ecosystems — without any vendor lock-in.

But now, after running into issues with some pretty basic things — like just running and debugging the cellular IoT demo app on the latest and greatest demo hardware — we’re starting to feel a bit concerned.

Is this the point where we should stop and reconsider?
Maybe we should just connect a low-cost modem module to our existing platform, send a few AT commands... and call it a day?

[Achim Kraus]

That are two different points:

- the lwm2m sample client and the docu

- debug issues with the nRF9151

I didn't use lwm2m for longer, I mainly prefer to use CoAP/DTLS 1.2 CID directly (but I'm biased, though I'm a developer of Eclipse/Californium and so I like to use that direct to simplify the things).

I also didn't use the debugger for longer. I mainly use logging to see, what happens. With a Thingy:91(X) and the BLE interface it's even easy to use that in the field with an android device and an app. But if you need debugging, then it's pain.

> send a few AT commands

That depends much more on your experience with that. In my experience this is far away from "a few AT commands". And for sure far away for the energy consumption and reliability of a nRF9151. I run about 50 devices, some are online without any reboot for more than 270 days. The others have received either software updates or have been restarted by users. In comparison to that, my experience with a BC68 years ago was about 3 week until a reset gets required, and 2 months until a power off/on was required.

[cellular_iot]

as always - your mileage may vary