Can I Integrate Generic OnOff Server and Generic OnOff Client?

Hey everyone,

First of all, thanks for your time. I am a complete newbie to Bluetooth Mesh and I have a small question regarding two of the samples of Bluetooth Mesh viz.,. Light and Light switch samples. 

I have a Board which should read the status of the Switch and send it to the Mobile Application whether it is on or off, The same board should be able to control the relay based on the input from the Mobile Application.

As per the webinars I have gone through, I have got some clarity that,

1. Read the status of the Switch and send it to the Mobile Application is similar to Light Switch Sample, where Board is Client and Mobile is Server.

2. Able to control the relay based on the input from the Mobile Application is similar to Light Sample, where Board is Server and Mobile is Client.

Now I want these two particular models to be in one single project. How to handle this?

Please correct me if I am wrong, but this is what I comprehended from the documentation on Bluetooth Mesh,

Method 1: I should add a handler, to Generic OnOff Server such as Light sample, to publish the status of the switch periodically so that mobile application will know the current status. Here, Board will be Server and Mobile application will be client.

or

Method 2: I should add handler, to Generic OnOff Client Such as Light Switch sample, to handle the Get and Set Messages. Here, Baord will be client and Mobile application will be server.

Is this the way? Is there any other example or sample that I need to refer? And what will be efficient way to solve my project?

Thank you in advance,

Kalyan.

  • Hi,

    If your phone is participating in the Bluetooth mesh network, then the phone should be capable of asking for the status of the light directly. Bluetooth mesh models are typically made such that the (digital) state is stored where the (physical) state is. For a setup with a light, a switch and a phone, this state is at the light. You would then have the Light be the server (since it holds the state, the on or off status of the light), and the switch and phone both have a client.

    With one light and several switches, if those switches are supposed to know the status of the light, then one way would be if those switches are all in one group, and the light publishes to that group on every state change. Then all switches (and the phone) will receive the updates, so they know the state of the light.

    The above means, if I understand your use case correctly, you do not need to implement two models (both client and server) for your switch. Rather, both switch and phone act as clients, and they both get the information from the light. When the phone connects to the network (I assume it will be out-of-range from time to time) then it must poll the light to know what the initial state is. After that, it receives updates on state change.

    Regards,
    Terje

  • Hi Tarje, 

    Thank you for your detailed answer. I just want to repeat what you said and confirm whether I understood it correctly or not for more clarification. 

    You mean to say that,

    Light shall be the server. 

    Phone shall be the client. 

    If both the devices are connected, Light shall publish the data upon state change and phone will receive it.

    If phone is connected after a disconnrction, then phone shall get the data from the server which is light. Upon subsequent transitions, light shall publish the state and all the clients will receive it. 

    Did I understood this correct?  Or Am I missing anything here. 

    Thank you very much and I really appreciate the help. 

    Thank you, 

    Kalyan. 

  • Hi,

    Yes, you seem to have understood it correctly. This is how Bluetooth mesh is designed to work.

    For setting the state of a server model, you use a SET message, which is responded to by a STATUS message to the sender of the SET message and a STATUS message to the configured publish address for the server model.

    For getting the status of a server model, you use a GET message, which is responded to by a STATUS message to the sender of the SET message.

    Those should be the building blocks that you need, for implementing your system.

    Regards,
    Terje

  • Thank you very much Tarje. Your help means a lot. Will be posting more questions if I get any. 

    You can close this thread. 

    Thanks again, 

    Kalyan. 

  • Hi,

    Thank you for the feedback. I have suggested my previous reply as an answer. Please verify the answer to close this case.

    Regards,
    Terje

Related