Controlling the nRF52833 dk using serial communication, without the Python application.

[SiemV]

I am using the following setup:

1. A nRF52833 dk, running the serial example from the mesh sdk.
2. A nRF52840, running the light switch server example from the mesh sdk.
3. A pc running an application, which will send and receive serial commands to and from the nRF52833 dk.

This pc application has to do two things:

1. Send the serial commands to the nRF52833, so it can provision the nRF52840.
2. Send the serial commands to the nRF52833, so it can turn on and off the light on the nRF52840.

So far, I have succesfully sent and received serial commands like 'echo' and 'scan start' to the nRF52833, using the documentation (Infocenter/Software Development Kit/nRF5 SDK for Mesh v5.0.0/Bluetooth mesh stack user guide/Modules/Serial interface/Serial interface library). However, I have not yet figured out how to do either of the two points mentioned above. This is because I cannot find which commands I should and should not use, and in what order.

So my question comes down to: How do I provision and control the nRF52840 using the nRF52833 via serial communication?

[Hieu]

Hi SiemV,

In this thread's title, you mention you don't want to use the Python library. However, in your post, you don't mention this. So, to be on the same page, are you willing to use the Interactive PyACI Script?

If you are willing to use or are using the script, here is what its documentation says:

Commands available in the interface can be found in aci/aci_cmd.py. They are imported through the cmd namespace, for example cmd.Echo. Similarly, available events are found in aci/aci_evt.py and available in the evt namespace, for example evt.MeshMessageReceivedSubscription.

I have not tried this script myself, but based on the text above, you ought to be able to find the commands you need in aci_cmd.py.

Have you also tried to provision the devices using a different method, like the nRF Mesh Mobile App yet? It might be helpful to first try to get your mesh working as desired without using the Serial Interface yet; that would give you an idea of what to expect, as well as be sure that the rest of your setup works.

If my suggestions above can't work for you, let me know and we can figure something else out.

Hieu

---

Due to Christmas & New Year Holidays, our team is currently understaffed and will take longer than usual for responses and follow-ups. Our apologies for the inconvenience.

[SiemV]

Hi Hieu,

Thank you for your answer and sorry for not being complete with my information.

I intend not to use the PyACI script. My goal is to communicate exclusively using a desktop application I'm working on, which will be using regular serial communication.

I have used the PyACI script and through this way, I have been able to make the nRF52833 dk provision and control the connected nRF52840 node. In other words, I have achieved all desired functionality (see original post) that needs to be implemented in the desktop application using the PyACI script.

I have also been able to provision the nRF52840 (running the same light switch server example) using the nRF mesh mobile app. However, I have not been able to provision the nRF52833 dk (running the same serial example) with the mesh app. This is because the nRF52833 dk requires some setting up before it can be provisioned, and I cannot figure out how to do that succesfully, either through the PyACI script or regular serial communication.

Using a serial port monitor, I have analysed the traffic back and forth between the PyACI script and the nRF52833 dk during the provisioning process. I have tried to recreate this process manually, but failed to do so because some of the commands (like for example the provisioning ECDH secret) are different each time.

[Hieu]

Hi SiemV,

Sorry for the wait.

What kind of application are you running on your nRF52833 DK?

Did you check out the Serial Commands and Serial Events documentation pages? I would expect them to provide more information than reverse engineering the PyACI script's communications.

[SiemV]

Hey there,

The nRF52833 dk is running the serial example from the nRF5 sdk for mesh.

I have checked out both the serial commands and events documentation. On top of that, I have reviewed the provisioning documentation. These pages allowed me to succesfully send various commands (Echo, provisioning scan start/stop Provisioning provision and various other provisioning related commands). I have also received various events from the nRF52833 (Provisioning unprovisioned received, Provisioning link established, Provisioning ECDH request and various other related events).

What I do not understand is exactly which commands to send, in what order, and with what payload. I have tried following the Implementing provisioning documentation (linked above), by sending the commands displayed in the "provisioning procedure" diagram. In this order:

1. Provisioning scan start
2. (After an Unprovisioned received event is received) Provisioning scan stop
3. Provisioning provision
4. (After a Provisioning capabilities event is received) Provisioning OOB Use
5. (After a Provisioning ECDH request event is received) Provisioning ECDH secret

After sending the Provisioning ECDH secret command, a Provisioning link cloded event is received.

[Hieu]

It seems you have researched into this very thoroughly.

Which makes it really strange to me that, are you saying even though both the PyACI script and your custom PC application are doing the same thing, your application doesn't work, while the PyACI script works?

Just double checking since that would be very strange.

[SiemV]

The PyACI script and the PC application don't do exactly the same thing yet. This is because some commands are different each time I provision the nRF52840, so they require a different payload every time. One of the commands that has this "issue" is the ECDH secret command.

I was wondering if you know how to determine the payload of this command, and the ones in my previous comment, or if I'm doing something else wrong entirely.

[Hieu]

SiemV said:

I was wondering if you know how to determine the payload of this command, and the ones in my previous comment, or if I'm doing something else wrong entirely.

I merely know the concept that the ECDH Secret is going to be a key sharing procedure to encrypt messages. Thus, it makes sense that the payload has to be different each time. (See more in this article)

As for the implementation details of how exactly that key, and subsequently the message's payload, is calculated/generated, I'm afraid that I don't know.

There are two directions I would recommend here:

• Modify the PyACI script into some sort of library that generates commands for your application
  This is the approach I better recommended, since it should save you a lot of time.
  
  
• Reverse engineering the ECDH Secret command of the PyACI script
  The ECDH Secret command is most likely involved in the /mesh/provisioning.py folder. But you probably know that.

For both approaches, the PyACI source code is available here: https://github.com/NordicSemiconductor/nRF5-SDK-for-Mesh/tree/master/scripts/interactive_pyaci. But you probably already have that from the installation of the script.
I embarrassed myself here, the script is available with the SDK.

How feasible do you think those approaches are for you?

By the way, I am out of office for the rest of the week. If you need urgent support, please mention and we will try to find an alternative.