Interesting... I'm surprised this hasn't come up before since we have much more Linux users that Mac and this is basically the same issue we recently solved on Mac.

For the BlueZ case though, I think we can solve it a better way by using AcquireNotify. We do know that not all devices correctly report "notify" and "indicate" flags though. So the logic would have to go like:

If d-bus characteristic object has property "NotifyAcquired" then use "AcquireNotify" else use "Value" property change.

This way, it would just work as expected without a need to write a discriminator.

On the other hand, since users would have to write a discriminator for Mac anyway, maybe it isn't worth the extra complexity? On the other, other hand, since Linux is much more popular, it might be worth it still since many users only care about running on Linux.

if is_notification(data):

Ah, I see you built the discriminator into the notification callback instead of using the one in CBStartNotifyArgs. So if this works on Mac but doesn't work on Linux, I'm not sure how adding a notification discriminator on Linux would work. It should be doing the exact same thing.

It should be doing the exact same thing.

Oh right, in the CoreBluetooth backend, we assume that if there is a pending read request then the changed value must be the response to the read request and don't send the notification in that case. However, that isn't 100% foolproof without a discriminator since a notification could be received after the read request but before the read response.

I've updated it to optionally use ActiveNotify if the characteristic presents it and removed the discriminator. This is definitely a better solution. Let me know what feedback you have on the changes!

Thanks!

Hi @dlech, do you have any additional thoughts on the changes above?

Thanks!

I added one more tweak to add some logging the the stop_notify() function and did some more testing. I like the way this turned out! Let's hope it don't break in unexpected ways! 🤞