Service caching issue

[Michael]

I've read a lot in different posts about this but still fails to wrap my head around this.

We have a device using GATT with a few services, each with a few characteristics. Sometimes we would like to add new characteristics to these services after doing a firmware update.

The current problem is that the apps does not find these new characteristics until after rebooting the phone (iOS). 

I've read about the Service Changed Characteristic, but I can't see the usage for this in this case, as it seems to me this is meant to be used when updating the service dynamically during a connection. In our case that would mean that our firmware always has to set this flag, otherwise a phone that is not connected while performing the firmware update does not realise this.

How do we get around this issue?

/Michael

[Edvin]

Hello,

Actually, I think the Service Changed Characteristic is exactly what you are looking for in this case. It is not intended for updating the services during a connection, but between connections. The most common use case is that you update the firmware over the air (OTA DFU), and this new firmware will introduce new services, or change existing. To update the firmware, you need to reset the device (to start the new application), and then, the Service changed characteristic is used to tell the phone that it has new services, and that the phone should run a new service discovery. 

Now, the challenge is that if you have not included the service changed from the very beginning, then the phone will not discover this new service changed service, which is supposed to trigger the service discovery, so you need to "forget device" from your central (phone), and possibly turn bluetooth completely off and back on for it to do a new service discovery. Maybe even reboot the phone (it depends on the phone model). 

Best regards,

Edvin

[Michael]

Hi Edvin,

Having to go through this issue once would be ok if it works after that...

How will this work in practice? Doesn't the firmware always has to indicate that the service has changed then? If the a phone has been connected last week, and then the firmware update is performed, how will the device know to indicate that service has changed when the phone connects at a later date? Or a second phone?

It seems like the device in that case has to always indicate that the service has changed, hence making the caching useless.

/Michael

[Edvin]

Not sure about the details when the device is not bonded. It is usually the peer manager that handles this. Note that devices in field usually doesn't change services, and if they do, they usually support bonding. And different phones usually have different ways of triggering service discovery. Some does whenever they connect to a device that is not bonded, some do only if it has been a while since they were last connected, and so on.

This is mostly an issue for the developers, and not the end users. 

Test it. Perhaps the service changed service will trigger a service discovery every time if the devices are not bonded. 

BR,

Edvin