How to use RBC_MESH_EVENT_TYPE_CONFLICTING_VAL

RE: How to use RBC_MESH_EVENT_TYPE_CONFLICTING_VAL

Trond Einar Snekvik — Thu, 01 Oct 2015 16:01:02 GMT

This seems like a very reasonable approach. As an alternative to waiting for some set amount of time after receiving SLEEP before going to sleep, you could look into using the TX_EVENT. I would recommend that you let the device report at least 3-4 TX events before sleeping, as to ensure that the device has safely relayed its message. Also, the TX event comes in when the tx is queued up for transmission (we'll change this for the next release), so it might get postponed if you put the mesh to sleep in the event handler.

The next release will bring some dramatic changes to the handle system, that may solve your memory limit. We'll basically unlock the ability to run with 65k handles, and store only a small subset for retransmission. We have seen some other usage scenarios similar to yours, and found that the static approach limits the potential of the mesh without much benefit, so we decided to change it. On the surface, the API will remain much the same, but your ability to fetch the content of each handle after the initial update event may be limited by your allocated cache size. Unless your application requires a lot of memory, you should be able to allocate more than 10-11 handles, if configured correctly. You need to change the linker address map (see the Scaling example), and set the RBC_MESH_GATTS_ATTR_TABLE_SIZE in the compile options.

RE: How to use RBC_MESH_EVENT_TYPE_CONFLICTING_VAL

sphudson — Thu, 01 Oct 2015 14:26:16 GMT

Thank you Trond for your response.

Our mesh has 32+ nodes. The nodes consist of a single "host" (or master) node and the other nodes being sensor nodes. The sensor nodes must be asleep most of the time since they run off of a battery. There are three (3) handles in the mesh: SLEEP, DATA_REQ, and DATA. The host has knowledge of the Bluetooth addresses of each sensor node in the system.

For each sensor node, the master node one-by-one puts the address of the node into the DATA_REQ handle. The DATA_REQ handle is then propogated throughout the mesh. Each sensor node will see that handle and if the address matches it's local Bluetooth address, then that sensor node will respond back by putting data into the DATA handle (which is then propogated through the mesh and back to the master node). The master node performs this same process for each sensor node in the mesh.

This is essentially the master polling each node for data, one-by-one. Once all sensor nodes have been polled, the master node sets a known value in the SLEEP handle which is then propagated througout the mesh. Each sensor node receives the SLEEP handle, waits for ~1-2secs, and then turns itself off to save battery. After 60 seconds, the sensor node wakes back up and turns on the mesh again. So, when the master node sends out SLEEP, it knows that the sensor nodes will wake back up in 60 seconds and will then starting polling each one again.

I originally was going to have a handle per sensor node, however we don't have enough memory to support that. I can't add more than about 10-11 handles without rbc_mesh_init() coming back with an error...

Do you see any issues with the above approach?

RE: How to use RBC_MESH_EVENT_TYPE_CONFLICTING_VAL

Trond Einar Snekvik — Thu, 01 Oct 2015 09:01:31 GMT

Hi, The CONFLICTING event should appear when a device receives a packet with the same version number as the one in the local GATT server, but different data. This typically occurs when you have two or more devices writing different data to the same handle at the same time, leading to a conflict somewhere in the network.

When you get a CONFLICTING event, the framework gives you the data that came in with the new packet, but does not overwrite the data in the GATT server. The overwrite decision is left to the application.

When sending a value, there is no feedback to the application beyond the return code of rbc_mesh_value_set(), and unless some other device is feeding the same handle, node#1 should never get a conflicting event.

The behavior you're experiencing doesn't sound like intended behavior. Which version are you on, and what's your mesh access address? Do you have more than two devices in the mesh?

We did have a bug in a previous version (v0.6.5 or so) where similar behavior could occur, but this should have been mitigated (and is tested for) in newer versions.

RE: How to use RBC_MESH_EVENT_TYPE_CONFLICTING_VAL

sphudson — Wed, 30 Sep 2015 16:44:59 GMT

Also note that after setting the value on node #1, I receive several sporadic RBC_MESH_EVENT_TYPE_CONFLICTING_VAL events. If I call rbc_mesh_value_set() on ndoe#1 with the value provided within the event structure, I still receive the CONFLICTING_VAL event even though the two nodes should match...