search

cagnulein / qdomyos-zwift

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

Sometimes Zwift doesn't discover the bridge #60

Closed cagnulein closed 3 years ago

cagnulein commented 3 years ago

if it helps, i saw the issue on both running zwift on my iPad and laptop. again it's not a super big issue, i just restart it now i have my kill script. if you open another issue log and want me to help with logs, i'll happily provide, or if you want to focus on other pressing matters that's fine to, as it's not a big issue. i just thought i'd mention it in case it was something easy to tweak 🙉

Originally posted by @rickoneeleven in https://github.com/cagnulein/qdomyos-zwift/issues/57#issuecomment-734973424

cagnulein commented 3 years ago

Logs https://github.com/cagnulein/qdomyos-zwift/issues/57#issuecomment-733156608

rickoneeleven commented 3 years ago

okay so just had a run, same issue. this time instead of having hciconfig hci0 leadv 0 on a @reboot script, I had it in my go.sh which I run to start the program, so it ran hciconfig about 60 seconds before I opened zwift, and still I couldn't see the brige, so I ran kill script, ran go.sh again and then it appears. i've never not had it appear the second time I run the program 😕

rickoneeleven commented 3 years ago

doubt it helps but: when it didn't pick up bridge on first run: debug-Sat Nov 28 08_05_31 2020.log

when it did on second run: debug-Sat Nov 28 08_08_00 2020.log

(ohhh and i had no segfaults this run, so never got to see the awesome restart)

cagnulein commented 3 years ago

@rickoneeleven uhhh very interesting, in the first log there is an error on startup

Debug: BTLE_DBUS::connect() failed "org.freedesktop.DBus.Error.NoReply" "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken." Debug: bluetooth.cpp void bluetooth::debug(QString) "Sat Nov 28 08:05:56 2020 1606550756399 domyostreadmill::error UnknownErrorUnknown Error"

i guess it's related to the behaviour. I will check into it

cagnulein commented 3 years ago

@rickoneeleven mmm is it possibile that the first log was running not with sudo? because it's full of

Debug: bluetooth.cpp void bluetooth::stateFileRead() Open status.xml for writing failed

and probably it's because there is a permission issue

rickoneeleven commented 3 years ago

i'm always root, in .bashrc I have "sudo su" so everything I run is as root, I don't need to sudo

cagnulein commented 3 years ago

ok but it's definitely something with the permissions. maybe you can check to be really root before running the bridge using the "whoami" command...i can put also some checks inside the bridge, so we can intercept this issue.

cagnulein commented 3 years ago

ok i added a check on the startup of the bridge. tell me if you have any issue

rickoneeleven commented 3 years ago

100% root didn't discover zwift bridge: debug-Sat Nov 28 16_19_46 2020.log

killed and started it manually, it detected bridge but seg faulted after a few seconds: debug-Sat Nov 28 16_20_41 2020.log

it auto reconnected: debug-Sat Nov 28 16_20_49 2020.log

cagnulein commented 3 years ago

debug-Sat Nov 28 16_20_41 2020.log this one has the DBUS issue. Did you use my last commit?

rickoneeleven commented 3 years ago

yeah that is the latest commit, just built it prior to running - anyway you can echo commit/build id to logs just so you're sure?

cagnulein commented 3 years ago

no ok, i trust you :) i have to add a version in the source code, it's simplier :)

cagnulein commented 3 years ago

ok i moved the init of the zwift part after the init of the treadmill and i also added the version in the logs :P tell me if something change :)

rickoneeleven commented 3 years ago

same 😕 100% root

ran first, no qwift bridge: debug-Sat Nov 28 16_54_03 2020.log

killed and ran a second time, it appeared: debug-Sat Nov 28 16_54_16 2020.log

what I did notice that may be something or nothing, is at the end when i killed it the second time, the treadmill stopped straight away, im sure it usually takes about 30 seconds after kill for the BT to disconnect (i always wait for it to disconnect BT before turning treadmill off)

cagnulein commented 3 years ago

wait wait wait in this first log i saw this

Debug: GATT connection from device "20:16:D8:D7:62:4D" "X230-0519" Debug: Group "RemoteSignatureKey" not found in settings file Debug: Written Char: "{49535343-8841-43f4-a8d4-ecbe34729bb3}" "f0cb030001ff0100000201000000010005010100" Debug: bluetooth.cpp void bluetooth::debug(QString) "Sat Nov 28 16:54:08 2020 1606582448304 characteristicWritten f0 cb 03 00 01 ff 01 00 00 02 01 00 00 00 01 00 05 01 01 00" Debug: HCI event triggered, type: 3e Debug: Received size: 3 data: "020f02" Debug: MTU request from client: 527 effective client RX MTU: 512 Debug: Sending server RX MTU 512

so bridge was connected to zwift! maybe you didn't wait enough? This commit has changed something, so, when you have time, try again please.

rickoneeleven commented 3 years ago

okay okay okay, let me reboot pi, start it again and wait a minute - be right back

rickoneeleven commented 3 years ago

no - it didn't show up this time, i didn't even restart it this time i just waited a minute or two - it did connect to treadmill debug-Sat Nov 28 18_13_27 2020.log

cagnulein commented 3 years ago

This time there isn't any sign of connection, tomorrow I will check deeper. Thanks for your time ;)

rickoneeleven commented 3 years ago

Thank you 😄

cagnulein commented 3 years ago

Another thing to test to give me more data is to try with nrfconnect when zwift doesn't see the bridge

rickoneeleven commented 3 years ago

ohhh god not that tool, I can never make sense of it 🦗 i'll try

cagnulein commented 3 years ago

Why? I love it, it's the best bluetooth tool in the world :D

rickoneeleven commented 3 years ago

you asked https://photos.app.goo.gl/PdP8CE2NaiFrWpX9A

rickoneeleven commented 3 years ago

after review of my video, i'm guessing the bridge is connecting to something else other than zwift, because i usually start the bridge first, then launch zwift and it takes 30 seconds or so to get zwift ready for BT connection, by that time the bridge has already connected to something else.

then when i kill bridge and start it again, zwift is already running so it connects to that first... maybe?

any way to filter out it connecting to whatever rouge device it is connecting to first?

cagnulein commented 3 years ago

The bluez Is definitely the raspberry and yes we can filter out any unwanted device. I will think about it this afternoon. Have a good Sunday lunch with your wife that she loves me :D

cagnulein commented 3 years ago

Stupid shower thought: i guess it's at linux bug. So, if i created twice the zwift interface we should solve it, no?

rickoneeleven commented 3 years ago

Only one way to find out 😆

cagnulein commented 3 years ago

@rickoneeleven done! tomorrow i will add also a filter for zwift device

rickoneeleven commented 3 years ago

cool, i'll be running tonight so can test it then :heart:

rickoneeleven commented 3 years ago

tested it this morning, still needed to do a kill/go shuffle to get it to advertise bridge ⚡

cagnulein commented 3 years ago

ok thanks, it would have been too easy

cagnulein commented 3 years ago

@rickoneeleven only if you have time to put in the toilet: i found that the command 'btmon' could sniff the HCI commands to the raspberry bluetooth adaptor.

So if we run btmon in parallel for 2 session (1 not working and 1 does) we should compare them and try to understand something more.

I will do it myself if only i was able to reproduce it /(

rickoneeleven commented 3 years ago

i still think it's related to the bridge disappearing quickly on the first start, as if it's connecting to something else, where you going to add a filter so the bridge would only take connects from the zwift app?

cagnulein commented 3 years ago

filter is not so easy to insert but if you have this doubt, we can check the log: in the log the device who connects to the bridge will be printed out

cagnulein commented 3 years ago

100% root didn't discover zwift bridge: debug-Sat Nov 28 16_19_46 2020.log

for example, in this log, i saw no sign at all of a connection to the bridge. so i guess the path "something is connecting to my bridge without my consent" it's a wrong way.

When you will have some time, i guess the correct way it's using the btmon, i'm quite confident that the issue is in the bluez qt implementation. But i need some logs to send to the qt guys

cagnulein commented 3 years ago

I think it's related https://github.com/cagnulein/qdomyos-zwift/issues/61#issuecomment-738559748 This morning i will release a patch, maybe fix this issue too

rickoneeleven commented 3 years ago

Cool ill test later ❤️

cagnulein commented 3 years ago

committed

rickoneeleven commented 3 years ago

It wasn't fixed in d5424a38fac9c20498c3170f8e3830ea95955735 - I always reboot the pi before testing, the other day without a reboot it did seem to connect first time, so I thought you'd fixed it. I rebooted and had to kill/go to get it to appear.

Same with this commit, started bridge, didn't show, killed it and started it again and it appeared 👍

cagnulein commented 3 years ago

i'm closing this one. feel free to reopen it :)