Keeping your hub connected while using pybricksdev

[dlech]

This has been a common request for pybricksdev. ₁

Thanks to some hard work and dedication by @shaggysa you no longer have to reconnect your hub each time you want to download and run a new version of the program you are working on each time you make a change. Just update pybricksdev to version 2.1.0 or higher and then add --stay-connected the next time you do pybricksdev run ... and when the program running on the hub ends, you will see a menu asking what to do next and the hub will stay connected so that it won't turn of while you are making changes to your code!

It looks like this:

$ pybricksdev run ble tmp/test.py  --stay-connected
Searching for any hub with Pybricks service...
100%|█████████████████████████████████████████████████████████████| 65.0/65.0 [00:00<00:00, 2.70kB/s] 
Hello, World!
The program was stopped (SystemExit).
? Would you like to re-compile your code? (Use arrow keys)
 » Recompile and Run
   Recompile and Download
   Exit

Footnote:
1: Although my search skills are failing me at the moment to actually find them. If anyone has a link to where someone asked for this feature, add it in a comment below.

[MrGibbage]

Can you add some more details here? The "recompile and run" option sounds like it is meant to just send the same program to the hub again and run it. Recompile and Download sounds like it will download your same code but this time not execute it. Which seems strange since the code is already downloaded on the hub. I guess Exit just exits the pybricks program and stops the running code on the hub? Then after a couple of minutes the hub will time out and turn off?

I have a couple of use cases that I would like to consider

1. Program started with pybricksdev, but never ended. For example, if there is a line of code to run a motor for 360 degrees, but gets physically blocked at 180. The program is still running. The programmer notices this and updates the code. When they try to re-upload the code, it will fail because the program is still running (they never stopped it). The programmer sees the failure, hos no idea what happened and they call me over. I hit the start/stop button, tell them to relaunch their new program and it works. It would be nice if there was a better failure message here. I would expect this new behavior wouldn't be triggered since the program never ended??

2. Program started with pybricksdev and runs to completion. After a couple of minutes, the hub turns off. Right now when this happens the kids rarely notice because they are probably busy updating their code, or doing tik tok dances. Hard to say. But eventually they get back to trying to upload an updated program and it fails, retriggering the "call the coach" Do Loop. I think this is the exact use case this new fix is targeting? But I think the problem will be if they don't choose one of the options? And may I suggest that the presentation text prompts aren't very clear and easy to understand? I think something like "Stay connected and keep hub powered on" and "Disconnect hub and power down" (not sure what the "Exit" option does. Or, am I completely missing the use case? What happens if none of the options are selected because I think most of the time the kids will just forget to select anything.

Since you are working on pybricksdev right now, I would like to see if we can have a configurable timeout parameter that keeps the hub powered on for a longer period of time. I'm not sure what the delay is now, but it is too short for us. It would be great as a command line option so I can configure it with our VS Code script,

I don't have a hub with me, but I look forward to testing this!

[dlech]

option sounds like it is meant to just send the same program to

The point is that you should modify your code before selecting "recompile and run". Otherwise, there is no need to re-download.

I don't have a hub with me, but I look forward to testing this!

I'll wait before replying to anything else. I think actually trying it will answer most of your questions.

[shaggysa]

I actually implemented this feature, so I can fill you in on some of the details. I also help coach a team, so ease-of-use was a big concern for me when working on it.

Can you add some more details here? The "recompile and run" option sounds like it is meant to just send the same program to the hub again and run it.

The program recompiles the file you provided in the original prompt (hence re-compile and run), so any saved updates to that file (or dependencies) since the last time you uploaded your code to the hub will be respected.

The program is still running. The programmer notices this and updates the code. When they try to re-upload the code, it will fail because the program is still running (they never stopped it). The programmer sees the failure, hos no idea what happened and they call me over.

The menu does not show up until the last program has ended. It is also canceled when a program is manually started (and will be brought back when that program ends). You will still have to stop the program manually, but it might be possible in the future for us to modify way "run" works (at least in --stay-connected mode) so that a KeyboardInterrupt will be intercepted and cancel the hub program rather than stop pybricksdev ⃰ .

After a couple of minutes, the hub turns off.

The main point of the --stay-connected flag is that it will stay connected to the hub through bluetooth.
The hub doesn't time out while it is still connected through bluetooth. As long as you don't pick the exit option or leave bluetooth range, it won't power off on it's own. If it becomes disconnected (manually turned off or leaves bluetooth range), a Y/n prompt will show up asking if you want to reconnect.

not sure what the "Exit" option does. Or, am I completely missing the use case?

It just disconnects the hub from bluetooth and stops pybricksdev

What happens if none of the options are selected because I think most of the time the kids will just forget to select anything.

The default option is decided based on the --start flag. If it is true, the default option will be to run your new code. If false, the default option will just download it. You can select it just by pressing enter. Otherwise, you can use the up/down arrow keys to select other options (a pointer will show you which option is currently selected).

*Looked at the code, turns out it would require some pretty significant structural changes for KBI intercepting to work. I'm not sure it's worth the trouble.

[bubulux]

This is a very cool feature, thx!

One question though: Can I specify which command for it to run when "recompiling"?

In my case I got tons of custom build scripts / monitor wrappers around my dev environment, so code changes arent reflected by my src/main.py but rather a build/main.py file.

Is that possible, to opt out of the default behavior and pass a custom recompile script to it?

I'll be fine without it, just wondering if thats possible and I just can find the CLI option for it...

Best Sam

[shaggysa]

Can I specify which command for it to run when "recompiling"?

In the current state, it just re-compiles and sends whichever file you you specified initially. This re-compile also propagates changes made to files that are imported by the main script.

If you are using pybricksdev in a more programmatic way and want to resend your code, I would recommend checking out the source code for the main send script (pybricks/cli/__init.py, lines 226-323) to look at the methods being used to achieve this. Several new methods were added to the hub class in 2.1.0

[MrGibbage]

Finally got a chance to do some testing. I see how it works, and I can easily see how some people will love it. For us, we use Tasks in VS Code to run the pybricksdev program, triggered by a keyboard shortcut. When the programmer is ready to test their code, they type "ctrl-L" (L for Launch). That will save their code and launch pybricksdev.exe and run their code. Assuming the code runs to completion, but requires an update, they simply make the desired changes and type ctrl-L again. Update, Ctrl-L. Update, Ctrl-L. Sometimes we have to hit the Big Brick Button, and sometimes the hub powers off, or sometimes the kids will accidentally turn the bluetooth off, but we have gotten pretty used to those things.