linux - Bluez D 总线， "StartNotify"与 "AcquireNotify"

Question

我有一个在使用 bluez d-bus api 的 Raspberry Pi 上运行的 C++ 应用程序。它支持来自不同供应商的多个传感器，但在大多数情况下，一旦我开始使用第一个传感器，添加新传感器就相当简单了。连接后我并没有真正使用任何太奇特的东西，只是“StartNotify”、“StopNotify”、“ReadValue”和“WriteValue”。不管怎样，最近我在添加几个新传感器时遇到了问题。两者都使用更大的数据包大小，因此使用数据包嗅探器我可以看到传感器协商更大的 MTU。无论出于何种原因，尽管在协商后我可以读取更大的值(value)特征，但无法启用(或无论如何接收)通知。使用 bluetoothctl 尝试不同的方法，我发现使用“acquire-notify”似乎可以解决问题。我还注意到新的“获取”命令返回 MTU，所以这可能与它有关。回到我已经支持的传感器，我还发现用“AcquireNotify”替换“StartNotify”似乎也适用于它们。所以我的犹豫是对所有传感器使用“AcquireNotify”(让我的代码更清晰)还是只对给我带来问题的新传感器使用。

不幸的是，我还没有真正找到任何关于新“获取”接口(interface)的深入文档。对于没有太多 bluez 历史的人来说，根本不清楚使用它们与原始界面相比的后果是什么。所以我的问题是双重的 -

1. 有什么理由不使用“AcquireNotify”/“ReleaseNotify”所有传感器(甚至是使用旧/较低 MTU 的旧传感器)？
2. 使用“AcquireNotify”时是否使用其他特征上的“ReadValue”/“WriteValue”，或者我应该使用“AcquireRead”/“AcquireWrite”？

非常感谢任何信息，谢谢!

Answer 1

AcquireNotify 返回一个您可以轮询和读取的文件描述符，并且通知不会通过 d-bus。使用 StartNotify 您可以从 d-bus 读取通知值。如果您在 GATT 通知中发送大量数据，您将能够使用文件描述符(并且没有 d-bus)获得更好的性能。

AcquireNotify/AcquireWrite 是相对较新的 API，它们存在一些稳定性问题(bluetoothd 可能因 SIGPIPE 而终止)。在他们的存储库中有一些 bluez 5.50 的补丁可以改进它。