cagnulein / qdomyos-zwift

Zwift bridge for smart treadmills and bike/cyclette
https://www.qzfitness.com/
GNU General Public License v3.0
391 stars 111 forks source link

[REQ]: Bluetooth Device Exception List for Virtual Bridge #2695

Open Novamusix opened 6 days ago

Novamusix commented 6 days ago

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:

Thank you for you consideration

cagnulein commented 6 days ago

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 https://github.com/cagnulein/qdomyos-zwift/issues/2695 to @cagnulein https://github.com/cagnulein.

— Reply to this email directly, view it on GitHub https://github.com/cagnulein/qdomyos-zwift/issues/2695#event-14849455911, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAALYWHYI5HERE2OHN4CJLLZ5DL7DAVCNFSM6AAAAABQQ4I2NOVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJUHA2DSNBVGU4TCMI . You are receiving this because you were assigned.Message ID: @.***>

cagnulein commented 6 days ago

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 https://github.com/cagnulein/qdomyos-zwift/issues/2695 to @cagnulein https://github.com/cagnulein.

— Reply to this email directly, view it on GitHub https://github.com/cagnulein/qdomyos-zwift/issues/2695#event-14849455911, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAALYWHYI5HERE2OHN4CJLLZ5DL7DAVCNFSM6AAAAABQQ4I2NOVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJUHA2DSNBVGU4TCMI . You are receiving this because you were assigned.Message ID: @.***>

Novamusix commented 6 days ago

Thank you for looking into this.

I was able to do the following

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 commented 6 days ago

image

Novamusix commented 6 days ago

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 commented 6 days ago

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 commented 5 days ago

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 commented 5 days ago

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 https://github.com/cagnulein/qdomyos-zwift/issues/2695#issuecomment-2437840673, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAALYWDMICBSQG4J54F7CXDZ5JEKRAVCNFSM6AAAAABQQ4I2NOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZXHA2DANRXGM . You are receiving this because you were mentioned.Message ID: @.***>