Hi! I've implemented provisioning using protocomm with BLE (nimble) as the transport. Now, I am trying to add a new characteristic to the service in order to obtain some additional information about the device. Adding the characteristic has been no trouble, and shows up correctly when scanning & discovering from my PC. However, the device is coupled with a mobile app, and iOS is using the cached characteristics from the previous version of the firmware. From my research, it seems that iOS requires the service changed indicator in order to rediscover services & characteristics, otherwise it uses cached versions. I've searched quite a bit and can't seem to find an example of adding the service changed indicator when using protocomm with BLE (though I think regular ble servers use ble_svc_gatt_changed).
As far as I can tell, I need to use the service changed indicator in order for the phone to stop using the cached characteristics which does not include the new endpoint. Any advice on how to do so in conjunction with protocomm would be appreciated.
Thanks!
Indicating Service Changed Protocomm Provisioning using BLE
-
- Posts: 1
- Joined: Mon Apr 15, 2024 11:02 am
Re: Indicating Service Changed Protocomm Provisioning using BLE
Sorry for responding to an old thread, but did you ever manage to get this working? I've also hit the wall of iOS not discovering new services after provisioning. From what I've read, the device needs to advertise the Generic Service Attribute at the point of provisioning so that the service changed indication can trigger a new service discovery in iOS. Our goal if possible is to keep the bond in place after provisioning so the user doesn't have to re-pair to use BLE after scanning the QR code.
Re: Indicating Service Changed Protocomm Provisioning using BLE
Still need to solve this. IDF 5.2 changed the characteristics's handles from those of IDF 4.6 and connection from laptops and phones are failing. The Service Changed characteristic would probably solve this.
Re: Indicating Service Changed Protocomm Provisioning using BLE
I have not solved this yet. It creates real problems when connecting to desktop machines.
Anyone?
Anyone?
Who is online
Users browsing this forum: No registered users and 75 guests