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. 是否有任何理由不对所有传感器（甚至使用旧/较低 MTU 的旧传感器）使用“AcquireNotify”/“ReleaseNotify”？
2. 使用“AcquireNotify”时，是否在其他特征上使用“ReadValue”/“WriteValue”，还是应该使用“AcquireRead”/“AcquireWrite”？

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

Answer 1

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