Beginner Help: Custom Light-Switch Mesh Dev Board Example

[MikeB]

BACKGROUND:

So I've got minimal experience with low-level development/low-level coding/digital hardware, being more of an antennas person before, but have been given a task that I have boiled down to the following architecture:

Host PC --> Cloud --> Raspberry Pi --> Network of Control Actuators and Sensors. 

Commands from the Host PC will either switch the actuators on/off (only this on/off binary is needed for now), or request sensor information. We currently do this with HM-10s running BLE, but this only allows up to 5 slave devices.

For demonstration purposes, ignoring integration with the RPi/electronics, and just using the dev-boards, I just want to use 1 nRF52832 device as a master/Client, and the other 2 I have as identical Slaves/Servers, each running multiple services, with each service having multiple characteristics. I don't have any sensors yet, so just want to change the status of the LEDs on the Servers through the Client. 

WHAT I WANT TO DO:

An obvious way to do this test is having each LED on each Server board representing a service. The characteristics of each LED could be On/Off, and two different duty cycles of pulsing when turned On. However, even using only 2 LEDs on each server, this is too much to do with only 4 buttons on the Client (2 servers * 2 services/LEDs * 2 characteristics ).

1.) So I would first like to just do (2 servers * 1 service/LED * 2 characteristics) in that a single LED on the server A can be turned on/off with button 1 on the client, the duty cycle can be changed with button 2, and the same with server B with buttons 3/4. 

2.) I then want to upgrade to plugging the client into a PC using USB to allow more complex commands, and more of them, using Python.

WHAT I'VE DONE SO FAR

Mostly background reading, getting the build toolchain up and running, and have run the light switch mesh example. This was cool to see, but was just following basic instructions, and now I'm at a loss where to go next.

MY QUESTIONS:

- Is the above a good way of demonstrating that Bluetooth Mesh is what our system needs?

- Is it a feasible approach within a month or two - remembering my minimal starting position

- What do I do to achieve these goals? I'm overwhelmed with the number of C files in each project. Should I start with the light switch example and modify it? I want to properly understand what's going on when I switch from this demonstration to the proper development cycle.

Thanks so much in advance, any advice appreciated.

[Bjørn Kvaale]

Is the above a good way of demonstrating that Bluetooth Mesh is what our system needs?

 You could definitely use Bluetooth Mesh for this usecase. Another option would be to use the multilink example we have, which supports up to 20 links to one central device. Do you want the sensors to be battery-powered or not? What about the actuators? Right now with mesh sdk v2.2.0, we do not support the low power node & friend node feature. As of right now, I would recommend using the multilink example if you want a node that can sleep. Then, you would have the following architecture: Computer -> Cloud -> Raspberry Pi -> nRF52 DK (as central) -> up to 20 different nRF52 based devices with connected actuators & sensors. I would definitely follow the testing setup & give this example a shot. Multiple customers always ask us about Bluetooth Mesh, when in practice multilink would work just as well. The multilink example also has the option of long range (requires 52840) & high throughput (link 1, link 2, link 3, link 4). The high throughput mode will work with both nRF52832 & 52840.

The downside of the multilink example is that there are not multiple paths to the device that is connected to the Raspberry Pi. Also, if you have a lot of nodes, then I would not recommend this approach.

Bluetooth Mesh has multiple paths if you have enough devices. The regular mesh relay nodes should not be battery-powered, as the radio needs to be on most of the time to listen for incoming packets from other nodes. For a low-power battery-powered sensor, you will want to look at the friend & low power (LP) node features. These features will let a friend node store incoming messages intended for the LP node when the LP node is asleep. When the LP node wakes up, it can poll the friend node for all relevant messages.

Although this feature is not yet available in the latest mesh sdk (v2.2.0), it should be coming soon. If you want to get more info on the potential release data, you can send me a private message on DevZone with your country location. Then, I'll put you in touch with your local Regional Sales Manager.

Is it a feasible approach within a month or two - remembering my minimal starting position

 I would say so, yes. :)

What do I do to achieve these goals? I'm overwhelmed with the number of C files in each project. Should I start with the light switch example and modify it? I want to properly understand what's going on when I switch from this demonstration to the proper development cycle.

 Yep, I would start with the light switch example in mesh sdk v2.2.0. Then, I would take a look at the interactive pyaci provisioner to provision the mesh network. This is a python script that could be run on a Raspberry Pi. I would test with a regular PC first. To get PWM working, I would look at this github example for adding PWM to the light switch example. A user guide is available for Android & iOS (see Mesh Hands-on *****_October2018.pdf). This example uses the nRF Mesh smartphone app, which is ok to use for a small mesh network. Be aware that the github example use slightly modified generic on/off server & client models compared to the mesh sdk v2.2.0. The example used is the proxy server model, but we have integrated both the generic on/off client & server models to enable a dev kit to operate as either a client (e.g. light switch) or server (e.g. LED).

It might be easier for you to start with the nRF Mesh app & then move over to the interactive pyaci provisioner when you have a small network up & running. The interactive pyaci script is a bit more difficult to understand IMHO.

Apart from that, you will need to figure out how you want to send the data from the Raspberry Pi to the cloud. Hope that helps!

Kind Regards,

Bjørn

[MikeB]

Hi Bjørn,

Thank you very much for your reply!

I should have noted in more detail the end vision that we will use Mesh for: The central computer (the RPi at the moment) will control hundreds of actuators and sensors, spread out over perhaps a 1km^2. The vast majority of these will be connected to mains power, with a smaller number of battery powered ones using the Friendship feature for battery conservation. This last feature is a fair way off being implemented, so I imagine the updated SDK will be available before then.

Based on this, I think Bluetooth Mesh is probably the best way forward, over e.g. any 802.15.4 protocols.

Thank you for the pointers on where to start! I will begin reading but will almost certainly have more questions in short time.

Kind Regards,

Michael

[Bjørn Kvaale]

Hi Michael,

No worries. Would you mind upvoting my answer if you thought it was useful? Thanks & have a nice weekend!