To use this module as a BLE central from a machine running Windows there are a few more interfaces that need to be implemented.

• [ ] Connect to a Device
• [ ] DiscoverServices on Device
• [ ] DiscoverCharacteristics on a discovered Services
• [ ] Write to a characteristic
• [ ] Receive notifications from a characteristic

See https://github.com/tinygo-org/bluetooth/blob/dev/gattc_darwin.go for example implementation in macOS.

The core of the low-level code needed to communicate with Windows Bluetooth interfaces has been written, see https://github.com/tinygo-org/bluetooth/tree/dev/winbt for more info.

This PR adds a function to retrieve the MTU of a characteristic on Darwin, Linux, Windows and SoftDevice.

Implementation details

I tried to keep the same signature on both implementations. So I had to adapt the Darwin implementation a little bit to match the requirements of linux:

• In Linux (bluez) we read the MTU property in the characteristic. So I did the same in other platforms, even though we read the MTU from the device.
• Since in Linux reading the MTU can fail, I added the same return type ((uint16, error)) on other platforms, even though it cannot fail.

Regarding Linux implementation, the MTU property is quite recent (bluez 5.62), so it is going to fail to anyone using an older version of bluez. I though about calling AcquireWrite as a fallback. This method returns a file descriptor to write messages and its MTU, and we could just call it and immediately close the file descriptor to get the MTU. But it felt ugly, and hacky, and I'm not sure if it has any other implications.

I wired up a HC-05 to a Raspberry Pi Pico's UART0. I connect the 3.3 to 3.3 and gnd to gnd and tx to GP1 and rx to GP0.

When working with the stock example:

package main

import (
	"time"

	"tinygo.org/x/bluetooth"
)

var adapter = bluetooth.DefaultAdapter

func main() {
	// Enable BLE interface.
	must("enable BLE stack", adapter.Enable())

	// Define the peripheral device info.
	adv := adapter.DefaultAdvertisement()
	must("config adv", adv.Configure(bluetooth.AdvertisementOptions{
		LocalName: "Go Bluetooth",
	}))

	// Start advertising
	must("start adv", adv.Start())

	println("advertising...")
	for {
		// Sleep forever.
		time.Sleep(time.Hour)
	}
}

func must(action string, err error) {
	if err != nil {
		panic("failed to " + action + ": " + err.Error())
	}
}

The error:

DefaultAdapter not declared by package bluetooth compiler (UndeclaredImportedName)

Is there additional setup necessary? There is nothing in the example showing how to handle the DefaultAdapter as the bluetooth mod on line 9 does not recognize it.

I am simply looking to run this example to connect to a central.

When I try to run the scanner example with -target circuitplay-bluefruit, the call to adaptor.Scan() results in a crash. The message itself seems to be obscured, nothing comes thru except the character p which I perhaps assume might be due to a panic getting lost?

Issue

In macOS 12 Monterey, developers have been reporting issues with CoreBluetooth device discovery. This issue manifests as a BLE scan returning no device results. This currently affects lots of BLE projects that use CoreBluetooth under the hood, such as Python Bleak.

Fix

The fix for this issue is to provide a non-empty list of service UUIDs to scanForPeripheralsWithServices:options:.

More context

This issue (feature?) has not yet been officially acknowledged by Apple. In the meantime, other projects are working to add user ergonomics around this issue. Bleak warns users who do not provide a list of advertised service UUIDs that MacOS will not return any results for their scan.

To serve macOS users, I would like to add support for tinygo Bluetooth to take a list of advertised service UUIDs when starting to scan. This is a first attempt at adding support for this to the Darwin adapter.

I know this breaks the interface and will not compile, but I'd like to start a conversation with this first draft of code. I'm totally OK with maintainers editing this PR however they like. I'm not familiar with this codebase and want to help fit this fix into tinygo – how can I help?

Adds service characteristic discovery. This change does not include characteristic reading or writing. It only allows obtaining their UUID and their properties (whether the characteristic supports writes, notifications, and so on. Checkout the winRT-go source file to view all properties).

This change removes the winbt package that included all the manually created WinRT classes and adds a dependency to saltosystems/winrt-go, which contains automatically generated WinRT API projections.

This will vastly simplify development, as developers won't have to go through the Windows IDL files to generate a Go struct that matches the Windows API they want to call.

~~All the code under winbt/winrt/<package> has been automatically generated. The change also includes utilities to dynamically generate UUIDs for parameterised classes and a reference counter used in delegates.~~

~~As I said in #13, the generated code has been added to the PR because the repository it belongs to is not yet public.~~

This PR adds the Device struct and the Connect and Disconnect methods.

When testing this, notice that calling Disconnect may not disconnect from the device. Disconnect only removes the references to it, and Windows will decide when to call disconnect (another program may be connected to it).

DIS service discovered UUID on macos: 180a0000-0000-0000-0000-000000000000

DIS service discovered UUID on others: 0000180a-0000-1000-8000-00805f9b34fb

specification: 128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID

This PR changes the API to always return pointers to DeviceService and DeviceCharacteristic instead of the value types to ensure consistency.

For example:

func (s *DeviceService) DiscoverCharacteristics(uuids []UUID) ([]*DeviceCharacteristic, error)

The slice is now []*DeviceCharacteristic instead of []DeviceCharacteristic so that any cached copies still refer to the same characteristic. This will make it a lot easier for the macOS implementation of the Read() function, among other things.

$ go run ./examples/scanner
panic: failed to enable BLE stack: MapToStruct: Field not found: Roles

goroutine 1 [running]:
main.must(...)
	/dev/shm/bluetooth/examples/scanner/main.go:23
main.main()
	/dev/shm/bluetooth/examples/scanner/main.go:11 +0x1df

os: Archlinux kernel: 5.8.10 bluez: 5.55 go: 1.15.2

The DeviceCharacteristics type implements io.Reader, but previously did not follow the semantics as defined in the docs. Several bugs are present that were fixed by this pull request:

1. the previous code always returned the full length of the data, regardless of how much data was actually read from the copy
2. io.EOF was never returned, meaning that we could never tell if the read was complete
3. the read always filled the buffer, then started over, meaning if the destination buffer was too small you would always get a partial read with no way to tell that the read was incomplete

This patch fixes this by caching the read internally, then copying from the read slice. The value is not actually read again using the upstream methods until the internal cached value is fully read.

It may also be beneficial to expose the internal read method in the future

func (*DeviceCharacteristics) ReadValue() ([]byte, error)

This would always allocate a byte slice, but would also always call the upstream read method, ignoring the internal cache. Effectively this would be the same as:

io.ReadAll(characteristic)

The documentation for DiscoverCharacteristics says:

If there is no error, the characteristics slice has the same length as the UUID slice with characteristics in the same order in the slice as in the requested UUID list.

However, at least on Linux, the code appears to just iterate through characteristics appending them to the slice as they are found. The documentation either needs to be changed, or the code updated to reflect the expected behavior.

What is missing?

go run ./examples/advertisement

tinygo.org/x/bluetooth/examples/advertisement

examples/advertisement/main.go:13:17: adapter.DefaultAdvertisement undefined (type *bluetooth.Adapter has no field or method DefaultAdvertisement) examples/advertisement/main.go:20:24: adapter.Address undefined (type *bluetooth.Adapter has no field or method Address)

Hi!

Upon inspecting the Bluetooth Assigned Numbers, I noticed a lot of them were missing in this library at this moment; the last update seems to be from 2021. I opened this PR to update the uuids and their generation.

Changes:

• Removed the data folder and added the Bluetooth Numbers Database as submodule instead. Now the 'uuid data' can be updated by pulling in the changes from that repo and running the generators.
• Variable names now remove 'illegal' characters based on a regular expression. I think using a regex is fine here, since this code only runs while generating the uuids. It is an easy way to get rid of weird characters like e.g. ® in "LEGO® Wireless Protocol v3 Hub Service".
• Updated the usage of deprecated strings.Title
• Added a dedup function to avoid naming collision. "Apple Reserved Service" is defined multiple times, for example. These get called AppleReservedService1, AppleReservedService2, etc.

Hi guys,

I am having some difficulty fetching the LocalName from an advertisement while running on Windows 10 (1903). I have no problem getting the manufacturer data, device address, and RSSI. I have tried 3 different computers running Windows 10 and had no luck.

To test, I am using the Central example in README.md and this is an example of what is returned.

scanning...
found device: FF:37:4A:A2:AA:60 -63
found device: 76:F8:55:B0:87:C0 -59
found device: F0:B3:EC:54:17:E4 -61
found device: 59:33:42:90:36:A4 -50
found device: FF:09:C7:01:14:2B -63
found device: 4B:06:6E:6D:9E:AC -65
found device: FF:37:4A:A2:AA:60 -66

I have tried v0.6.0 as well as the latest on dev.

I have had a bit of a look myself but quickly got out of my depth when it moved to WinRT.

Cheers

I have a temperature sensor peripheral that has an environmental sensing service, and there, two temperatures (same UUID).

A call to DiscoverCharacteristics, with either empty or the Temperature UUID, returns only one of the two characteristics.

Is this a bug or something yet to be implemented?