Review last

The last article covered the concept of a Bluetooth Mesh, how iOS can develop a Bluetooth Mesh, and what iOS needs to do to develop a Bluetooth Mesh. It explains in detail how bluetooth Mesh is configured. In this article, we will continue the problem left over from the previous article: how to send messages to the nodes in the Mesh.

News classification

Messages can be classified into the following three categories in terms of usage scenarios:

  • Configuration message: A message that sets configuration information for a node with a network, for example:Nodes add/delete AppKey, bind/unbind Model in nodes AppKey, add subscription address, set publishing address, reset nodeThat sort of thing.
  • General message: bySIGBluetooth definitionMeshGeneric messages such as:General switch status message, general brightness message, etc. Configuration messages are also generic messages, but they have different functions, so they are distinguished here.
  • Custom messages: thoughGeneral newsIn the third party library has helped us to achieve, it is very convenient to use. But because the function is too simple, basically can not meet our development needs, then can only useCustom message.

The first two of the above three types of messages in the NRF third-party library have basically been implemented, we just need to use the method to achieve the requirements, for the use of third-party library here will not be too much explanation, want to use or have to carefully study their own.

Custom message

I’ll focus on custom messages here, but I’ll briefly talk about generic messages to see the difference between the two. General message: a function defined by SIG. The opcode of the message is two bytes at most (for example, the opcode of model binding AppKey is 0X803D, and the opcode of model setting publishing address is 0X03). Here, opcode is the unique identifier of a function. Custom messages: The opcode of the custom message is different from that of the general message. The opcode of the custom message occupies 3 bytes, among which the last two bytes are the ID registered in SIG by the manufacturer of the manufacturer model, and the first byte is 0xC0 and calculated by our custom opcode and operation. So the number of Opcodes we can use is 2 to the sixth power = 64. The following is the code for the vendor-defined message about opCode:

public extension VendorMessage {
    
    /// The Op Code as defined by the company.
    ///
    /// There are 64 3-octet opcodes available per company identifier.
    /// Op Code is encoded in the 6 least significant
    /// bits of the first octet of the message Op Code.
    var opCode: UInt8 {
        // If 3 and F are published together, it will prompt sensitive words and cannot be published
        // So I changed the hexadecimal to binary --> 0b00111111
        return UInt8(opCode >> 16) & 0b00111111
    }
    
    /// The Company Identifiers are 16-bit values defined by the
    /// Bluetooth SIG and are coded into the second and third octets
    /// of the 3-octet opcodes
    var companyIdentifier: UInt16 {
        return UInt16(opCode & 0xFFFF).bigEndian
    }
    
}
Copy the code

The second version of that NRF third-party library now provides class definitions for custom messages, as shown above. However, the SDK does not currently provide an interface for sending and receiving custom messages. That is to say, if you want to achieve custom message sending and receiving function, you can only use the format defined in the library on the basis of their own implementation. See the library demo for a custom message sending and receiving feature.

What do you need to do to develop bluetooth Mesh for iOS?

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — line — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

The following is a summary of my work in developing bluetooth Mesh.

Bluetooth Mesh workflow

Distribution network flow

1. Scan bluetooth devices with 1827 service. 2. Connect devices, discover services, features, subscribe to read features. 3. Call the network access invitation method in the third-party library to invite the device to the network and wait for the device to return component data. 4. Call the device network allocation method in the third-party library to complete network allocation and assign unique addresses to nodes and elements. 5. Add AppKey to the node. 6. Assign the specified AppKey to the model binding. 7, the implementation of our company’s own equipment certification agreement, all completed before the real network success.

The process of connecting to a proxy node

1. Scan the Bluetooth device with 1828 service (once the network is configured, the service inside the device will change from 1827 to 1828, and the UUID of the corresponding service will also change, but it is still one read and one write, which is defined by the Bluetooth Mesh protocol). 2. After scanning, verify whether the node belongs to the current Mesh network, which can be verified from the data broadcast by the proxy node. 3. After passing the authentication, connect to the device, discover services, features, and subscribe to read features. 4. Start sending heartbeat packets periodically to synchronize the time between the node and the mobile phone.

Data persistence in Mesh networks

After creating a Mesh and adding several nodes to the Mesh network, the information cannot be stored on the device. After all, the device can store only a small amount of data, so it can only be stored persistently on the mobile phone. The third party library for Blue Tooth Mesh provides data caching, but does not meet our need to store multiple networks. Therefore, the third party library code has to be changed.

1. At the beginning, the data cache class was modified to take the ID of the Mesh network as the saving path and save the data of different Mesh networks in different paths. 2. Later, the Mesh network import and export function is required, which can be bound to the user. The user logs in to another mobile phone account, and only needs to invoke the following interface for obtaining network list to obtain the Mesh network data and save it in the mobile phone. 3. To ensure the sharing of iOS and Android Mesh information, we discussed a set of protocols to save the key data of the Mesh network, so as to realize the binding of the Mesh network with users and the requirement of cross-platform.

To sum up, data caching is very complicated to implement, because the data of the Mesh must be synchronized at all times.

This is the end of the iOS Bluetooth Mesh development summary. The main purpose is to record the implementation ideas of the relatively important places encountered in the development of Bluetooth Mesh, so as to facilitate my future search when I forget. I also hope to provide some experience and information to iOS peers who are developing Bluetooth Mesh.