Bluez D-bus，“StartNotify”与“AcquireNotify”

Question

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

不幸的是，我还没有真正找到有关新“获取”接口的任何深入文档。对于没有太多 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，它们存在一些稳定性问题（蓝牙可能会因 SIGPIPE 而终止）。在他们的存储库中有一些 bluez 5.50 的补丁可以改进它。

Answer 2

我想我会跟进其他看到类似行为的人。奇怪的是，在尝试使用 bluetoothctl 发送命令的各种排列之后，我找到了一种无需使用 notify-acquire api 即可使其正常工作的方法。随机我发现，如果我通过“通知开启”启用通知，那么传感器供应商推荐的写入命令序列是否让传感器开始发送数据什么也没发生。但是，如果我做了所有这些，然后简单地使用“选择特征”返回到我启用的通知特征，它将开始发送数据。不知道为什么。无论如何，一旦我将传感器完全集成到我的应用程序中，它们实际上就可以工作而无需任何额外的东西。不知道为什么，因为我的代码直接基于 bluetoothctl 源但不管它似乎工作（到目前为止）......