Technic hub is difficult to pair with Remote

[davecparker]

On the TechnicHub, using Remote() to connect the BT remote, I found connection difficult, and it only succeeds with a carefully ordered and executed sequence. I found that the remote must be started first followed very quickly by the hub. If the hub program starts first, it will not connect, regardless of the timeout parameter.

As a new user, this is not the intuitive/logical sequence, so I could not get it to work at all despite many tries at first, and almost gave up. Then even once I found what works, it's still tricky in practice since programs run right away after download.

Steps to reproduce the behavior:

1. In a program for TechnicHub() use Remote(), with large or infinite timeout if you want
2. Run program
3. Press green button on remote to connect
4. Connection will fail (every time for me)

The InventorHub is more forgiving and can do it in either order.

[dlech]

Is the Technic hub also connected to your computer when you try connecting to the remote? If so, what operating system is on your computer? Does connecting to the remote work better if the hub is not connected to the computer (use the button on the hub to start the program)?

I don't have any problem connecting the remote to the Technic hub in either order locally, but we have had reports in the past like #397 where the computer can affect the connection.

[dlech]

Also, which firmware version are you running on the Technic hub?

[davecparker]

I did try disconnecting the hub from from the computer (I use Mac OS), quitting Pybricks entirely, restarting the hub, and even going into a different room away from nearby BT sources, but none of these helped. I tried again just now outside away from the house and mobile phones, and it still fails. Works consistently in the other order, though.

Technic Hub firmware is 3.2.0.

[dlech]

Just to make sure I am repeating this correctly, I'm running the following program:

from pybricks.hubs import ThisHub
from pybricks.pupdevices import Remote
from pybricks.parameters import Color
from pybricks.tools import wait

hub = ThisHub()

hub.light.on(Color.YELLOW)

try:
    remote = Remote()
    hub.light.on(Color.GREEN)
except OSError:
    hub.light.on(Color.RED)

wait(5000)

Start the program then turn on the remote.

VID_20221224_110001805.mp4

And it connects. What error do you get?

I don't suppose you have a Bluetooth sniffer?

[davecparker]

I pasted and tried your program (ThisHub()? undocumented feature? Nice) with sequence like your video, but it still fails, regardless of whether the hub is connected to the computer or not :( I get yellow light for a while then red light. Works in the other order.

I don't have a BT sniffer or know anything about that, but I can try if you send me info.
Is there a way to query the remote's firmware version?

[dlech]

I don't have a BT sniffer or know anything about that, but I can try if you send me info.

I bought one of these to use as a sniffer. It took a little while to figure out how to use it and it isn't able to see everything that is going on, but it has been helpful in some cases like the other issue I linked.

Is there a way to query the remote's firmware version?

The pybricksdev command line tool has a lwp repl command that is useful for this. If you are on macOS:

brew install pipx
pipx run pybricksdev lwp3 repl

It will wait for any LWP3 device to start advertising and attach to it, then show a prompt.

So at this point, turn on the remote.

At the prompt, enter:

>>> HubPropertyRequestUpdate(HubProperty.FW_VERSION)
>>> HubPropertyRequestUpdate(HubProperty.RADIO_FW_VERSION)

I get the following:

>>> HubPropertyRequestUpdate(HubProperty.FW_VERSION)
[11:30:00.792] INFO: sending: HubPropertyRequestUpdate(<HubProperty.FW_VERSION: 3>)
[11:30:00.910] INFO: received: HubPropertyUpdate(<HubProperty.FW_VERSION: 3>, Version(0x10000004))
>>> HubPropertyRequestUpdate(HubProperty.RADIO_FW_VERSION)
[11:31:21.058] INFO: sending: HubPropertyRequestUpdate(<HubProperty.RADIO_FW_VERSION: 9>)
[11:31:21.198] INFO: received: HubPropertyUpdate(<HubProperty.RADIO_FW_VERSION: 9>, '2.2.1')
>>>

[dlech]

Not sure that this would make any difference, but another thing you could try is clearing the user flash on the remote. Turn the remote off, then press and hold the green button until the light flashes purple. This erases any custom name and "remembered" connections to hubs running official LEGO firmware.

[laurensvalk]

I have had this issue several times (and consistently) at robotics events, and also at a friend's place, but never at home for some reason.

So I'm starting to wonder if there is a link with certain wireless devices being nearby?

This may be a bit of a stretch, but does this still happen for you if you take the hub+remote outside, far away from any other wireless devices?

[davecparker]

I tried again after clearing/resetting the remote, outside away from the house without my phone, and it still failed as before. Works consistently and quickly in the other order.

[laurensvalk]

What happens if you try this program? i.e. does it work now if you turn on the remote after starting the program?

from pybricks.hubs import ThisHub
from pybricks.pupdevices import Remote
from pybricks.parameters import Color
from pybricks.tools import wait

hub = ThisHub()

hub.light.on(Color.YELLOW)

while True:
    try:
        remote = Remote(timeout=2000)
        hub.light.on(Color.GREEN)
        break
    except OSError:
        print("failed, trying again...")
        wait(500)

print("success!")
wait(5000)

This is effectively restarting the scan process, which is partially similar to starting the program after turning it on.

[davecparker]

Got the tool to check my remote firmware, it looks the same as yours:

>>> HubPropertyRequestUpdate(HubProperty.FW_VERSION)
[12:12:02.088] INFO: sending: HubPropertyRequestUpdate(<HubProperty.FW_VERSION: 3>)
[12:12:02.155] INFO: received: HubPropertyUpdate(<HubProperty.FW_VERSION: 3>, Version(0x10000004))
>>> HubPropertyRequestUpdate(HubProperty.RADIO_FW_VERSION)
[12:12:21.188] INFO: sending: HubPropertyRequestUpdate(<HubProperty.RADIO_FW_VERSION: 9>)
[12:12:21.255] INFO: received: HubPropertyUpdate(<HubProperty.RADIO_FW_VERSION: 9>, '2.2.1')
>>>

[davecparker]

Well, get this: Laurens' program above worked for me sometimes, although inconsistent. According to the console prints, it typically got it on the 2nd try, although sometimes never, and sometimes even on the 1st try (!) So I tried the test from @dlech again, and it started working for me (!). So then I went back to my simple program which just tries to connect with default timeout and no exception handling, and it started working too!

Update: Even after clearing the remote again (hold to blinking magenta), and retrying, it still works now!

So, no idea what to think at this point... I'll update with more info if I see a pattern.

[laurensvalk]

Does it keep working if you pair it with your Inventor Hub again, and then try the Technic Hub again?

I don't necessarily see how that would make any difference, but I'm wondering about what triggered and then cleared the bad condition.

The re-try program not working consistently is a known separate (but perhaps related) issue by the way, but I suggested it here as a means for diagnosis (and now I'm wondering if it helped somehow?).

[davecparker]

Well, just as mysteriously, it is back to not working for me again (remote must go first), for no apparent reason. The BT clouds just parted for a while there I guess.

[dlech]

Hi @davecparker. Is this problem still reproducible using the latest firmware builds?

Random idea: does it make a difference if you add a wait(1) or wait(10) before the call to Remote() in the test case?

[davecparker]

Sorry, I didn't see any improvement. I downloaded and installed the custom firmware from your link above (2618) to Technic Hub and tried your test program (which has the try except). It worked once the very first time (!), but I was unable to get another success with many tries, including running from Pybricks, running from the hub, and restarting the hub first, and going outside away from nearby BT interference. Adding wait(10) before remote() did not help. As before, it works consistently if the remote is started first.

BTW, it took me 5 tries to download the firmware to the hub. The first 4 times it paired, erased, then downloaded about 10-20% then said the hub took too long to respond. This leaves you in a state (red-green-blue light cycle) where it appears that you need to open and take a battery out to restart the hub. Also, FYI once this happens you have to restart Pybricks to try again otherwise it won't pair... On the 5th try I got it to work by holding the hub behind my iMac instead of in front (better BT signal?)

[dlech]

Hmm... apparently my reply from a few days ago didn't go through. I think I said something like this...

Thanks for trying again. Since we have ruled out possible interference, I'm really scratching my head as to what could be different about your setup or timing that makes it so I can't reproduce the problem.

Regarding the firmware download issues, we've been getting an uptick in macOS Bluetooth problem reports, so I'm guessing Apple has changed something somewhat recently. Mostly, they seem to be resolved if you turn off other connected Bluetooth devices. If you see the issue again, pleas log the Bluetooth packets (instructions) while you are reproducing the issue and share if possible. Either in a new issue or on #938 if it sounds like the same issue.

[laurensvalk]

I think we have a bit of a breakthrough here, or at least on something that sounds very similar.

Rephrasing @racingbrick:

• Remote does not connect if the hub is started first, in a studio with many Bluetooth devices
• Remote does connect in studio if remote is started first and then quickly the hub, much like @davecparker described.
• Same situation on multiple different hubs and remotes
• It does work both ways, even if hub is started first, inside garage with fewer Bluetooth devices.

And I think we've seen as much in #1096. Paraphrasing that issue: The Technic Hub as a limited list of devices it can see in one scan. In a busy environment, that list may be full by the time you turn on the remote. Since it does work when starting the remote before the scan, the solution might be to restart the scan every 2 or 3 seconds instead of infinitely as we have now.

[laurensvalk]

@racingbrick was able to confirm improvement using a test firmware that implements this fix.

This will be released in beta this week and the pybricks-micropython source released shortly thereafter.

[laurensvalk]

@davecparker when you have time, would you be able to test if it is fixed for you with the firmware from https://beta.pybricks.com/ ? Thanks!

[davecparker]

Test and verified fixed with new beta firmware :) First I re-verified that the problem still persists with the old firmware that I had on my Technic hub (now at my new house with different BT environment), and yes it would still only connect to the remote when the remote is started first. Then I updated to the firmware on beta.pybricks.com, retested, and verified that it can now connect in either order, and with or without Pybricks running. However FYI, when updating the firmware, I again ran into the problem that it bailed out part way through the download with the error “The hub took too long to respond”, which leaves the hub in a state where the LED is cycling [red, green, blue], and cannot be powered off. I had to remove the batteries to reboot it. Worked on the second try.

…

On Feb 26, 2024, at 4:34 AM, laurensvalk ***@***.***> wrote: @davecparker <https://github.com/davecparker> when you have time, would you be able to test if it is fixed for you with the firmware from https://beta.pybricks.com/ ? Thanks! — Reply to this email directly, view it on GitHub <#880 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADRMZOSRKYAQO2WBMYM23PDYVR6PFAVCNFSM6AAAAAATIQOTVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRUGA2DMNZYHA>. You are receiving this because you were mentioned.

[laurensvalk]

Thank you!