Cannot connect custom board to nRF Cloud

RE: Cannot connect custom board to nRF Cloud

Burt — Fri, 14 Jun 2024 00:31:33 GMT

Thanks, Justin--very good explanation. I look forward to seeing the updated Add Devices menu.

Burt

RE: Cannot connect custom board to nRF Cloud

justin — Fri, 14 Jun 2024 00:12:10 GMT

[quote userid="89447" url="~/f/nordic-q-a/110797/cannot-connect-custom-board-to-nrf-cloud/488755"]Once I use nrf_cloud_onboard.py, there is no need to use Add Devices[/quote]

Correct. That script performs the onboarding, so no need to use the UI.

The "Add LTE Device" button allows you to onboard a device using JITP credentials (https://docs.nordicsemi.com/bundle/nrf-cloud/page/Devices/Associations/Provisioning.html#just-in-time-provisioning).
You can create JITP credentials for your custom device using a bms-<IMEI> device ID. You provide any PIN number you want when creating the JITP credentials and then provide that same PIN when adding the device to your team.
JITP credentials can be useful for testing, but are not recommended for real devices.

If you select the "Bulk Onboard" button, you can onboard your device(s) using a csv file (like what is produced when running the device_credentials_installer.py script).
This is what the nrf_cloud_onboard.py script does.

We are in the process of updating the Add Devices menu to be more clear.

RE: Cannot connect custom board to nRF Cloud

Burt — Thu, 13 Jun 2024 21:52:35 GMT

Yeah, they make zero sense, that crazy menu brought up by Add Devices. The only way I can add my bms-350457794634418 board (where I am using bms as a prefix) is to use the nrf_cloud_onboard.py script. So, what the heck is the purpose of the useless Add Devices menu? Once I use nrf_cloud_onboard.py, there is no need to use Add Devices. Prior to using nrf_cloud_onboard.py, Add Devices comes up with a 40142 error. It's crazy!! I'm tempted to think that Add Devices is only for Nordic DK and Thingy, but that's not what it claims. And that Add Devices button is in my face when I go to the Devices page (that lists current devices).

Burt

RE: Cannot connect custom board to nRF Cloud

Burt — Thu, 13 Jun 2024 19:48:57 GMT

I still have a question about below, and the question is how I make use of a custom prefix for a custom board if when I try to add the custom board to nRF Cloud I will be asked for the PIN or HWID. How can my custom board have a HWID when it has no nRF52840 or anything that looks like a MAC address?

CONFIG_NRF_CLOUD_CLIENT_ID_SRC_IMEI - If you enable this option, the ID is automatically generated using a prefix and the modem’s IMEI (<prefix><IMEI>). This is the default. You can configure the prefix by using CONFIG_NRF_CLOUD_CLIENT_ID_PREFIX. The default format of the prefix is nrf- and it is valid only for Nordic devices such as Thingy:91 or an nRF91 Series DK. For custom hardware, use a prefix other than nrf- by modifying CONFIG_NRF_CLOUD_CLIENT_ID_PREFIX.

RE: Cannot connect custom board to nRF Cloud

Burt — Thu, 13 Jun 2024 17:32:52 GMT

Hi Simen, thank you for the opportunity to improve the code, but the short answer to your question is "No!" I am chuckling, because it sounds so rude for me to say that so bluntly--even more rude would be to use all caps or even say "NO WAY." The longer answer: Looking again at the issue, I don't like the design in which the choice HW_ID_LIBRARY_SOURCE and the choice NRF_CLOUD_CLIENT_ID_SRC are set up as independent entities in the Kconfig files, but in most cases HW_ID_LIBRARY_SOURCE depends on NRF_CLOUD_CLIENT_ID_SRC or else one is not using NRF_CLOUD and it depends on something different. To do things really nicely, one has to consider every case. If I tried and missed a case, I'd look like a jackass. And even if I didn't miss any case, a restructuring of configuration might not be acceptable when existing configurations required changes. I like to point out that throughout my career I have had a knack for noticing these types of design issues. "These types" translates to "things that have to be fixed globally." One time I was "the guy in charge" and I was able to make some good build system changes. But I had to block a lot of people from checking in code to our ancient, locking source control system for 3 days. So even when I was able to make the changes, I caught a lot of flak for those 3 days. Fortunately, I was able to speed up the build system so people changed their tune.

If it is not practical to make big changes, I recommend that a documentation change be made to nRF Cloud (nordicsemi.com). There are a few places in "Configuration options for device ID" that should explicitly mention the corresponding required HW_ID_LIBRARY_SOURCE option.

Just for fun, here is an example of what might be nice: 1) I take the options HW_ID_LIBRARY_SOURCE_IMEI and HW_ID_LIBRARY_SOURCE_UUID out of the HW_ID_LIBRARY_SOURCE choice. That allows me to do something like:

config NRF_CLOUD_CLIENT_ID_SRC_IMEI
depends on NRF_MODEM_LIB
# depends on HW_ID_LIBRARY_SOURCE_IMEI
select HW_ID_LIBRARY_SOURCE_IMEI
bool "IMEI based value"

and

config NRF_CLOUD_CLIENT_ID_SRC_INTERNAL_UUID
bool "Modem internal UUID value"
depends on MODEM_JWT
select HW_ID_LIBRARY_SOURCE_UUID
help
Requires modem firmware version 1.3 or later.

Burt

RE: Cannot connect custom board to nRF Cloud

Burt — Thu, 13 Jun 2024 01:10:11 GMT

I'm trying to review everything in this ticket since it has been a while since I looked at it. I have found a bug in https://docs.nrfcloud.com/Devices/Security/Credentials.html : the statement "For details, see the Device Credentials Installer documentation." in the second note points to the python script rather than the documentation. It should be https://github.com/nRFCloud/utils/blob/master/python/modem-firmware-1.3+/README.md#device-credentials-installer.

Burt

RE: Cannot connect custom board to nRF Cloud

Pete Skeggs — Tue, 11 Jun 2024 20:43:48 GMT

The need for various CONFIG_HW_ID_LIBRARY_SOURCE values is not required when using CONFIG_NRF_CLOUD_CLIENT_ID_SRC_INTERNAL_UUID=y, but only when CONFIG_NRF_CLOUD_CLIENT_ID_SRC_HW_ID=y.

We will add a note to the documentation about the requirement for CONFIG_MODEM_JWT=y.

RE: Cannot connect custom board to nRF Cloud

Pete Skeggs — Tue, 11 Jun 2024 20:08:40 GMT

Hello Burt. Thank you for your feedback.

In reply to:

"I must have used create_ca_cert.py using the IMEI (not UUID) for the CN. Hopefully that is okay: I did not see any instructions stating that a particular CN should be used (I started off trying to work with IMEI prior to seeing that UUID is more "natural.""

The CN doesn't matter. The example in the docs here: https://github.com/nRFCloud/utils/tree/master/python/modem-firmware-1.3%2B#create-ca-cert shows:
-cn example.com

The next section explains how to use the device credentials installer: https://github.com/nRFCloud/utils/tree/master/python/modem-firmware-1.3%2B#device-credentials-installer. This section does say that create_ca_cert.py is required first.

We will add clarifying statements to the Securely generating credentials page.

RE: Cannot connect custom board to nRF Cloud

simensr — Tue, 11 Jun 2024 20:01:50 GMT

Hi Burt ! Are you willing to make a PR towards sdk-nrf with your suggested changes?

github.com/.../sdk-nrf

Simen

RE: Cannot connect custom board to nRF Cloud

Burt — Fri, 03 May 2024 02:28:14 GMT

Okay, I see that with an improvement one could make to asset_tracker_v2 application (ignore the added printf)

diff --git a/applications/asset_tracker_v2/src/cloud/nrf_cloud_integration.c b/applications/asset_tracker_v2/src/cloud/nrf_cloud_integration.c
index c624fd544..156cba1a6 100644
--- a/applications/asset_tracker_v2/src/cloud/nrf_cloud_integration.c
+++ b/applications/asset_tracker_v2/src/cloud/nrf_cloud_integration.c
@@ -303,10 +303,12 @@ int cloud_wrap_init(cloud_wrap_evt_handler_t event_handler)
#endif
};

-#if !defined(CONFIG_CLOUD_CLIENT_ID_USE_CUSTOM)
+#if !defined(CONFIG_CLOUD_CLIENT_ID_USE_CUSTOM) \
+ && !defined(CONFIG_NRF_CLOUD_CLIENT_ID_SRC_INTERNAL_UUID)
char hw_id_buf[HW_ID_LEN];

err = hw_id_get(hw_id_buf, ARRAY_SIZE(hw_id_buf));
+printf("cloud_wrap_init() HW_ID_LEN=%d hw_id_buf=%s\n",HW_ID_LEN, hw_id_buf);//BMS

if (err) {
LOG_ERR("Failed to retrieve device ID");
@@ -314,7 +316,7 @@ int cloud_wrap_init(cloud_wrap_evt_handler_t event_handler)
}

strncat(client_id_buf, hw_id_buf, IMEI_LEN);
-#else
+#elif defined(CONFIG_CLOUD_CLIENT_ID_USE_CUSTOM)
snprintf(client_id_buf, sizeof(client_id_buf), "%s", CONFIG_CLOUD_CLIENT_ID);
#endif

Then one could greatly simplify the prj.conf for the case of UUID: in prj.conf you just need to add

CONFIG_MODEM_JWT=y
CONFIG_NRF_CLOUD_CLIENT_ID_SRC_INTERNAL_UUID=y

and you can get rid of the use of the HW LIBRARY, like
-CONFIG_HW_ID_LIBRARY=y
-CONFIG_HW_ID_LIBRARY_SOURCE_IMEI=y

Burt

RE: Cannot connect custom board to nRF Cloud

Burt — Thu, 02 May 2024 20:59:33 GMT

Looking more at asset_tracker_v2/src/cloud/nrf_cloud_integration.c in v2.5.0, this looks a bit corny:

#define IMEI_LEN 15
#define CLOUD_CLIENT_ID_IMEI_PREFIX_LEN (sizeof(CONFIG_CLOUD_CLIENT_ID_IMEI_PREFIX) - 1)

#if !defined(CONFIG_CLOUD_CLIENT_ID_USE_CUSTOM)
#define NRF_CLOUD_CLIENT_ID_LEN (IMEI_LEN + CLOUD_CLIENT_ID_IMEI_PREFIX_LEN)
static char client_id_buf[NRF_CLOUD_CLIENT_ID_LEN + 1] = CONFIG_CLOUD_CLIENT_ID_IMEI_PREFIX;
#else
#define NRF_CLOUD_CLIENT_ID_LEN (sizeof(CONFIG_CLOUD_CLIENT_ID) - 1)
static char client_id_buf[NRF_CLOUD_CLIENT_ID_LEN + 1];
#endif

So they don't seem to acknowledge the existence of UUID based cloud client id, but then later in nrf_cloud_transport nct_client_id_set() they are smart enough to know that based on IS_ENABLED(CONFIG_NRF_CLOUD_CLIENT_ID_SRC_RUNTIME) not being true that they should ignore the malformed client_id. Okay, they clearly do the right thing, but it's pretty complicated so maybe that corresponds to me having had to jump through hoops to get things working!

RE: Cannot connect custom board to nRF Cloud

Burt — Thu, 02 May 2024 20:26:58 GMT

I got things to work. In addition to the CONFIG_NRF_CLOUD_CLIENT_ID_SRC_INTERNAL_UUID=y change, I also had to add CONFIG_HW_ID_LIBRARY_SOURCE_UUID=y and most likely comment out CONFIG_HW_ID_LIBRARY_SOURCE_IMEI=y. But in order to set CONFIG_HW_ID_LIBRARY_SOURCE_UUID=y I also had to add CONFIG_MODEM_JWT=y. None of this is explained in nRF Cloud (nordicsemi.com) under Connecting. Well, maybe it is further down on the page, but you really have to look hard, and certainly CONFIG_MODEM_JWT is not mentioned. Wait, actually someone reading the document would think they are okay with CONFIG_NRF_CLOUD_CLIENT_ID_SRC_INTERNAL_UUID=y but would have no way of understanding the subtle difference with that option vs CONFIG_NRF_CLOUD_CLIENT_ID_SRC_HW_ID. Anyway, someplace there is a suggestion that UUID is the default, but that's hard to square with the way that asset_tracker_v2 comes up. Something like

cloud_wrap_init() HW_ID_LEN=37 hw_id_buf=504b5839-3736-4877-80f8-1f1d740fa9aa
nrf_cloud_init() entered... param->client_id=nrf-504b5839-3736-4
nct_init() entered... client_id=nrf-504b5839-3736-4
[00:00:00.448,699] <inf> nrf_modem_lib_trace: Trace thread ready
[00:00:00.450,073] <inf> nrf_modem_lib_trace: Trace level override: 2
[00:00:00.450,683] <wrn> lte_lc: About to lte_lc_system_mode_set
[00:00:00.453,765] <inf> app_event_manager: MODEM_EVT_INITIALIZED
[00:00:00.559,814] <wrn> nrf_cloud_transport: Not configured for runtime client ID, ignoring
[00:00:00.653,045] <dbg> nrf_cloud_transport: nct_client_id_set: client_id = 504b5839-3736-4877-80f8-1f1d740fa9aa

after I threw enough options into prj.conf. Maybe you can show me a simplification.

One more question: the documentation states that nrf-<IMEI> will work as a client id only for Thingy and DK boards. Is that still true? I imagine so, but it sure would be a lot easier if I didn't have to jump through so many hoops for a custom board. So I ask the question.

Thanks,

Burt