Support for SwitchOS 12 about nxbt HOT 51 CLOSED

Thanks for putting in work on this @ggzengel. You're close on the profile-side of things with what we need to do. I've ended up spending the better part of the last few days debugging/testing the new update and I think I've managed to get a preliminary v12 compliant version of NXBT working again.

From my findings, a fair amount has changed since the previous update. Most of the changes are encountered during the initial connection to the Switch and few others pertain to communication frequency changes. I'll list out my findings below:

Connection Changes

• As I mentioned in the original post on this issue, the Switch is far pickier now with which "controllers" it starts sending packets to. With previous emulation techniques, you can lure the Switch into initially pairing, however, it will now disconnect after pairing. I've found it's looking an additional factor to confirm a controllers identity:
  • The device class. The Switch used to ignore checking this value, however, this isn't the case any longer.
• Even with the above values set, I've observed that the Switch can occasionally fall into a "connect/disconnect loop" Bluetooth-wise and never officially start the connection process. The surprising part is that I've had this happen with official controllers. The remedy is fairly easy for this: Navigate to Settings -> Controllers and Sensors -> Disconnect Controllers. Restart your Switch after this. You should be able to connect.
• Reconnection works the same, so once you establish the initial connection to the Switch, it's smooth sailing connection-wise. Communication-wise, however, is another story. See the next section for more details.

Communication Changes

• The Switch now sends blank packets as a reply when the controller is prompting for input. The frequency at this stage is around 1Hz. Attempting to increase the frequency at this stage will result in the Switch abruptly disconnecting.
• After sending a few blank packets, the Switch will send the "Device Inquiry" packet (as usual). Once you've received this packet, you can crank up the frequency to 15Hz. Again, increasing any further will result in abrupt disconnection.
• The big change is that the 15Hz frequency now MUST be maintained on the main menu and all other submenus. Previously, you could jump to 120Hz once off of the "Change Grip/Order" menu. More testing is needed to see how/where the 120Hz frequency is used (likely inside of games only now).

Changes to NXBT

The following changes apply to the v12_fix branch on the repo:

• The hciconfig CLI is now used to change the class and reset the bluetooth devices
• NXBT's frequency is capped at 15Hz until the mechanism for frequency switching is determined

Ideally, I would like to eliminate the use of further CLIs within NXBT, so if anyone has any ideas on replicating the functionality/use-cases of hciconfig/hcitool/sdptool within NXBT, let me know!

If anyone's willing to help test/debug things, you can try out the SwitchOS v12 compliant version of NXBT by cloning/installing the v12_fix branch or with the following command(s):

Updated September 7 5:55 PM PST

# If you have a previous version of NXBT
sudo pip3 uninstall nxbt
# Install the v12 compliant version with the following
sudo pip3 install git+http://github.com/Brikwerk/nxbt.git@b48b030b5e8c92666ed446be5c01a8ee2ec93c6f

Thanks again for everyone's interest in this project!

from nxbt.

Hi all,

Apologies for the lack of updates with this project. Some real-world commitments have been consuming my free time lately.

Anyways, I have found some time recently to take another stab at correcting issues with SwitchOS v12 and NXBT. The good news is that I believe I've corrected the disconnection issues happening when users initially connect a controller on the "Change Grip/Order" menu.

The new commits pushed to the v12_fix branch include the following changes

• Optimized communication with the Switch
  • Fixes disconnects from the "Change Grip/Order" menu and slightly improves input accuracy.
• Better TUI error handling and a new remote-specific TUI
  • A new remote_tui option has been added to the CLI which explicitly enables use of NXBT's TUI over remote shells (SSH, Mosh, etc). This helps in situations where NXBT can't detect if a shell is a remote one or not.
  • Using the regular TUI CLI option while on a remote shell that isn't detected as remote will result in a clearer and immediate message.
• A more respectful and cleaner BlueZ toggle (thanks @Yamakaky)

The new communication process NXBT employs (while talking to the Switch) is effectively a redundancy optimization procedure. Every packet constructed in the mainloop is only sent if the previous packet (excluding the timing byte) doesn't exactly match. This (1) eliminates the situation whereby the Switch would kick a controller off after receiving packets at full frequency and (2) seems to slightly increase input accuracy due to decreased computational burden.

If you're interested in giving this new version a spin, please follow the installation instructions below. This version was tested on a Raspberry Pi 4b (4GB) with Raspbian and a Switch with SwitchOS v12.1.0. It would be great to hear if this does fix the disconnection issue for others.

# If you have a previous version of NXBT
sudo pip3 uninstall nxbt
# Install the v12 compliant version with the following
sudo pip3 install git+http://github.com/Brikwerk/nxbt.git@b48b030b5e8c92666ed446be5c01a8ee2ec93c6f

Edit: I've successfully tested the current branch on a Pinebook Pro. If you're encountering difficulties connecting (eg: you're stuck at the "Connecting" stage), please make sure that you've deleted any previous pairings with your Switch.

from nxbt.

@riking Excellent point. I double checked and the emulated controller is still being sent the x30 command. The original jump to 60/120Hz in the emulation server (before the v12 update) didn't happen until a few commands after this.

I ran a quick test where I reconnected within a game where the full refresh should be allowed, however, I'm still seeing disconnections above anything over 18Hz. I wonder if this is something to do with packet timing (eg the timing byte, time received, time between, etc) rather than a speed limit? I would still (ideally) like to run the frequency test to see what the authentic controllers are doing since I have a hunch they may still be functioning at the full frequency on the menus.

Another thought: maybe the transition to 60/120Hz must happen immediately after the x30 command is sent now? If the frequency transition doesn't happen immediately afterwards, maybe this disallows future frequency increases?

@donelwero @S1monuwu From reading over the debug log, it looks like you're using an old version of NXBT. I'm not seeing the class getting set to the gamepad class (0x2508) and the DEBUG in bluez should appear twice now due to the SDP record cleansing. If you're looking to test the v12 compliant version, you'll need to completely remove the pypi version of NXBT and reinstall from the repository's v12_fix branch. I reference the instructions you need to perform in this post, however, this is a development version and is not ready for general use.

from nxbt.

Yes, v12 branch of NXBT worked fine for me on 12.0.1. (though note that I only did a brief test so far, so maybe wait till I do longer tests, if you're worried)

from nxbt.

@dtrunk90 What the device officially identifies as is specified in the device inquiry packet reply. Your Android could have an alias of "Pro Controller" but show up as a Joy-Con with the right inquiry reply.

Edit: Check out the example pairing session here for more info.

from nxbt.

Hello there. I just discovered this amazing tool, however I am already in Nintendo Switch version 12.0.3 and I am unable to get nxbt conected.
I am using Raspberry Pi 4 B and tried nxbt v12 fix, the nxbt v0.1.3 and the nxbt v0.1.4 without success. Thanks for all you work I am looking forward next updates on this topic.

from nxbt.

Hey hello Brikwerk, nice to hear from you again!!

I have tried what you said with different setups and this is what i got:

Using Raspberry Pi 4b (8GB) with Pi OS Lite (32bit) + Nintendo Switch 12.1.0:
Running demo: it does nothing. No connect at all.
Running webapp: it shows connecting and then crashed

Using Raspberry Pi 4b (8GB) with Pi OS Desktop (32bit) + Nintendo Switch 12.1.0:
Running demo: makes Nintendo Swtich shows a new controller Synchronized but immediately demo crashes in terminal, showing error message (attached images).
if i run demo again, it does nothing, just shows Running demo. I need to go to bluetoothctl, remove paired Nintendo Switch. Then running again demo and it repeats the same thing (Nintendo Switch shows Sinchronized and immediately error)

Thanks again for your contribution!!

from nxbt.

I tried with already known mac address but it didn't work.
I used this script:

#hcitool cmd 0x3f 0x001 0xYY 0xYY 0xYY 0xE7 0xA5 0x48 #reverse order
hcitool cmd 0x3f 0x001 0xYY 0xYY 0xYY 0xe9 0xb6 0x98 #reverse order
hciconfig hci0 reset
service bluetooth restart
bluetoothctl show

I stripped bluetoothd with

ExecStart=/usr/lib/bluetooth/bluetoothd --noplugin=*

and uninstalled some packages:

Purge: lxplug-bluetooth:armhf (0.21), lxplug-volumepulse:armhf (0.5)
Purge: pulseaudio-module-bluetooth:armhf (12.2-4+deb10u1+rpi3)

but I still have 3 UUIDs left:

# bluetoothctl show
Controller 98:B6:E9:YY:YY:YY (public)
        Name: BlueZ 5.50
        Alias: Pro Controller
        Class: 0x00000000
        Powered: no
        Discoverable: no
        Pairable: yes
        UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
        UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
        UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
        Modalias: usb:v1D6Bp0246d0532
        Discovering: no

I think we should have no default UUIDs like a common controller:

[bluetooth]# info 98:B6:E9:YY:YY:YY
Device 98:B6:E9:YY:YY:YY (public)
        Name: Pro Controller
        Alias: Pro Controller
        Class: 0x00002508
        Icon: input-gaming
        Paired: yes
        Trusted: no
        Blocked: no
        Connected: no
        LegacyPairing: no
        UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)
        Modalias: usb:v057Ep2009d0001
        RSSI: -73

from nxbt.

Here is a debug log:

# bluetoothctl
Agent registered
Agent unregistered
[DEL] Device D0:55:09:YY:YY:YY Nintendo Switch
[DEL] Controller 98:B6:E9:YY:YY:YY Pro Controller [default]
Agent registered
[CHG] Controller 98:B6:E9:YY:YY:YY Class: 0x00000508
[CHG] Controller 98:B6:E9:YY:YY:YY Powered: yes
[CHG] Controller 98:B6:E9:YY:YY:YY PairableTimeout: 0x00000000
[CHG] Controller 98:B6:E9:YY:YY:YY DiscoverableTimeout: 0x000000b4
[CHG] Controller 98:B6:E9:YY:YY:YY UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[CHG] Controller 98:B6:E9:YY:YY:YY UUIDs: 00001124-0000-1000-8000-00805f9b34fb
[CHG] Controller 98:B6:E9:YY:YY:YY UUIDs: 00001200-0000-1000-8000-00805f9b34fb
[CHG] Controller 98:B6:E9:YY:YY:YY UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Controller 98:B6:E9:YY:YY:YY Discoverable: yes
[CHG] Device D0:55:09:YY:YY:YY Connected: yes
[CHG] Device D0:55:09:YY:YY:YY Connected: no

from nxbt.

bdaddr won't work with rpi4:
https://community.cypress.com/t5/Wi-Fi-Bluetooth-for-Linux/How-to-change-Bluetooth-MAC-address-on-Raspberry-Pi-4/m-p/179476

from nxbt.

@ggzengel @Brikwerk Wow, this was amazing level of debugging by both of you!!!!

from nxbt.

@ggzengel Thanks for pointing that out. I've swapped in use of hcitool with the latest commit on the v12_fix branch. Funny enough, I was actually using bdaddr with an RPi4. I must have been using a patched version. Anyways, I think hcitool is the better bet going forward since it seems more hardware agnostic.

@dentedghost Thanks ;)

I'll try to run some frequency tests soon to check what the relative "speed limits" are on the Switch now. I'm thinking that the /scripts/proxy.py file can be used to calculate an authentic controller's frequency on the fly (a running average might be needed). You could navigate around with the controller and see how/when the frequency changes.

from nxbt.

For the speed limit, you probably need to wait for one of the x30/x31/x32/x33 commands which switch the official controllers into high frequency (60Hz) push.

Additionally, since the limit is 120, you should be scheduling at significantly below that as a safety margin.

from nxbt.

This is my first time trying to be helpful in any project, so I don't really know if this is useful or not, hope it is, if it's not I will gladly delete the post.
I'm using a VM, luckily I bought a BT usb dongle a week ago, so I thought I could just give it a try.

I tried running the demo using sudo nxbt demo -d
There wasn't anything much of a log, except for this line:
[2021-04-11 17:43:48,587] DEBUG in bluez: Using adapter under object path: /org/bluez/hci0

It doesn't do or print anything else.

I did run bluetoothctl on the background and got this:
(Didn't know if I should delete anything, so I'm pasting all of it)

[CHG] Controller 00:1A:7D:DA:71:15 Name: ubuntu
[CHG] Controller 00:1A:7D:DA:71:15 Powered: yes
[CHG] Controller 00:1A:7D:DA:71:15 Powered: no
[CHG] Controller 00:1A:7D:DA:71:15 Discovering: no
Agent unregistered
[DEL] Controller 00:1A:7D:DA:71:15 Pro Controller [default]
Agent registered
[CHG] Controller 00:1A:7D:DA:71:15 Name: ubuntu
[CHG] Controller 00:1A:7D:DA:71:15 Powered: yes
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001133-0000-1000-8000-00805f9b34fb
...[Non-essential output truncated]
[CHG] Controller 00:1A:7D:DA:71:15 Class: 0x003c0000
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001133-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 0000110e-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001105-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001132-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001200-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001104-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00005005-0000-1000-8000-0002ee000001
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001112-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 0000110c-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 0000112f-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 0000110b-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 0000180a-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001108-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 0000110a-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001106-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 PairableTimeout: 0x00000000
[CHG] Controller 00:1A:7D:DA:71:15 DiscoverableTimeout: 0x000000b4
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001133-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 0000110e-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001105-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001132-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001200-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001104-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00005005-0000-1000-8000-0002ee000001
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001112-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 0000110c-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 0000112f-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 0000110b-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 0000180a-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001108-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 0000110a-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001106-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001124-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 Discoverable: yes
[NEW] Device 98:B6:E9:6C:D2:34 Nintendo Switch
[CHG] Device 98:B6:E9:6C:D2:34 UUIDs: 0000110a-0000-1000-8000-00805f9b34fb
[CHG] Device 98:B6:E9:6C:D2:34 UUIDs: 0000110c-0000-1000-8000-00805f9b34fb
[CHG] Device 98:B6:E9:6C:D2:34 UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Device 98:B6:E9:6C:D2:34 UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[CHG] Device 98:B6:E9:6C:D2:34 ServicesResolved: yes
[CHG] Device 98:B6:E9:6C:D2:34 Paired: yes
[CHG] Device 98:B6:E9:6C:D2:34 Trusted: yes
[CHG] Device 98:B6:E9:6C:D2:34 UUIDs: 0000110a-0000-1000-8000-00805f9b34fb
[CHG] Device 98:B6:E9:6C:D2:34 UUIDs: 0000110c-0000-1000-8000-00805f9b34fb
[CHG] Device 98:B6:E9:6C:D2:34 UUIDs: 0000110d-0000-1000-8000-00805f9b34fb
[CHG] Device 98:B6:E9:6C:D2:34 UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Device 98:B6:E9:6C:D2:34 UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[Nintendo Switch]# 

I had to turn off and on Bluetooth in order to pair.

On the Switch nothing happened. Never got the controller to appear on the Change Grip/Order screen. So I Ctrl + C the demo and tried using nxbt tui while it was still paired.

Using sudo nxbt tui -d afterwards, then I got the following repeating over and over.

Connected : yes
Connected : no
Connected : yes
Connected : no  

from nxbt.

This is my first time trying to be helpful in any project, so I don't really know if this is useful or not, hope it is, if it's not I will gladly delete the post.
I'm using a VM, luckily I bought a BT usb dongle a week ago, so I thought I could just give it a try.

I tried running the demo using sudo nxbt demo -d
There wasn't anything much of a log, except for this line:
[2021-04-11 17:43:48,587] DEBUG in bluez: Using adapter under object path: /org/bluez/hci0

It doesn't do or print anything else.

I did run bluetoothctl on the background and got this:
(Didn't know if I should delete anything, so I'm pasting all of it)

[CHG] Controller 00:1A:7D:DA:71:15 Name: ubuntu
[CHG] Controller 00:1A:7D:DA:71:15 Powered: yes
[CHG] Controller 00:1A:7D:DA:71:15 Powered: no
[CHG] Controller 00:1A:7D:DA:71:15 Discovering: no
Agent unregistered
[DEL] Controller 00:1A:7D:DA:71:15 Pro Controller [default]
Agent registered
[CHG] Controller 00:1A:7D:DA:71:15 Name: ubuntu
[CHG] Controller 00:1A:7D:DA:71:15 Powered: yes
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001133-0000-1000-8000-00805f9b34fb
...[Non-essential output truncated]
[CHG] Controller 00:1A:7D:DA:71:15 Class: 0x003c0000
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001133-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 0000110e-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001105-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001132-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001200-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001104-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00005005-0000-1000-8000-0002ee000001
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001112-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 0000110c-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 0000112f-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 0000110b-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 0000180a-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001108-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 0000110a-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001106-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 PairableTimeout: 0x00000000
[CHG] Controller 00:1A:7D:DA:71:15 DiscoverableTimeout: 0x000000b4
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001133-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 0000110e-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001105-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001132-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001200-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001104-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00005005-0000-1000-8000-0002ee000001
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001112-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 0000110c-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 0000112f-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 0000110b-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 0000180a-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001108-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 0000110a-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001106-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 UUIDs: 00001124-0000-1000-8000-00805f9b34fb
[CHG] Controller 00:1A:7D:DA:71:15 Discoverable: yes
[NEW] Device 98:B6:E9:6C:D2:34 Nintendo Switch
[CHG] Device 98:B6:E9:6C:D2:34 UUIDs: 0000110a-0000-1000-8000-00805f9b34fb
[CHG] Device 98:B6:E9:6C:D2:34 UUIDs: 0000110c-0000-1000-8000-00805f9b34fb
[CHG] Device 98:B6:E9:6C:D2:34 UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Device 98:B6:E9:6C:D2:34 UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[CHG] Device 98:B6:E9:6C:D2:34 ServicesResolved: yes
[CHG] Device 98:B6:E9:6C:D2:34 Paired: yes
[CHG] Device 98:B6:E9:6C:D2:34 Trusted: yes
[CHG] Device 98:B6:E9:6C:D2:34 UUIDs: 0000110a-0000-1000-8000-00805f9b34fb
[CHG] Device 98:B6:E9:6C:D2:34 UUIDs: 0000110c-0000-1000-8000-00805f9b34fb
[CHG] Device 98:B6:E9:6C:D2:34 UUIDs: 0000110d-0000-1000-8000-00805f9b34fb
[CHG] Device 98:B6:E9:6C:D2:34 UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Device 98:B6:E9:6C:D2:34 UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[Nintendo Switch]# 

I had to turn off and on Bluetooth in order to pair.

On the Switch nothing happened. Never got the controller to appear on the Change Grip/Order screen. So I Ctrl + C the demo and tried using nxbt tui while it was still paired.

Using sudo nxbt tui -d afterwards, then I got the following repeating over and over.

Connected : yes
Connected : no
Connected : yes
Connected : no  

this is happening for me too

from nxbt.

I am using joycontrol on Linux + python to send bluetooth commands to auto play some nintendo games. My question: me switching to NXBT, can I call connect/reconnect, press and keep button pressed, release button etc from within my python script ? Something similar to JoyControl ?

from nxbt.

I am using joycontrol on Linux + python to send bluetooth commands to auto play some nintendo games. My question: me switching to NXBT, can I call connect/reconnect, press and keep button pressed, release button etc from within my python script ? Something similar to JoyControl ?

You should be able to do similar things, but from what I understood it doesn't looked like NXBT works with 12.0.0 either

from nxbt.

VirtualBox:~$ sudo pip3 install git+http://github.com/Brikwerk/nxbt.git@abb966d438be79678b1b23579b06517995246618
Collecting git+http://github.com/Brikwerk/nxbt.git@abb966d438be79678b1b23579b06517995246618
  Cloning http://github.com/Brikwerk/nxbt.git (to revision abb966d438be79678b1b23579b06517995246618) to /tmp/pip-req-build-1n2uxq33
  Running command git clone -q http://github.com/Brikwerk/nxbt.git /tmp/pip-req-build-1n2uxq33
  Running command git checkout -q abb966d438be79678b1b23579b06517995246618
Collecting Flask-SocketIO==5.0.1
  Downloading Flask_SocketIO-5.0.1-py2.py3-none-any.whl (16 kB)
Collecting Flask==1.1.2
  Downloading Flask-1.1.2-py2.py3-none-any.whl (94 kB)
     |████████████████████████████████| 94 kB 3.2 MB/s 
Collecting blessed==1.17.10
  Downloading blessed-1.17.10-py2.py3-none-any.whl (76 kB)
     |████████████████████████████████| 76 kB 7.4 MB/s 
Requirement already satisfied: dbus-python==1.2.16 in /usr/lib/python3/dist-packages (from nxbt==0.1.4) (1.2.16)
Collecting eventlet==0.27.0
  Downloading eventlet-0.27.0-py2.py3-none-any.whl (223 kB)
     |████████████████████████████████| 223 kB 11.5 MB/s 
Collecting psutil==5.6.6
  Downloading psutil-5.6.6.tar.gz (447 kB)
     |████████████████████████████████| 447 kB 10.7 MB/s 
Requirement already satisfied: pynput==1.7.1 in /usr/local/lib/python3.8/dist-packages (from nxbt==0.1.4) (1.7.1)
Collecting python-socketio>=5.0.2
  Downloading python_socketio-5.1.0-py2.py3-none-any.whl (53 kB)
     |████████████████████████████████| 53 kB 3.3 MB/s 
Collecting Werkzeug>=0.15
  Downloading Werkzeug-1.0.1-py2.py3-none-any.whl (298 kB)
     |████████████████████████████████| 298 kB 10.7 MB/s 
Requirement already satisfied: click>=5.1 in /usr/lib/python3/dist-packages (from Flask==1.1.2->nxbt==0.1.4) (7.0)
Collecting itsdangerous>=0.24
  Downloading itsdangerous-1.1.0-py2.py3-none-any.whl (16 kB)
Collecting Jinja2>=2.10.1
  Downloading Jinja2-2.11.3-py2.py3-none-any.whl (125 kB)
     |████████████████████████████████| 125 kB 10.8 MB/s 
Collecting wcwidth>=0.1.4
  Downloading wcwidth-0.2.5-py2.py3-none-any.whl (30 kB)
Requirement already satisfied: six>=1.9.0 in /usr/lib/python3/dist-packages (from blessed==1.17.10->nxbt==0.1.4) (1.14.0)
Collecting monotonic>=1.4
  Downloading monotonic-1.6-py2.py3-none-any.whl (8.2 kB)
Collecting dnspython<2.0.0,>=1.15.0
  Downloading dnspython-1.16.0-py2.py3-none-any.whl (188 kB)
     |████████████████████████████████| 188 kB 10.7 MB/s 
Collecting greenlet>=0.3
  Downloading greenlet-1.0.0-cp38-cp38-manylinux2010_x86_64.whl (165 kB)
     |████████████████████████████████| 165 kB 10.5 MB/s 
Requirement already satisfied: python-xlib>=0.17; "linux" in sys_platform in /usr/local/lib/python3.8/dist-packages (from pynput==1.7.1->nxbt==0.1.4) (0.28)
Requirement already satisfied: evdev>=1.3; "linux" in sys_platform in /usr/local/lib/python3.8/dist-packages (from pynput==1.7.1->nxbt==0.1.4) (1.3.0)
Collecting bidict>=0.21.0
  Downloading bidict-0.21.2-py2.py3-none-any.whl (37 kB)
Collecting python-engineio>=4
  Downloading python_engineio-4.1.0-py2.py3-none-any.whl (51 kB)
     |████████████████████████████████| 51 kB 308 kB/s 
Collecting MarkupSafe>=0.23
  Downloading MarkupSafe-1.1.1-cp38-cp38-manylinux2010_x86_64.whl (32 kB)
Building wheels for collected packages: nxbt, psutil
  Building wheel for nxbt (setup.py) ... done
  Created wheel for nxbt: filename=nxbt-0.1.4-py3-none-any.whl size=99467 sha256=1ca85a186aefce0dd60ab3038daef09007a13a77b92d3336d1399e0378ec84a1
  Stored in directory: /root/.cache/pip/wheels/c9/78/51/42384641fb65996e3c48597de1be62235eb290fdaf6453650a
  Building wheel for psutil (setup.py) ... done
  Created wheel for psutil: filename=psutil-5.6.6-cp38-cp38-linux_x86_64.whl size=286293 sha256=800aad0f8e0a12e5b869ad76602ff7b5232e06aaeac9c3b53c35084c416dbbd6
  Stored in directory: /root/.cache/pip/wheels/79/67/93/91114b71e0965edb6233d607d82bb5de75ad02e3d9d469ba17
Successfully built nxbt psutil
Installing collected packages: bidict, python-engineio, python-socketio, Werkzeug, itsdangerous, MarkupSafe, Jinja2, Flask, Flask-SocketIO, wcwidth, blessed, monotonic, dnspython, greenlet, eventlet, psutil, nxbt
  Attempting uninstall: psutil
    Found existing installation: psutil 5.5.1
    Not uninstalling psutil at /usr/lib/python3/dist-packages, outside environment /usr
    Can't uninstall 'psutil'. No files were found to uninstall.
Successfully installed Flask-1.1.2 Flask-SocketIO-5.0.1 Jinja2-2.11.3 MarkupSafe-1.1.1 Werkzeug-1.0.1 bidict-0.21.2 blessed-1.17.10 dnspython-1.16.0 eventlet-0.27.0 greenlet-1.0.0 itsdangerous-1.1.0 monotonic-1.6 nxbt-0.1.4 psutil-5.6.6 python-engineio-4.1.0 python-socketio-5.1.0 wcwidth-0.2.5

After installing.. I ran the demo and its stuck

sudo nxbt demo -d
[2021-04-15 10:50:30,540] DEBUG in bluez: Using adapter under object path: /org/bluez/hci0
[2021-04-15 10:50:31,449] DEBUG in bluez: Using adapter under object path: /org/bluez/hci0

from nxbt.

Been running the V12 Fix Branch for the past 48 hours on Raspberry Pi 4b 4gb, with Ubuntu 20.04.2 LTS with pi-bluetooth/bluez and am able to run Demo and Webapp with Switch running v12 firmware.

Initial connection can take a while after 'create controller' function is initiated from webapp. Sometimes network adapter get's hung up but rebooting the pi seems to resolve any locks. For the most part the V12 fix appears to be working.

from nxbt.

@Willsie-Digital could you be a little more specific? Where are the network adapter hangups, and are you on the switch change grip menu or somewhere else? Can you run macros?

from nxbt.

Thank you !
I used the tips found here to POC joycontrol with a 12.0.0 switch.

I posted my findings here : Poohl/joycontrol#3 (comment)
Luckily, joycontrol emulation seems to be stable even knowing the changes in command frequencies.

My main interest is in getting amiibos writing back to work to play Zelda ;) And there seems to be changes on the way it works too.

from nxbt.

Just to add to the knowledge base: I was able to get nxbt working (the v12 fix branch linked in this post) in an Xubuntu virtual machine on Windows (set up according to the VM portion of the instructions here), on firmware v12.0.0, with the ZEXMTE Bluetooth dongle.

I've put together a complete set of instructions here: https://github.com/Venryx/switch-resources/blob/master/NXBT.md

However, the "Pro Controller" that nxbt creates for the Switch, has some connection limitations:

1. The connection success rate is ~50%: you may need to try a couple times before it connects (and stays connected after closing) on the "Change Grip/Order" page.
2. The fake-controller refuses to stay connected if both of my physical joycons are also connected.

If I only connect one joycon alongside the fake-controller, the connection is stable. (at least as far as I tested; I played a full match of Smash Bros Ultimate, and did multiple shorter tests after that, each without issue)

If I connect two joycons, the fake-controller disconnects as soon as I leave the change-grip-order page.

Any ideas on why the fake-controller would be stable with only one joycon connected, but unstable with two connected?

Some additional notes:

• After starting nxbt (eg. sudo nxbt tui), the process would just sit there not doing anything in most cases. To fix this, I usually have to press the Bluetooth dropdown, then press "Set up new device" (and then cancel) or "Make discoverable"; this appears to "kickstart" the bluetooth pairing process, prompting the Pair popup to show up after a couple of seconds. (this was very repeatable, ie. not just a fluke)
• Connection appears to persist more reliably if you wait a few (~8) seconds after connecting your controllers, before closing the change-grip-order page. (EDIT: I think this may have been a fluke.)
• Once I hit an issue where the connecting just failed to show the Pair popup in Xubuntu, even after the trick/fix above. Shutting down and restarting the VM fixed it. (this only happened once)
• NXBT stopped working when I changed the Bluetooth dongle's persistent mac address to start with Nintendo's "94:58:CB"! I used the command: sudo ./bdaddr -i hci0 -r 94:58:CB:DA:71:13 (after installing bdaddr, as seen here). Anyone know why this could be?
• I was able to get NXBT working again by: 1) changing the mac address back to what it was, 2) undoing the probably-irrelevant file changes described here, which I had applied after NXBT broke (for the purpose of trying to get the joycontrol v12 branch working -- which failed for me btw, never showing the Pair popup), 3) fully shutting down and restarting the VM.

from nxbt.

I had modest success using the v12 branch on a raspberry pi with Raspbian and later Ubuntu 20.10.
I have the best success after freshly powering the PI on and using "disconnect all controllers" via switch settings.
I have yet to get a connection to persist outside the "change grip/order" screen. Initially because I left joycons connected, and later because nxbt tui would get confused about my DISPLAY variable once connection was established (which still baffles me) and error out. I worked around that by SSH'ing into local host (shrug). Will see if I get a solid connection today.

from nxbt.

Was the v12 branch tested with firmware version 12.0.1 already? I tested with 12.0.0 and it worked but someone reported that it's not working with 12.0.1.

from nxbt.

I have it running with v12 branch on 12.0.0. Not brave enough to try 12.0.1 yet.

from nxbt.

Confirmed, it works for me on 12.0.1 as well.

from nxbt.

I did a longer test (about an hour and a half, playing Smash Bros Ultimate), and had no disconnects. For NXBT users, 12.0.1 appears safe to update to.

(I don't know about JoyCon Droid, joycontrol, etc., as I'm not using those. I know that at least one JoyCon Droid user said it broke the real-left-joycon, fake-right-joycon approach that they'd been using fine on v12.0.0; I'm guessing this is an Android-specific issue though, not applying to NXBT and joycontrol.)

from nxbt.

By the way, I received my second set of joycons today.

My old setup: 1 NXBT simulated controller + 1 real right-joycon + 1 Magic-NS Xbox controller.

What I tested today: 1 NXBT simulated controller + 2 real right-joycons + 1 Magic-NS Xbox controller.

Unfortunately, the new setup I tested did not work; it appears that using 2 real joycons alongside the NXBT simulated controller will always disconnect the simulated controller, even if they are both of the same "side" (I also tried two lefts, with the same result).

However, since adding the 1 Magic-NS Xbox controller worked "in addition to" the simulated controller and real joycon, I have purchased a second Magic-NS to see if I can connect 2 Xbox controllers alongside the simulated controller and joycon. It should arrive in a few days, at which point I'll make an update here on whether that lets me get to four local players. (I'm guessing it will work, but we'll see.)

Also, I realized something: If you're using other controllers alongside the simulated controller, it's more reliable to connect only the simulated controller on the change-grip-order panel, and connect the rest afterward when you're already in the target game [they need to have previously been paired once, of course]. This is because including other controllers on the change-grip-order panel, makes the simulated controller have a lower chance of "sticking" when you leave that panel. However, once you leave those panels and enter a game, it stays connected stably. (the one thing that will disconnect the simulated controller, even in game, is connecting more than 1 real joycon)

from nxbt.

I ran NS 12.0.1 and try to play Rocket League, i am very good in this game.
I dont tested it with 12.0.0.
The input Latency is bigger, 150-300ms added?
I using a USB Bluetooth Stick.
Disconnect on pairing? But connects after pairing attempt.

from nxbt.

@Brikwerk i see some unnecessary changes in your v12fix. it is enough to change the device class. you don't need to remove sdp records or changing the mac address. i tested it on my android phone with a patched libbluetooth.so with switch fw 12.0.0 (need to test it with fw 12.0.1 though).

EDIT: Can you tell me how you got the device class for the pro controller? i need the device classes for joycon left/right too and running hcitool inq crashes my whole bluetooth on my machine because of those weird device classes.

from nxbt.

@dtrunk90 Thanks for double checking that. It does seem to be the case from some preliminary testing on my end as well. I think the device class was the last thing I fixed/changed and didn't catch that in my A/B testing due to the occasional weird connection refusals the Switch would sometimes fall into. I pushed these changes into a new patch on the branch.

I do my debugging from a Mac using the Bluetooth explorer utility. It lists all stats (including device class) through a device inquiry service it provides. Joy-Cons have the same device class as the Pro Controller (0x2508) from a quick check.

From my testing, the 12.0.1 update seems to improve the stability of the Bluetooth on the Switch. I don't seem to be encountering the random refusal to connect that seemed characteristic of the 12.0.0 update.

For those noting disconnections after the Change Grip/Order Menu, please keep in mind that this is an acknowledged bug that I'm still working on. NXBT operates at a 15Hz frequency at the moment to mitigate this issue, however, this is more of a temporary fix. I'm finding that a lower frequency when exiting the Change Grip/Order menu seems to translate to lower disconnect rates.

As an additional update on my part, I've found some success in restoring the original 60Hz frequency when reconnecting and exiting the Change Grip/Order menu, however, this still needs some research/work. It seems that by throwing out an occasional "slow" packet (eg: at 15Hz or lower) the Switch doesn't mind accepting a bunch of "fast" packets (60Hz or higher even).

from nxbt.

@Brikwerk Thanks for the device class information but I guess it's a different device class because my android device is always recognized as a pro controller as I can see the pro controller symbol when paired instead of a joycon symbol.

from nxbt.

Another quick update for those unable to connect with an adapter that worked in the past:

If you previously had paired/used either Joycontrol or NXBT on a version prior to SwitchOS v12, you should delete the Bluetooth pairing with the Switch before trying to emulate a controller. This can be done through the respective Bluetooth GUI provided by your distro or through the bluetoothctl CLI (use the remove command with the Bluetooth MAC address of your Switch).

I had the chance to run through testing use of only setting the device class on a few different adapters I have. Some adapters that had paired previously with the Switch (and retained the link keys) fell into the connect/disconnect loop. After deleting the pairing profile, they happily connected to the Switch.

from nxbt.

Thanks for the info @Brikwerk!

On my side, I received my second Magic-NS adapter today, and tried connecting a second Xbox controller (alongside the NXBT simulated controller, the existing Magic-NS/Xbox controller, and the 1 joycon); it worked!

I can now use NXBT alongside three physical controllers, which is really nice.

It looks like you could also just keep adding more Magic-NS adapters, as the USB-based controllers don't seem to "count toward the limit" of the issue hit with bluetooth-based simulated controllers. Since the Switch has three USB ports, this gives a maximum of five players (1 NXBT, 1 joycon, and 3 Magic-NS/Xbox/PS/etc. controllers). [it's possible you could add even more actually, if USB splitters/hubs work for the Switch)

Of course, it's ideal if a way is found to have the NXBT simulated controller not disconnect when more than 1 joycon is connected; but in the meantime, using Magic-NS adapters to fill the gap works fine.

from nxbt.

Hey,
it's a very cool project :)

So let me share my experiences with you. While i was testing nxbt and playing around i noticed the following things:

• first of all: before connecting my rpi 3B I need to remove the nintendo switch from bluetooth device list
• then I need to connect the nxbt controller as well as my VINSIC Pro Wireless Switch Controller to let the contoller be connected
• then the nxbt controller is working fine except for a couple games (e.g. opening settings, nintendo E-Shop or playing Asphalt 9 ist working fine while all Pokemon games let the controller disconnect as soon as I start or open the game)

Hope that information is helpful

from nxbt.

Hi!
MY RPi Zero WH cannot connect to switch even use v12fix...

bluetoothctl says as follows.

Agent registered
[CHG] Controller B8:27:EB:XX:XX:XX Powered: no
[CHG] Controller B8:27:EB:XX:XX:XX Discovering: no
[CHG] Controller B8:27:EB:XX:XX:XX Class: 0x00000000
Agent unregistered
[DEL] Device 94:58:CB:YY:YY:YY Nintendo Switch
[DEL] Controller B8:27:EB:XX:XX:XX Pro Controller [default]
Agent registered
[CHG] Controller B8:27:EB:XX:XX:XX UUIDs: 00001112-0000-1000-8000-00805f9b34fb
[CHG] Controller B8:27:EB:XX:XX:XX UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[CHG] Controller B8:27:EB:XX:XX:XX UUIDs: 00001200-0000-1000-8000-00805f9b34fb
[CHG] Controller B8:27:EB:XX:XX:XX UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Controller B8:27:EB:XX:XX:XX UUIDs: 00001112-0000-1000-8000-00805f9b34fb
[CHG] Controller B8:27:EB:XX:XX:XX UUIDs: 00001108-0000-1000-8000-00805f9b34fb
[CHG] Controller B8:27:EB:XX:XX:XX UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[CHG] Controller B8:27:EB:XX:XX:XX UUIDs: 00001200-0000-1000-8000-00805f9b34fb
[CHG] Controller B8:27:EB:XX:XX:XX UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Controller B8:27:EB:XX:XX:XX Class: 0x00000508
[CHG] Controller B8:27:EB:XX:XX:XX Powered: yes
[CHG] Controller B8:27:EB:XX:XX:XX PairableTimeout: 0x00000000
[CHG] Controller B8:27:EB:XX:XX:XX DiscoverableTimeout: 0x000000b4
[CHG] Controller B8:27:EB:XX:XX:XX UUIDs: 00001112-0000-1000-8000-00805f9b34fb
[CHG] Controller B8:27:EB:XX:XX:XX UUIDs: 00001108-0000-1000-8000-00805f9b34fb
[CHG] Controller B8:27:EB:XX:XX:XX UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[CHG] Controller B8:27:EB:XX:XX:XX UUIDs: 00001124-0000-1000-8000-00805f9b34fb
[CHG] Controller B8:27:EB:XX:XX:XX UUIDs: 00001200-0000-1000-8000-00805f9b34fb
[CHG] Controller B8:27:EB:XX:XX:XX UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Controller B8:27:EB:XX:XX:XX Discoverable: yes
[CHG] Controller B8:27:EB:XX:XX:XX Class: 0x00002508
[CHG] Device 94:58:CB:YY:YY:YY Connected: yes
[CHG] Device 94:58:CB:YY:YY:YY Connected: no
[CHG] Device 94:58:CB:YY:YY:YY Connected: yes
[CHG] Device 94:58:CB:YY:YY:YY Connected: no

Do you have any information for fix it?

OS : Raspian Linux raspberrypi 5.10.11+ #1399 Thu Jan 28 12:02:28 GMT 2021 armv6l GNU/Linux

from nxbt.

@device-high to get the best conditions :

• unpair the console : bluetoothctl remove 94:58:CB:YY:YY:YY
• on the Switch, goto to Settings->Controllers->Forget all controllers
• resync the joycons then remove them both and power them off
• start sudo ./run-controller-cli.py PRO_CONTROLLER
• using touchscreen goto to Controllers/Change Order
• wait for connection from the Switch !

If it still doesn't connect, use btmon tool to monitor any bluetooth activity and look for error Events (Disconnection Request, Authentication failed, etc..)

from nxbt.

By chance, the solution proposed by Brikwerk can be implemented in an Esp32 with Bluetooth ?, previously it worked in versions lower than firmware 12 for nintendo switch

from nxbt.

I played around with v12_fix. My Switch is on 12.0.1 firmware and I'm using Raspberry Pi 4B to run nxbt. Connecting controller isn't as stable as it used to be but it seems to work in at least 50% of cases. Once I'm able to exit "Change Grip/Order" successfully, connection seems stable.

Now things get weird. I'm not sure if I should post this as a separate issue but I don't know if this is a new thing related to v12 or not. The problem is that I can play Zelda but I cannot play Pokemon Sword unless in-game menu is open. If I exit the menu or simply don't open it before connecting fake controller, it will disconnect me after about 1-2 seconds. I immediately assumed this problem is caused by local communication features which are extensively used in Pokemon games (infamous Y-Comm). There's no way to turn off this feature in-game but I used airplane mode to disallow Wi-Fi entirely and left only Bluetooth on. This confirmed my theory because after reconnecting nxbt everything went smoothly. Honestly this makes no sense to me because controllers are using Bluetooth and Y-Comm is using Wi-Fi, so common sense suggests this should be completely independent. Unfortunately that's clearly not the case. It seems that changing Wi-Fi mode from normal to local affects connected controllers in some way (some kind of "refresh all connections" mechanism?) and it just kills emulated controller with 100% success rate. Do you have any idea about this?

from nxbt.

I played around with v12_fix. My Switch is on 12.0.1 firmware and I'm using Raspberry Pi 4B to run nxbt. Connecting controller isn't as stable as it used to be but it seems to work in at least 50% of cases. Once I'm able to exit "Change Grip/Order" successfully, connection seems stable.

Now things get weird. I'm not sure if I should post this as a separate issue but I don't know if this is a new thing related to v12 or not. The problem is that I can play Zelda but I cannot play Pokemon Sword unless in-game menu is open. If I exit the menu or simply don't open it before connecting fake controller, it will disconnect me after about 1-2 seconds. I immediately assumed this problem is caused by local communication features which are extensively used in Pokemon games (infamous Y-Comm). There's no way to turn off this feature in-game but I used airplane mode to disallow Wi-Fi entirely and left only Bluetooth on. This confirmed my theory because after reconnecting nxbt everything went smoothly. Honestly this makes no sense to me because controllers are using Bluetooth and Y-Comm is using Wi-Fi, so common sense suggests this should be completely independent. Unfortunately that's clearly not the case. It seems that changing Wi-Fi mode from normal to local affects connected controllers in some way (some kind of "refresh all connections" mechanism?) and it just kills emulated controller with 100% success rate. Do you have any idea about this?

Thank you for this information mappzor. I have come to the same conclusions. I will also experiment a little again tomorrow.
A possible cause for the complications between WiFi and Bluetooth could be that both use the same frequency range for communication.

from nxbt.

Same results as @DhSufi here - though I can't get the demo to ever connect.

from nxbt.

Thanks for trying out the changes, everyone. I've pushed some new additions to the v12_fix branch that should hopefully help with the issues I'm seeing.

@DhSufi First, I recommend against using Raspbian Lite for Bluetooth functionality. From some personal testing and evidence online, Bluetooth can be buggy on this version. Second, I'm unable to reproduce the error above that you're encountering. For testing, I used a clean installation of Raspbian (full version) on an RPi 4b and an RPi 3b with a Switch (v12.1.0). If possible, could you try running sudo nxbt test with a clean, full Raspbian installation?

New Changes:

• The Connection Reset Watchdog
  • This new addition will remove a Switch's device profile if it's seen connecting/disconnecting. The threshold for removal is 2 connect/disconnect cycles. The watchdog polls every 0.25s which seems to anecdotally be enough to catch a connect/disconnect cycle. The watchdog only runs when the controller is accepting connections and shuts down afterwards.
  • Removing a Switch seems to break the connect/disconnect loop.
• The test CLI option
  • This new CLI option provides more descriptive and thorough output when debugging NXBT. If you're trying to pinpoint why something isn't working, this is a good place to start now.
  • Run this option with sudo nxbt test
  • I might have this capture output from bluetoothctl (and dump into a text file) in the future so users don't have to run both in conjunction. I'm open to feedback on this.

To use the new version, please run the following:

# If you have a previous version of NXBT
sudo pip3 uninstall nxbt
# Install the new, v12 compliant version with the following
sudo pip3 install git+http://github.com/Brikwerk/nxbt.git@v12_fix

from nxbt.

For testing, I used a clean installation of Raspbian (full version) on an RPi 4b and an RPi 3b with a Switch (v12.1.0). If possible, could you try running sudo nxbt test with a clean, full Raspbian installation?

To use the new version, please run the following:

# If you have a previous version of NXBT
sudo pip3 uninstall nxbt
# Install the new, v12 compliant version with the following
sudo pip3 install git+http://github.com/Brikwerk/nxbt.git@v12_fix

Thanks a lot for your reply. I just tested it and it works perfect!! I am using RPi4b with clean Raspbian (full version) and Switch v12.1.0

Both, sudo nxbt test and sudo nxbt demo worked for me!!

from nxbt.

Likewise - updated to bef7180 here, with no other changes on my RPi 4b since the last attempt, and it now looks to work perfectly. Looking forward to some fun with this over the weekend (time permitting) - thanks!!

from nxbt.

Alright, thanks everyone for testing!

I've pushed a few more changes in the meantime and I believe we're close to a new release. At this point, I'm fairly satisfied with the compatibility level on SwitchOS v12 and v13. Unfortunately, there are still a couple quirks that I haven't been able to completely chase down, however, I think it's more important to get this version of NXBT (as it stands) onto PyPi. I'll list out the new additions/changes below:

Changelog (Sept 26 2021)

• Added Virtual Machine support for Windows and MacOS (check the README and docs folder for more information in the v12_fix branch). VM support has been added through Vagrant.
• Added input sampling frequency options to the web app to help improve latency.
• Added a "Controller Restart" button to the web app.
• Made some frequency/timing changes within the controller server to help with latency and "Change Grip/Order" menu disconnects
• Added a self-signed SSL mode (--usessl) for the web app.
  • This change is necessary due to soon-ish deprecation of controller support on insecure connections (eg: you won't be able to access game controllers [Xbox, Playstation, etc] on locally hosted or insecure sites). Please keep in mind that the SSL certificate generated by NXBT in this mode is completely insecure and not meant for any kind of production or non-local use. Your browser will warn you as such.
• Fixed pairing disconnects characteristic of SwitchOS v13
• Fixed the reconnection and pairing procedure. Reconnections should now be possible on the "Change Grip/Order" menu.
• Fixed reconnecting after forceful disconnection.

Known Bugs

• Repeatedly pressing or mashing buttons while exiting the "Change Grip/Order" menu will result in the Switch kicking the emulated controller. Mitigated with f435d16
• Pairing on SwitchOS v13 can take a bit longer now due to pairing changes. Occasionally, the Switch will drop the connection during pairing, resulting in things taking a bit longer. This can lead to scenarios where pairing a controller takes about 30-60s. Fortunately, these situations were fairly rare from my testing.

If anyone would like to test the new changes, please feel free! I'll let this sit for a few days and slice off of a new release if no huge bugs come through.

With these latest changes, I think we can start bringing this issue to a close 🥳
Thanks for everyone's interest in this project, as always.

from nxbt.

@Brikwerk I am still unable to get it to work, even after uninstalling and reinstalling v12_fix.

The emulated controller connects to the Switch, exits the "Change Grip/Order" menu, and then disconnects.

Edit: Ubuntu VM, Virtual Box, Windows 10 Host :)
Edit 2: This happens when I run sudo nxbt test, sudo nxbt demo, or sudo nxbt remote_tui.

from nxbt.

@unsightedmetal6 Just to make sure, you're reinstalling with the following, right?

sudo pip3 install git+http://github.com/Brikwerk/nxbt.git@v12_fix

Can you try uninstalling/reinstalling again, please? I've pushed a patch that should help a large amount with the disconnects. It turns out that there was a bug with the reconnection procedure previously. The new patch should enable NXBT to save itself when a disconnection occurs.

Based on some previous reports/issues, I'm starting to think that Windows VMs might be more prone to "Change Grip/Order" disconnects than other devices. I'm not able to produce consistent disconnects on a macOS VM or other Linux devices. I'll try to do some debugging on a Windows VM when I have time.

from nxbt.

@Brikwerk Uninstalling, reinstalling, and running sudo nxbt demo worked! Thank you! Your latest patch must have fixed the problem!

from nxbt.

@unsightedmetal6 Great to hear! Thanks for testing the new version.

For everyone: I'm going to start the process of merging the v12_fix branch and publishing a release. After this is done, I believe this issue can officially be brought to a close.

from nxbt.

The release should be officially out now. To those of you who have installed NXBT from the v12_fix branch, I recommend uninstalling and reinstalling with the official PyPi version.

Thanks again to everyone who tested and helped!

from nxbt.

@Brikwerk I'm so sorry to dig up this issue-- I'm working on a general use API for ESP32 and I may have an easy resolution for the refresh rate issue. I believe that the 'enable rumble' command may be a bit more than meets the eye. When it's disabled, it might be a 'low power' mode specifically for menus and playback of media (netflix etc).

I suspect that the lowering of the refresh rate is also a power saving measure on top of not sending voltage to the linear actuators. In my code, when handling the interrupt reports, I set the report frequency in coordination with the vibration bit being 1 or 0 and I have not had any disconnects at this point :)

Hope this helps!

from nxbt.