我的团队一直在尝试实现蓝牙 LE“api”一段时间。我们决定使用 BLE 而不是传统蓝牙，因为 iOS（我们的客户端设备类型之一）阻止任何不在其批准的设备列表中的人使用传统 BT。我们主要使用在带有 Ubuntu Server 22.04 LTS 的小型边缘设备上运行的 Intel AX200/AX201 蓝牙硬件。尽管我们还使用 Raspberry Pi 4 和 nVidia Jetson 进行了一些开发测试。
在意识到 BLE 没有真正的 Java（我们的核心语言）桥接器/绑定后，我们在 StackOverflow 上得到了指导，建议 Linux 上的大多数自定义 BLE 都是通过自定义 BlueZ 源并将其自定义 GATT 特征添加到 BlueZ 源来完成的（例如修改
gatt-database.cpopenprintfread也就是说，即使是最简单的特性，我们也很难让蓝牙 LE 始终如一地工作。我们与某些设备的连接大部分是稳定的，而与其他设备的连接则非常不稳定。 （例如 iOS 与笔记本电脑）也许这只需要一些重试处理，但也......
我们一直看到，每当我们的 Ubuntu/BlueZ 堆栈进入某种“故障”状态时，实际的 BT 硬件就会完全变砖，直到我们执行完整的电源循环。只有在硬重启后，我们才能再次看到正常行为。
与此同时，蓝牙无处不在，虽然它通常是一个相当有缺陷的协议，但它通常只需一些小改动即可工作。所以我倾向于认为我们做错了什么。
所以 BlueZ+Ubuntu 对我们来说似乎太不可靠了，我们正在考虑使用基于 UART 或以太网的接口来代替，但在放弃之前，我在这里问一下......
我们真的遗漏了一些重要的东西吗？产品如何在基于 Linux 的系统上成功使用 BLE？ BlueZ 对每个人来说都是绝对可怕的吗？我们应该使用不同的库吗？我们应该使用不同的硬件吗？
我的问题可能很模糊，因为我们甚至不知道根本问题是什么，除了 BLE 对我们来说是一个充满错误的混乱之外。
你肯定走错方向了！正如 Emil 所说，正常的方式是使用 DBus 命令与 Bluez 交互。但我不得不承认，处理 DBus 比您想象的要困难。
可以用任何语言与 DBus 进行交互。你可以在 Python 中找到很多例子。还有 Java DBus 绑定，当然也有 C 语言的绑定。如果您尝试实现外围设备，我建议您尝试我的库中的“外围设备”示例：https://github.com/weliem/bluez_inc。您可以修改该示例来定义您自己的服务和特征。
我猜大多数使用 BlueZ 的人都使用 DBus API (https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc)，任何有客户端的语言都可以使用它DBus 的库，而不是修改 BlueZ 的源代码。
如果您想尝试与 BlueZ 完全不同的解决方案，您可以在 https://github.com/Emill/node-ble-host 尝试我的库，在我看来，它更易于使用。然而它是为 Javascript 编写的...
仅供参考，大多数 BLE 产品不使用 BlueZ。 Android 和 iOS 都有自己的实现，嵌入式产品（“裸机”）使用芯片制造商提供的蓝牙堆栈。