blissha: resolve adapter by MAC via BlueZ D-Bus, not sysfs - #2
Merged
Conversation
added 2 commits
July 7, 2026 00:19
Pinning a blind to an adapter by its Bluetooth MAC failed on Ubuntu 26.04 with "no bluetooth adapter found", even for the correct, present controller. The resolver read the address from /sys/class/bluetooth/hciN/address, but that kernel/BlueZ no longer exposes an `address` file under the adapter's sysfs dir, so every adapter was skipped. (It would also fail in a container that mounts the D-Bus socket but not host sysfs.) Resolve the MAC through BlueZ over D-Bus instead (ObjectManager → org.bluez.Adapter1.Address), which is authoritative and matches how the bridge already drives the adapters. The sysfs read is kept as a fallback for older systems where D-Bus enumeration isn't available. Matching remains case-insensitive (it always was — EqualFold), so this was never a case issue. Adds unit tests for the sysfs matcher (fixture dir) and the object-path→hciN helper; the live D-Bus path is exercised on-device.
With one dongle per room, the two blinds scanned concurrently on different adapters and the second blind never connected: it failed with "scan was stopped unexpectedly" and then "Operation already in progress" on every retry. Root cause is in tinygo/x/bluetooth (v0.15.0) Linux scanning: Scan watches the org.bluez.Adapter1 "Discovering" property but does not filter by adapter path, so when one adapter's scan finds its device and stops discovery, a scan running concurrently on a *different* adapter sees Discovering=false, aborts, and leaks its StartDiscovery — leaving that adapter stuck "in progress". Use a single shared scan mutex for all blinds (instead of one per adapter) so only one BLE scan runs at a time across every adapter. Connects still run in parallel and scans are brief, so the practical cost is negligible. Docs updated; the ScanMutex contract now documents the cross-adapter hazard.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pinning a blind to an adapter by its Bluetooth MAC failed on Ubuntu 26.04 with "no bluetooth adapter found", even for the correct, present controller. The resolver read the address from /sys/class/bluetooth/hciN/address, but that kernel/BlueZ no longer exposes an
addressfile under the adapter's sysfs dir, so every adapter was skipped. (It would also fail in a container that mounts the D-Bus socket but not host sysfs.)Resolve the MAC through BlueZ over D-Bus instead (ObjectManager → org.bluez.Adapter1.Address), which is authoritative and matches how the bridge already drives the adapters. The sysfs read is kept as a fallback for older systems where D-Bus enumeration isn't available. Matching remains case-insensitive (it always was — EqualFold), so this was never a case issue.
Adds unit tests for the sysfs matcher (fixture dir) and the object-path→hciN helper; the live D-Bus path is exercised on-device.