Control of indications

[Malcolm]

In my device I send data using a characteristic with indications. The client sets the indication and data is then sent. I understand that when a device is bonded the values of characteristics remain, and the value of the indication is persistent. This will mean that on the next connection, data will be sent immediately.

However it is important that I read some of the characteristics before data is sent (such as the clock in the device).

Is there a mechanism to reset the value of indications on disconnect, so that my client can read the characteristics and then enable the indication?

[Malcolm]

If I have control of the server side, would it be permissable to disable indications when the client disconnects, so that it is disabled on next connection? This may go against described behaviour of BLE.

[Hung Bui]

Hi again, 
If you have control over the server side, you can decide not to send notification even if the CCCD value is set. You can have an extra flag to be set before you send the notification (independent from the CCCD value)

If you are not planning to qualify for a certain Bluetooth SIG's profile, I don't see any problem to not re-enable CCCD on the server side if you choose to do that on a proprietary profile. 

[daviddedwin]

In a bonded connection, If you clear CCCDs locally, they will go out of sync between the client and Server as the client will remember the CCCD state.
CCCD = Client Configuration Characteristic Descriptor and as the name implies, its owned by the client.

As Hung suggests, you are likely to lose GATT compliance with this behavior.

It would be a lot simpler to just stop HV Indications on disconnect and re-send  the HV Indication when connection is re-established. The HV Indication will not be sent unless you explicitly re-send it after a disconnect, so there is no danger of HV Indications being sent automatically on re-connect. The value you are sending in the HV Indication is updated in the GATT database even when the HV Indication fails to be sent due to disconnection, so on re-connect you can send the HV Indication again if the previous HV Indication had failed.

I hope this is clearer.

[Hung Bui]

Thanks David for great explanation :) 

[Malcolm]

Our concern is if the server disconnects before the client has opportunity to disable indications, hence my question.

[Hung Bui]

In that case you would need to modify the server so that it won't send notification if a certain flag has not be cleared.
Or if you can't modify the server, you can configure the client so that it ignore the notification data until it has write to a certain characteristic.