NRF Cloud Shadow Update / AT Command messaging delay

RE: NRF Cloud Shadow Update / AT Command messaging delay

AdrianT — Tue, 09 Sep 2025 14:29:28 GMT

So for the suggestions you have listed, we basically have to poll for the shadow config to retrieve changes.

I'll try that. Thanks!

RE: NRF Cloud Shadow Update / AT Command messaging delay

Maximilian Deubel — Tue, 09 Sep 2025 09:52:44 GMT

Hi Adrian! The structure of the MQTT library generally dictates the timing from its internal state machine. For more control over timing, I would recommend taking a look at the CoAP backend instead. Other than that, you could try using the `nrf_cloud_shadow_device_status_update` (send new status) or `nrf_cloud_shadow_transform_request` (request data using JSONata expression) functions to interact with the shadow more directly.

RE: NRF Cloud Shadow Update / AT Command messaging delay

AdrianT — Mon, 18 Aug 2025 08:53:44 GMT

Sorry for the really late follow up question. But is it possible to override the default behavior? In case we would like to set the device to "test" mode, where we need to be able to update shadow config quickly.

RE: NRF Cloud Shadow Update / AT Command messaging delay

Markku Lehto — Mon, 16 Jun 2025 13:57:00 GMT

Hi Adrian,

I believe this behaviour applies to C2D messages similarly.

Best regards,

Markku Lehto

RE: NRF Cloud Shadow Update / AT Command messaging delay

AdrianT — Wed, 11 Jun 2025 10:14:55 GMT

Thanks for clarifying. Is this the same case for C2D messages? We also observe the same behavior

RE: NRF Cloud Shadow Update / AT Command messaging delay

Markku Lehto — Tue, 10 Jun 2025 11:25:17 GMT

Hi,

Our underlying infrastructure sends shadow update notification when one of these conditions are met:

1. Device or application successfully updates the shadow

2. Publishing a MQTT message

If this is not a case, we need to investigate this.

Best regards,

Markku Lehto