They've been doing tool-assisted runs on real hardware for a while now:

http://tasvideos.org/TASBot.html

In addition to TASBot, there's also a growing practice of using physical rigs to "verify" tool-assisted runs:

http://tasvideos.org/ConsoleVerificationGuide.html

This isn't generally regarded as necessary for a TAS to be valid, but it allows it to work on TASBot and similar rigs, which can help it get in front of a wider audience. It also helps figure out which TAS techniques are theoretically possible in non-TAS runs.

the importance of console verification is to make sure a TAS isn't relying on any emulator bugs (such as timing, uninitialized memory, etc) and would theoretically be possible on the actual hardware. it also speaks to the accuracy of the emulations themselves

For a specific example of something like this being important, remember the (very impressive) Watch for Rolling Rocks in 0.5 A presses video from a couple years ago? https://www.youtube.com/watch?v=kpk2tdsPh0A (For the uninitiated, this video presents a TAS of Super Mario 64 which beats the level Watch for Rolling Rocks without pressing the A button outside of keeping it held from entering the level.) It turns out that the route presented in the video actually fails console verification, since the crazy things he does trigger some annoying FPU crashes on console, but not on emulator. There is a happy end, though: a fixed route was published after this was discovered, and it passes console verification just fine (assuming the inputs dont desync over the 13 hour run)

Neat, I've always been into speed running, but my neighbour introduced me to TAS not too long ago.

This is all super cool, thanks everyone.

Console verification is an important part of ensuring TASes are accurate. For that, we need an interface into the console's controls among other things.

Well, given that this controller talks bluetooth, wouldn't a logical way to control the input be to write a BT stack that emulates the controller?

I know its not the legit real controller, but buttons are buttons (analog or digital). As long as you don't mod the console itself, that should be fine for the TAS community, no?

I'm curious about this too. There's also a physical connection between the joycons and tablet which can be used instead of the Bluetooth.

I believe the main issue is that it's very easy to electrically simulate button presses and be confident that the rest of the system is functioning correctly. Once you start simulating the entire controller and its protocol for communicating with the console, you start to enter a realm where it may be possible to trigger inputs that are not physically possible with the actual controller hardware.

I'd assume for precise play/speedruns you'd use the controller in the physically connected mode, not over Bluetooth? (with random delays potentially)