This article aims at helping those developers who want to use the vendor specific models in their Bluetooth Mesh products.
The concept ‘Model’ is defined in the section 2.3.6 of Mesh Profile Specification 1.0. It’s good to understand the concepts client and server model, in the following example, we will use this architecture.
It’s also defined in the section 2.3.6 of Mesh Profile Specification 1.0.
“Models may be defined and adopted by Bluetooth SIG and may be defined by vendors. Models defined by Bluetooth SIG are known as SIG adopted models, and models defined by vendors are known as vendor models. Models are identified by unique identifiers, which can be either 16 bits, for SIG adopted models, or 32 bits, for vendor models.”
Before reading this article, it’s recommended to read the article - Log System first. The output information will be shown from the RTT or serial terminal as they were introduced in that article.
There are 3 projects in the example.
The example supports both being provisioned by a standard provisioner, or being provisioned by the node itself by the test class command. The symbol PROV_LOCALLY in the file my_model_def.h decides which way the node uses. If it is defined, the nodes will provisioned themselves at boot time when they are unprovisioned, and the server node will publish to the group address the client node subscribes from and subscribe from the group address that the client node publishes to, the same for client node. If the symbol is not defined, they will send out the unprovisioned device beacon after boot when they are unprovisioned, waiting for a provisioner to provision and configure them.
Before introducing the server and client model, there are 3 concepts I want to introduce firstly. See figure 1, figure 2 and figure 3. This are the standard behaviors that the client and server models follow, which means all the opcodes defined later with the name “xxx Get/Set/Set unacknowledged” will use the “Reliable Get/Reliable Set/Unreliable Set”.
Figure 1. Reliable Get
Figure 2. Reliable Set
Figure 3. Unreliable Set
To be simple, there is only one group created and the provisioner configures both the client and server model to publish and subscribe to this group. Below are the definitions of the Client and server models
This example is originally designed to use SLWRB4104A as the mesh nodes and SLWRB4103A as the provisioner. If you don’t have them, you probably need to migrate the existing projects to fit your boards. Below steps assume that you have the desired boards, and the migration effort is not covered. Follow below steps to run this example.
Figure 4. Provisioner Serial Terminal
Figure 5. Client RTT Terminal
Figure 6. Server RTT terminal
This article doesn't aim at introducing the soc provisioner, the reason why we use it is because the Bluetooth Mesh app doesn't support configuring the vendor models yet. Some codes in the provisioner project are hardcoded to fix value so it can't be used as a generic provisioner. I know my colleague has an updated version covering both the SIG and vendor models, please navigate to above link for more information.
This example implements the periodical status update feature in the application layer. This can also be implemented using the model publication state in configuration server, section 4.2.2 of Mesh Profile Specification 1.0. I prefer to implement it in the application layer since only the nodes implementing the configuration client can modify the period value in publication value if using the configuration server, however, the client nodes probably don't.
The images do not load on this article.
Could you check it?
The article has been updated to the Bluetooth Mesh 1.3.0 GA SDK, and the images should load now. New feature - periodical update added.
I download the"vendor_model_client". the folder"log_module" is empty. when build the project, a error showing:
../app.c:5:10: fatal error: log.h: No such file or directory
make: *** [app.o] Error 1
I had the same issue, the files are in the log_module folder on the github repo but they don't download when you download the whole thing (not sure why). You can just download them manually and put them back into the log_module folder of the project you are trying to build and it will work.
Here is a direct link to the subfolder on Kevin's github.
I used git and the log module is a submodule in the project, so you can type "git submodule update --init" or add "--recursive" when you clone the project. If you download it directly not using git, you can download the log module from here.
Thanks for this mesh vendor model example.
I have been able to modify the model in order to transfer an uint8_t buffer instead. Howerver, I can't send a buffer payload of 192 bytes or up to the (256-9) limit of the publish function. The publish function (gecko_cmd_mesh_vendor_model_publish) returns no errors, and actually works at the first or second attempt but after a short while no more messages are sent to the other nodes. When I limit the buffer to 191 bytes, all goes well.
Can you please help?
I have noticed that what is actually happening is that the message is being split into two messages. The maximum payload of each messages seems to be 128 bytes.
- Is there a way to increase this limit in order to avoid message splitting?
- Alternatively, is there a way to find out is the received message is part of a larger message ?
I have since discovered that recv_evt has a "final" field to indicate if the message being received has been split.
I got above error when i was trying to load the provisioning firmware to the SLWRB4103A, is anyone facing the same problem?
The example has been updated to the latest Bluetooth Mesh 1.4.0-GA SDK.
@WAI KIN KOH, can you please create a ticket to our support portal, there will be dedicated Studio support engineer to help you.