Ble mesh code removing version part

RE: Ble mesh code removing version part

Trond Einar Snekvik — Tue, 31 May 2016 12:14:01 GMT

The comment I posted on your other question today should allow you to solve both problems.

RE: Ble mesh code removing version part

Manjunath — Tue, 31 May 2016 10:22:14 GMT

what you told i agree, but my requirement is to synchronize led in network. If i use this mesh code it value is updated with version this is not need for me. Because of version i am facing some problems,

I need only simple write function rbc_mesh_value_set(2, mesh_data, 1), so it should send to at least 3 devices.

Note: If any new node enter into mesh, it should not update automatically unless until any old nodes send the data.

for this requirement any sample code like mesh OR is their any possible to change mesh code.

please tell me how to do this.

RE: Ble mesh code removing version part

Trond Einar Snekvik — Tue, 31 May 2016 08:35:17 GMT

We usually solve this problem by assigning a single handle per device, and only let that device push on that handle. This way, there are never any version conflicts, and the handles only really work as source addresses.

You might still want to keep versioning around. If you remove all versioning, you can run into scenarios where messages are received out of order. If you for instance send a message to turn on a led, then immediately send a message to turn it off again, the "off"-message could catch up with the "on"-message, so that the "off"-message is delivered first, and "on" second. This will leave your LED in on-state, even though you pressed the off button last! By adding versioning, you will ensure that your messages are never delivered out-of-order, and this problem disappears. The downside is that your on-message never finds its way to the LED. This problem will never really go away until you add ack-messages or similar mechanisms to ensure that your messages are delivered before sending the next, as the mesh doesn't guarantee delivery.