Bluetooth Mesh - The Flexibility
When designing the application layer for Bluetooth Mesh (materialized as the Mesh Model Specification), we of course wanted to go as deep as possible to address particular application domains, like lighting. But at the same time we realized the concept of Generics (binary on/off, analog level with level / transactional delta / move control options) has been really powerful. Capable of fulfilling the needs of 80% of non-lighting applications. I was pitching the Generics since it's conception, arguing they are applicable to all sorts of use cases and device types.
After all most things that can be controlled are either on/off or analog-level type and 16-bit resolution is more than enough for most applications.
Then I was asked about a door open/close sensor: is "open" 0 or 1? What is the convention?
Well... ain't it rather obvious? Open is 1. Want a proof? Open your fridge. You'll see the light inside is on, and we've already defined light on as 1. So open is 1, closed is 0. My debater was not convinced: "sure you can represent many things as 0 or 1, but you have to be precise which state is 0 and which is 1. For a moment the universality of generics seemed to had gone... or at least not be sufficiently precise to live in a real world.
But only for a moment, until we came back with the concept of Properties. It ended up as the third mesh specification - the Mesh Device Properties. Supported by the set of Generic Property (Manufacturer / Admin / User) models and the Sensor models, today it consists of more than a hundred of precise definitions. It addresses variety of states that can be read, written, or reported as sensor values.
Examples? Building a sensor camera capable of reporting the number of people it sees? Define it as a Mesh Sensor reporting the 0x004C People Count property. Want to expose how many times your device has been power cycled - include the 0x006C Total Device Power On Cycles property in the Manufacturer Property model.
An by the way, if you have an idea that we have not covered in the initial release of Mesh Device Properties, just let us know. This thing is flexible by design, adding new properties to this specification is going to have an ultra-short release cycle. Not more than a week or two since a request comes in and is approved until it is included in the standard specification. We're inviting contributors who are eager to build variety of classes of devices taking advantage of Mesh Generics, Sensors and Device Properties concepts. Looking forward to your input!
After all most things that can be controlled are either on/off or analog-level type and 16-bit resolution is more than enough for most applications.
Then I was asked about a door open/close sensor: is "open" 0 or 1? What is the convention?
Well... ain't it rather obvious? Open is 1. Want a proof? Open your fridge. You'll see the light inside is on, and we've already defined light on as 1. So open is 1, closed is 0. My debater was not convinced: "sure you can represent many things as 0 or 1, but you have to be precise which state is 0 and which is 1. For a moment the universality of generics seemed to had gone... or at least not be sufficiently precise to live in a real world.
But only for a moment, until we came back with the concept of Properties. It ended up as the third mesh specification - the Mesh Device Properties. Supported by the set of Generic Property (Manufacturer / Admin / User) models and the Sensor models, today it consists of more than a hundred of precise definitions. It addresses variety of states that can be read, written, or reported as sensor values.
Examples? Building a sensor camera capable of reporting the number of people it sees? Define it as a Mesh Sensor reporting the 0x004C People Count property. Want to expose how many times your device has been power cycled - include the 0x006C Total Device Power On Cycles property in the Manufacturer Property model.
An by the way, if you have an idea that we have not covered in the initial release of Mesh Device Properties, just let us know. This thing is flexible by design, adding new properties to this specification is going to have an ultra-short release cycle. Not more than a week or two since a request comes in and is approved until it is included in the standard specification. We're inviting contributors who are eager to build variety of classes of devices taking advantage of Mesh Generics, Sensors and Device Properties concepts. Looking forward to your input!
Comments
Post a Comment