Closed fhunleth closed 5 years ago
This library may be useful: https://github.com/edrosten/libblepp. See the blog: https://deathandthepenguinblog.wordpress.com/2016/09/29/libble-simple-bluetooth-low-energy-on-linux/
If nothing else, this library has great documentation. The one caveat is that I believe that it only handles the host side of BLE and we really want to be a device.
Here's another library: https://github.com/sandeepmistry/node-bluetooth-hci-socket/
Here's buildroot: https://delog.wordpress.com/2014/10/29/bluetooth-on-raspberry-pi-with-buildroot/
Here's another reference to pi 0: https://jaigouk.com/raspberry-pi-zero-w-for-iot-dev-env/
@fhunleth A comment regarding libblepp and why it's not relevant... I'd say it is. We want to be a host, scanning for beacons, since we've attached them to things and want to report enter/exit events from various zones.
I'm investigating creating a nerves system with bluez and all that stuff by following some pointers and grabbing inspiration online but wouldn't mind just using this and the normal rpi3 system, if possible.
Would it require less effort to set up a wrapper for libblepp, intended to be used with nerves than creating a custom nerves system?
Since writing that, I've heard from a couple people who have interest in BT host stacks, but they haven't done anything to my knowledge. If you create something, please let us know.
There was some discussion on Slack about what the pi3-miniuart-bt overlay
is for, so I'm pasting this here for posterity:
The reason this exists is that the Rpi Zero and 3 have two hardware UART interfaces, one of which is connected to the Bluetooth chip and the other to the UART pins on the board. One of the UARTs is actually software-defined “mini-uart” inside the processor whereas the other is a “real” hardware UART block. By default, the “real” one is used to talk to the Bluetooth chip, and the mini-uart is exposed to the UART pins on the board. Since Nerves doesn’t currently support BT officially, we apply this “overlay” by default to switch them so the “real” one is exposed on the pins. The reason for this is that the “real” one is independent of the CPU clock frequency and will perform better in general than the mini-uart. If you want to use the BT interface, though, you should switch them back to default because the BT interface is going to be more sensitive to the UART performance and you’ll just have to live with a flakey UART interface on the physical pins.
Also, anyone interested in this topic may want to join the #nervesbluetooth channel on the Elixir Slack
Adding to the list of findings: https://github.com/alfert/nerves_bluetooth
Adding this for posterity as well, since it has scrolled off the Slack history already. https://github.com/verypossible/harald
Closing. If you're interested in Bluetooth on Nerves, please check out https://github.com/verypossible/harald. File issues there or go to the Elixir lang slack's #nervesbluetooth channel support.
Currently, if you want to use Bluetooth with Nerves you need to either integrate bluez in a custom system image or use
nerves_uart
against an RN42 or Adafruit Bluefruit. It would be really nice have a Elixir project that could be pulled in for BLE support that doesn't require all of bluez and yet would still work with a Raspberry Pi 3 BT chip or a USB BT dongle.The end goal is to provide an API like what Adafruit does with their Bluefruit modules to BLE (except Elixir, not AT commands). The Raspberry Pi 3 BT module (and most other cheap BT modules/dongles) are connected via a UART connection to the main processor, but the interaction are pretty low level. There's a protocol called GATT and some other stuff that needs to be implemented or integrated. I "believe" that this is within range of us doing. It will look really hard in the beginning, but as we get more familiar, it will be ok. I think that the key is avoiding like the plague anything original Bluetooth and keeping the BLE parts simple. This will probably be limited to BLE devices at least initially.
This issue is to track work on a Nerves BLE projects. Please watch this issue if you're interested in helping. We'll still communicate on the elixir-lang slack, but important findings can be logged here so that they're easier to find. Once a prototype of this is available, we'll move discussion over to that project.