I am using NRF Logger to research this issue. Here is what I found:
The device has total of 3 characteristics with property 'Notify' - 2 of them belongs to the service I am working with, and another one is under different service:
Service 00001801-0000-1000-8000-00805f9b34fb
characteristic 00002a05-0000-1000-8000-00805 (I don't need this service)
Service 0000fff0-0000-1000-8000-00805f9b34fb
characteristic 0000fff1-0000-1000-8000-00805f9b34fb - this is the one I need
characteristic 0000fff2-0000-1000-8000-00805f9b34fb
When I call Starter.manager.SetNotify(service_id,characteristic_id,True)
for Characteristic 0000fff1-0000-1000-8000-00805f9b34fb,
NRF Log shows 3 calls one after another for _EACH_ characteristics above, that is, single call actually generates 3 calls for all characteristics of connected device that have 'Notify' property:
gatt.setCharacteristicNotification(00002a05-0000-1000-8000-00805f9b34fb, true)
gatt.setCharacteristicNotification(0000fff1-0000-1000-8000-00805f9b34fb, true)
gatt.setCharacteristicNotification(0000fff2-0000-1000-8000-00805f9b34fb, true)
Is this expected functionality?
Also, NRF log shows that after these 3 calls are registered - nothing else happens after that, that is, the log ends. Even though I send SetNotify(..,False), and then Disconnect - logger does not register that. So BLE communication is actually completely stalled after this.
When I disconnect from device and try to scan for it again, it does not shows up in discovered list, and status LED on device show it is still connected. This confirms that after sending SetNotify no further BLE commands are actually transmitted.