While working on the smart mesh for a year now, we always had the difficulty to find out what mesh nodes are available in your network. CSR as well as Feit Homebrite products use a discovery mechanism, by broadcasting PING packets when the user starts the mesh controller app. It also needs to find out how many groups are supported resulting in lots of packets and often does not yield results. Imagine, a node that does not listen at the time to save power.

Each node has a certain set of functions. E.g. light switches can control the light vs. the air conditioning unit can switch between heating and cooling. And there are any type of sensor available, some dedicated for room temperature measurement, some build-in, e.g. the battery level of a node. There are so many possibilities that it is hard to find a common ground. 

Profiles and Models

Bluetooth has always been all about interoperability between devices. Each device implements a profile, e.g. the audio profile of your headset, so it can work with any smart phone. Makes sense. In the case of the smart mesh, we define Models. Models are specified using a client-server architecture and implement Smart Mesh Applications.

There is a light controller model (server), and a light switch model (client), and a power switch model and a heater model and so on. Of course we found that the CSR defined light switch models don't implement all of the functions of our AIRcable SmartDimmer, or it implements it differently. We would need to create our own Vendor Specific Model and also allow the SmartDimmer to be a client and a server at the same time. Those specific models will them be able to implement the adjustment of the intensity of the night light inside the light switch, for example. Status updates, like the current power consumption when the light is on are also just unsolicited model messages. 

It is required to give each mesh node a certain type that is manufacturer specific. This certain unique type, which could be modeled according to the USB-IF should contain the vendor ID and the product ID, or the SIG may define their own Bluetooth assigned company identifier.

Our mesh products periodically send out a status packet that describes the product and it's capabilities. It basically is a PING RESPONSE packet, containing the product ID, vendor ID, battery voltage, internal temperature and the receiver's duty cycle, if the mesh node is not listening 100% of the time to save battery.

We transmit this packet on a predefined status channel.

Addressing and Status

Each node in the smart mesh has a unique address, the destination address. When packets are received they are decrypted and the destination address needs to match.  Then they are processed. Nodes can also subscribe to one or more group addresses, unicast, virtual and broadcast addresses. A group is also a unique address, just with a bit set. CSR device addresses are 0x8000-0xFFFE and group addresses are 0x0001 to 0x7FFF. In our case, we define the status channel as group ID 0x7FFF. All products transmit their status on that channel to let other devices know that they are available in the network. Rate depends on usability and how much the broadcast channel is able to bear. Once every 20 seconds is a good way.

Using one specific status channel for the whole network the user of a smart phone app can discover all devices around within 20 seconds. Using a bit of caching and the user experience is remarkable easy to deal with the smart mesh. There is no need to publish the information on 3rd party servers, such as Feit does it or download a certain mesh configuration before the mesh is usable by someone else in the family.

Configuration

Configuring mesh nodes is the same issue. Certainly, devices have their own individual settings. Those should be visible and controllable by any smart mesh controller, your smart phone e.g. We use configuration data blocks. On the broadcast channel, they publish their own configuration periodically, very specific to each product. Those packets don't need to be transmitted that often. A mesh controller app will then be able to change the configuration and send it back to the device.

While it is difficult to find a common model for all types of products, it would be best to standardize the transmission of status and configuration and let the individual product control the content of those packets. The CSRmesh implementation has not done that, but the SIGmesh has a good notion of a configuration data block, which contains components, model IDs, vendor IDs and configuration data.