How to control what a BLE mesh switch triggers?

[Marius Heil]

Hi,

I am currently trying to understand the BLE mesh concepts, but its a quite tough process. At the moment I am wondering the following:

Let's say that I wand to create a light switch with 2 rocker buttons. If I just want to switch a light on/off, it could be pretty simple. I guess, I would have 2 elements with a Generic OnOff Client and I would set the publish address of e.g. for the OnOff model on the first element to the group address that will switch a light. Then, when the user presses the first rocker switch, it would generate the Generic OnOff Set Message and would send it to the configured group address.

Now, I wand to reconfigure the switch so that it does not switch the lamp on/off, but it should dim it up with each press of a button. So I would remove the publish address on the Generic OnOff Client of the first element. Next, I would set the publish address for the Generic Level Client that is also bound to the first element.

Now, how does the Generic Level Client know which message it should send, once the user presses a button? How can I configure the button to either send a Generic Level Set message, with e.g. a value of 10000, or reconfigure it to send a Generic Delta Set message with a step count of 10? Or maybe another user wants to configure a delta step of 20 instead of 10. I think this must be configurable somehow, but I cannot figure out how. Hardcoding some action in the firmware of the switch would be a weird way to do it.

Of course, I could add some kind of virtual element that I use to change the switch mode and another element that I use to configure the delta step. But I think that would really bend the standard and would be completely different for every vendor and therefore would not provide any interoperability.

Thanks,

Marius

[tesc]

Hi,

I am not entirely sure I understand what you are looking for, so please let me know if I do not answer your questions.

The behavior of the switch when it comes to levels and increments, is regarded properties of the switch itself (i.e. properties of the Generic Level client.) Any configuration of, for lack of a better word let's call it the "sensitivity" of the button (i.e. how large delta a push or prolonged push will give) is not mandated by the Bluetooth mesh specification.

When sending messages to a group address, as a general rule it is best to use idempotent commands. That is, commands that give the same end result regardless of how many times they are issued. Generic Delta Set messages gets idempotency through handling a series of Generic Delta Set messages as part of the same transaction, where the messages within the transaction carry the cumulative values of the Delta Level field. See the Mesh Model specification for details.

Regards,
Terje

[Marius Heil]

Hello, the first paragraph mostly answers my question. However I am wondering how this would work in a real-world use-case. That basically means that if I buy a switch from different manufacturers, the one might dim the light in high increments, while the other switch will only increment it a tiny bit each increment. This seems to me like a huge Problem.

Of course the manufacturer can make that configurable, but the way to configure this would be entirely vendor specific and therefore different for each switch.

Using the switch for something different than e.g. a light might make the switch unusable for that use-case if it cannot be configured. E.g. a valve that needs to be opened and can only be opened in 3 steps would not work with a switch that only increments the level by e.g. 1000 because the user might need to press 65 times to reach the highest level.

Am I missing something?

[tesc]

Hi,

I am not sure if you are missing something, but I do not think you are.

The generic level state ranges from 0 to 65k, and the best bet for a generic device would be to operate on that entire range. I.e. a generic client model device should give the possibility to use the full range from 0 to 65k.

Using button presses the way you describe, i.e. one press-release of the button corresponds to one quantified amount of increase (or decrease) in level, does give some limitations. Another approach may be gradually increasing the level while the button is being pressed and held, starting gently to begin with, then accelerate the increase towards a "highest speed" of for instance 10k per second (total time from 0 to 65k in maybe 10 seconds if button is continuously pressed.)

If more configurability is desired for the buttons, that would be an app dedicated for the button, yes. Please note, however, that while the configuration of the button itself would then be a device specific app, the button device may interact with any generic Bluetooth mesh ecosystem. What devices it controls can be configured with any generic app. While it may in some cases be desirable to both assign the publish address of the button and change its functional characteristics at the same time, I am afraid there seems to be no standardization of the latter. Care should be taken, therefore, that the button device does provide as varied functionality as possible without need for reconfiguration.

Regards,
Terje

[Marius Heil]

thank you