Hi! There is a subscribe to change the byte characteristics of a specific service. Service UUID: 0000fee1-0000-1000-8000-00805f9b34fb, characteristic UUID: 00000009-0000-3512-2118-0009af100700. I don't know where to send the command. I know that to subscribe to the descriptor, you need to send \ x01 \ x00, and that all characteristics have the same NOTIFICATION_DESCRIPTOR = 0x2902.
In the program windows, this subscription is simply a slider
And it's not clear where to send the subscription command, because there is only a service field and a characteristic. Please help me figure it out. Device MiBand2
I also think it would be appropriate to ask here how to receive notifications from this characteristic? The method recivebyte also contains only a service and a characteristic, without a descriptor.
If you want to subscribe for notifications when a characteristic changes, use the RegisterFor... method with the corresponding type of interest, e.g., RegisterForBytes. Internally, the BLE extension will update the descriptor associated with the characteristic in order to receive the notifications. The WriteBytes method will actually write to the characteristic, not the descriptor, and if the characteristic is read-only will just result in an error.
Thank you! As far as I understand, the application will itself ask the device for the state of the bytes. Is there a way for the device to send the change of bytes to the application by triggering an event? As if you were actually subscribing to a descriptor.
Maybe I'm just misunderstanding what you are writing, but that is the entire point of RegisterFor... class of methods. The Read... methods will directly read the values whereas the RegisterFor... set up the necessary infrastructure at the OS level to get notifications of changes from the peripheral device. Both method classes trigger the same event (...Received). Any changes on the device side to the characteristic after an invocation of RegisterFor... will trigger the event at that point assuming both devices are still connected and within radio range.
Ok, that is, with a one-time initialization of "RegisterFor", the client activates on the server side the algorithm for sending a notification to the client side for any attribute change, and will not ask the server for the attribute value all the time?
Yes, that's part of the "low energy" part of BLE. Actively polling would be awful for battery life which is why we always advise people to use the register methods to get updates from the device rather than actively polling using a clock/read combination.
