[REQ]: Bluetooth Device Exception List for Virtual Bridge

[Novamusix]

Feature Request:
Is it possible to create an exception list to ignore specific Bluetooth devices/ID's from trying to connect to the virtual bridge? So in my case, I want to prevent the Echelon bike (ECHEX-3-189898, CE:AF:39:CD:C0:37) from trying to connect to the bridge and maybe other conflicting devices I may have identified, but allow all other devices such as the family's phones/tablets to connect via a 3rd party app.

Description:
I’m using QZ on a Raspberry Pi to connect to a Proform Treadmill with the Virtual Bluetooth bridge enabled. I successfully connect to the bridge via the Runna app (Android) to control the treadmill and follow structured training programs.

Recently, I purchased an Echelon Ex3 smart bike and use the QZ Android app to bridge it. However, I’ve noticed that when the Echelon bike is powered on, the treadmill bridge stops broadcasting.

Steps to Reproduce:

1. Turn off all known Bluetooth devices
2. Use phone to view available Bluetooth devices but don't pair
3. Turn on only the treadmill and the Raspberry Pi
4. Verify the treadmill bridge is broadcasting via the phone
5. Wait 5 minutes and check treadmill bridge remains broadcasting and visible.
6. Power on the Echelon bike.
7. Observe that the treadmill bridge stops broadcasting and is no longer visible
8. Raspberry PI remains connected to the treadmill but can longer be bridged

Additional Observations:

• It appears the Echelon bike is trying to auto-connect to the treadmill’s virtual bridge but fails.
• When my Garmin watch is set to manually broadcast heart rate within settings, the Echelon automatically connects to it after about a minute, even though I did not pair it.
• Attached is debug file debug-Thu_Oct_24_11_59_44_2024.log with lines between 5060 to 5071 showing some attempt to connect and then being ignored at the same time I switched the Echelon on and when the bridge stopped being visible.

Thank you for you consideration

[cagnulein]

Let me check if it possible, I guess you have to do on Os side rather than app side Roberto Viola Software engineer and open source enthusiast http://robertoviola.cloud Il giorno gio 24 ott 2024 alle 13:39 Novamusix ***@***.***> ha scritto:

…

Assigned #2695 <#2695> to @cagnulein <https://github.com/cagnulein>. — Reply to this email directly, view it on GitHub <#2695 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAALYWHYI5HERE2OHN4CJLLZ5DL7DAVCNFSM6AAAAABQQ4I2NOVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJUHA2DSNBVGU4TCMI> . You are receiving this because you were assigned.Message ID: ***@***.***>

[cagnulein]

checked, the only thing that I can do on the app side, it's disconnecting once it's connected a particular device. check instead # Block a specific device bluetoothctl block XX:XX:XX:XX:XX:XX Roberto Viola Software engineer and open source enthusiast http://robertoviola.cloud Il giorno gio 24 ott 2024 alle ore 13:41 cagnulein ***@***.***> ha scritto:

…

Let me check if it possible, I guess you have to do on Os side rather than app side Roberto Viola Software engineer and open source enthusiast http://robertoviola.cloud Il giorno gio 24 ott 2024 alle 13:39 Novamusix ***@***.***> ha scritto: > Assigned #2695 <#2695> > to @cagnulein <https://github.com/cagnulein>. > > — > Reply to this email directly, view it on GitHub > <#2695 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAALYWHYI5HERE2OHN4CJLLZ5DL7DAVCNFSM6AAAAABQQ4I2NOVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJUHA2DSNBVGU4TCMI> > . > You are receiving this because you were assigned.Message ID: > ***@***.***> >

[Novamusix]

Thank you for looking into this.

I was able to do the following

• Switch treadmill off
• Switch echelon on
• Restart RPi and type the following

# On the RPi, Block echelon mac address
bluetoothctl trust XX:XX:XX:XX:XX:XX
bluetoothctl block XX:XX:XX:XX:XX:XX

• turn treadmill on with RPi connecting to treadmill
• This kept the virtual bridge up and running for that session.
• But restarting RPi , the echelon tried reconnecting bringing the virtual bridge down again.

In an attempt to make it permanent am investigating UDEV rules to trigger when echelon bluetooth tries to do an add action. Anyway, this will be a learning curve and not solved overnight, one step at a time :-)

Thanks once again for your direction and for the quick response.

[cagnulein]

[Novamusix]

Thanks, but that didn’t work. When I ran sudo journalctl -u bluetooth, I got the following message:

Oct 25 09:15:30 treadmill bluetoothd[490]: src/main.c:check_options() Unknown key BlockedDevices for group Policy in /etc/bluetooth/main.conf

I also tried BlockDevices as suggested by ChatGPT, but still no luck.

After checking the GitHub source code for BlueZ (src/main.c), I found no reference to BlockedDevices, so it seems this option might be deprecated

static const char *policy_options[] = {
	"ReconnectUUIDs",
	"ReconnectAttempts",
	"ReconnectIntervals",
	"AutoEnable",
	"ResumeDelay",
	NULL
};

For now, I will revert to the old fashioned, switch the echelon off and on as needed :-). But will still keep exploring out of curiosity. Cheers

[cagnulein]

what about

sudo nano /etc/udev/rules.d/81-bluetooth-block.rules
Add this line:

ACTION=="add", ATTR{address}=="XX:XX:XX:XX:XX:XX", ATTR{authorized}="0"

[Novamusix]

We’ve made some progress, but it’s not quite what I expected.

First, the UDEV rules seemed to be triggered (writing to a temporary log file), but the Bluetooth device was still able to connect when manually using bluetoothctl connect XX:XX:XX:XX:XX:XX, even with the rule ACTION=="add", ATTR{address}=="XX:XX:XX:XX:XX:XX", ATTR{authorized}="0".

It turns out the Echelon wasn’t connecting as I initially thought. Instead, when it became visible, it triggered something with the virtual bridge, causing it to go down.

To simplify things, I changed the QZ script from:

qdomyos-zwift -no-log -no-heart-service -qml -platform webgl:port=80

to:

qdomyos-zwift -no-gui -no-log -no-heart-service -name I_TL

To my surprise, the Raspberry Pi connects to the treadmill, controls it, and creates the virtual bridge, which stays up and running even with the Echelon on, with no interference.

It seems that using the QML web option was causing issues with the virtual bridge.

I’m happy to continue with this simpler approach since I only used the QML web option for the initial setup. However, it’s good to know in case this issue arises in the future.

[cagnulein]

Thanks for the update. I really don't know which could be the issue. Maybe a memory corruption issue? or a timing one Roberto Viola Software engineer and open source enthusiast http://robertoviola.cloud Il giorno ven 25 ott 2024 alle ore 15:52 Novamusix ***@***.***> ha scritto:

…

We’ve made some progress, but it’s not quite what I expected. First, the UDEV rules seemed to be triggered (writing to a temporary log file), but the Bluetooth device was still able to connect when manually using bluetoothctl connect XX:XX:XX:XX:XX:XX, even with the rule ACTION=="add", ATTR{address}=="XX:XX:XX:XX:XX:XX", ATTR{authorized}="0". It turns out the Echelon wasn’t connecting as I initially thought. Instead, when it became visible, it triggered something with the virtual bridge, causing it to go down. To simplify things, I changed the QZ script from: qdomyos-zwift -no-log -no-heart-service -qml -platform webgl:port=80 to: qdomyos-zwift -no-gui -no-log -no-heart-service -name I_TL To my surprise, the Raspberry Pi connects to the treadmill, controls it, and creates the virtual bridge, which stays up and running even with the Echelon on, with no interference. It seems that using the QML web option was causing issues with the virtual bridge. I’m happy to continue with this simpler approach since I only used the QML web option for the initial setup. However, it’s good to know in case this issue arises in the future. — Reply to this email directly, view it on GitHub <#2695 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAALYWDMICBSQG4J54F7CXDZ5JEKRAVCNFSM6AAAAABQQ4I2NOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZXHA2DANRXGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>