betaflight-configurator
betaflight-configurator copied to clipboard
Custom protocol URI scheme to open the configurator (btfltcp://)
Fixes #2281
This PR makes it possible to open the Betaflight Configurator and immediately initialize a TCP connection via a custom URI protocol scheme: btfltcp://. The IP/URL (and optionally the port) of the TCP host (e.g. an ExpressLRS receiver connected via WiFi) can be passed in as: btfltcp://{{address}}:{{port}} - thus e.g. btfltcp://10.0.0.1, btfltcp://10.0.0.1:5761 or even btfltcp://elrs_rx.local.
The scheme is automatically registered with the OS by the Configurator on all platforms during installation (currently Linux, Windows, OSX and Android). On all NW.js builds (Linux, Windows and OSX), the invocations with the scheme are handled both on a "cold start" as well as while the Configurator is running. On the Cordova (Android) builds, the cordova-plugin-customurlscheme NPM dep. is used to both register and handle the invocations with the custom URI scheme.
Testing
The changes (as of commit 57c1883e3ea698d92f16770a5d7d36de53c8cce1) have been tested on the following platforms:
- [x] Linux (deb)
- [x] Linux (rpm)
- [x] Android (emulated)
- [x] Android (physical)
- [ ] OSX
- [x] Windows
:information_source: Please note that in order to test this feature you must select the enableURIScheme experimental configuration option (it is not necessary to restart the configurator afterwards):
Next steps
- (question to maintainers :question: ) Should we do anything special for the SpeedyBee app or would they decide to handle the change on their own? It would be good to see if multiple Android applications can handle the same deep link / custom URI scheme (so that the user can choose which one to open).
- The ExpressLRS Web UI can be updated with a link to open the Betaflight Configurator (as simple as e.g.
<a href="btfltcp://{{ip}}">Open Betaflight Configurator</a>)
Demos
- Linux (cold start)
-
Linux (warm start)
-
Android (cold start)
-
Android (warm start)
-
Experimental configuration option toggling
Do you want to test this code? Here you have an automated build: Betaflight-Configurator-Android Betaflight-Configurator-Linux Betaflight-Configurator-macOS Betaflight-Configurator-Windows WARNING: It may be unstable and result in corrupted configurations or data loss. Use only for testing!
Do you want to test this code? Here you have an automated build: Betaflight-Configurator-Android Betaflight-Configurator-Linux Betaflight-Configurator-macOS Betaflight-Configurator-Windows WARNING: It may be unstable and result in corrupted configurations or data loss. Use only for testing!
Do you want to test this code? Here you have an automated build: Betaflight-Configurator-Android Betaflight-Configurator-Linux Betaflight-Configurator-Windows Betaflight-Configurator-macOS WARNING: It may be unstable and result in corrupted configurations or data loss. Use only for testing!
Do you want to test this code? Here you have an automated build: Betaflight-Configurator-Android Betaflight-Configurator-Linux Betaflight-Configurator-Windows Betaflight-Configurator-macOS WARNING: It may be unstable and result in corrupted configurations or data loss. Use only for testing!
Do you want to test this code? Here you have an automated build: Betaflight-Configurator-Linux Betaflight-Configurator-Android Betaflight-Configurator-Windows Betaflight-Configurator-macOS WARNING: It may be unstable and result in corrupted configurations or data loss. Use only for testing!
Do you want to test this code? Here you have an automated build: Betaflight-Configurator-Android Betaflight-Configurator-Linux Betaflight-Configurator-Windows Betaflight-Configurator-macOS WARNING: It may be unstable and result in corrupted configurations or data loss. Use only for testing!
Do you want to test this code? Here you have an automated build: Betaflight-Configurator-Android Betaflight-Configurator-Linux Betaflight-Configurator-Windows Betaflight-Configurator-macOS WARNING: It may be unstable and result in corrupted configurations or data loss. Use only for testing!
✅ Checked on M1 Max: OSX Sonoma 14.3.1
Do you want to test this code? Here you have an automated build: Betaflight-Configurator-Android Betaflight-Configurator-Linux Betaflight-Configurator-Windows Betaflight-Configurator-macOS WARNING: It may be unstable and result in corrupted configurations or data loss. Use only for testing!
should not be there when connected.
Deploy Preview for origin-betaflight-configurator failed.
| Name | Link |
|---|---|
| Latest commit | b6dd017f3ae2befc9dbcc768aeec53ae6833315d |
| Latest deploy log | https://app.netlify.com/sites/origin-betaflight-configurator/deploys/660b4e8130203e00089756ea |
Do you want to test this code? Here you have an automated build: Betaflight-Configurator-Android Betaflight-Configurator-Linux Betaflight-Configurator-Windows Betaflight-Configurator-macOS WARNING: It may be unstable and result in corrupted configurations or data loss. Use only for testing!
should not be there when connected.
Thanks for noticing @haslinghuis ! Indeed we had a bug where the #port-override-option was not being properly hidden upon connection establishment (I have since fixed it so it's both hidden on connection and shown after the disconnect callback). I also updated the screen recordings to show the new UI behavior.
Do you want to test this code? Here you have an automated build: Betaflight-Configurator-Android Betaflight-Configurator-Linux Betaflight-Configurator-macOS Betaflight-Configurator-Windows WARNING: It may be unstable and result in corrupted configurations or data loss. Use only for testing!
Do you want to test this code? Here you have an automated build: Betaflight-Configurator-Android WARNING: It may be unstable and result in corrupted configurations or data loss. Use only for testing!
Do you want to test this code? Here you have an automated build: Betaflight-Configurator-Android Betaflight-Configurator-Linux WARNING: It may be unstable and result in corrupted configurations or data loss. Use only for testing!
Do you want to test this code? Here you have an automated build: Betaflight-Configurator-Android Betaflight-Configurator-Linux Betaflight-Configurator-macOS WARNING: It may be unstable and result in corrupted configurations or data loss. Use only for testing!
Do you want to test this code? Here you have an automated build: Betaflight-Configurator-Android Betaflight-Configurator-Linux Betaflight-Configurator-macOS Betaflight-Configurator-Windows WARNING: It may be unstable and result in corrupted configurations or data loss. Use only for testing!
Trying to test this pr but after installing a portable version here on windows 11 https://github.com/betaflight/betaflight-configurator/suites/22069555096/artifacts/1360150995 there is no way thru elrs or directly on BF configurator (manual selection) to use btfltcp://... A more detailed use for portable windows version is appreciated.
It's the installer who associates the uri to the Configurator. Maybe we can look for a workaround for portables.
It's the installer who associates the uri to the Configurator. Maybe we can look for a workaround for portables.
I was 99% sure, but i love portables, may author can set a script to install or/and un-install the missing steps. Thanks. Btw it looks a cool feature with a future for development and integration with other software. Compliment to the author.
Installed the windows installer version to test, typing btfltcp://10.0.0.1 request to open BF. All ok.
All tab seems to work except Ports and VTX tab hang on waiting for data
I also have some concern on the flow of operations. Example i power my FC (a speedybee stack) via usb that also provide power the elrs, If configurator has set auto-connect what happens? Will i run 2 configurator one via usb/com and one via elrs? Which has priority/preference? Is this PR intented to be "on the field" or for portable usage ? Again the idea is great, but i think needs some more in depth usage consideration.
Do you want to test this code? Here you have an automated build: Betaflight-Configurator-Android Betaflight-Configurator-Linux Betaflight-Configurator-macOS Betaflight-Configurator-Windows WARNING: It may be unstable and result in corrupted configurations or data loss. Use only for testing!
Quality Gate passed
Issues
0 New issues
0 Accepted issues
Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code
Usability issues needs to be addressed. We are already in RC phase, so want to mark this as experimental feature as it takes time for real public testing to take place and discover other edge cases I would suggest to implement this as an option like we have done for mDNS.
@haslinghuis That is indeed a great idea - thank you! :) I have since added the new enableURIScheme configuration optional (disabled by default):
P.S. Forgot to mention - since the URI scheme is associated on the OS level during installation, the configurator will be opened once it's invoked, no matter the enableURIScheme value. However if enableURIScheme is disabled the we won't take any action whatsoever.
Do you want to test this code? Here you have an automated build: Betaflight-Configurator-Android Betaflight-Configurator-Linux Betaflight-Configurator-macOS Betaflight-Configurator-Windows WARNING: It may be unstable and result in corrupted configurations or data loss. Use only for testing!
@Pancronos
It's the installer who associates the uri to the Configurator. Maybe we can look for a workaround for portables.
I was 99% sure, but i love portables, may author can set a script to install or/and un-install the missing steps.
Indeed - the feature at hand would not work for the portable executables since the installer is the one associating the URI scheme with the configurator binary installation path (on the OS level).
I think it is theoretically possible to implement that feature for the portable binaries - using e.g. something like the protocol-registry NPM dependency to register the URI scheme after the configurator has booted up (or once the configuration is selected).
(In fact I initially implemented it that way but dropped the approach due to some of the issues I ran into).
However IMHO there are some drawbacks to doing permanent URI scheme associations with a portable executable:
- The executable can easily be moved / removed - which would leave a "dangling" URI scheme association in the OS.
- Some users might be wary of a portable executable doing "permanent" changes to their OS (such as creating
.desktop/.plistfiles on Linux/OSX and editing the OS registry on Windows).- Some of the issues I ran into with
protocol-registryare also related to this point. Normally the NW.js app runs in a sandboxed environment which doesn't let it do certain broader changes in the OS. I'm worried that the only potential workaround might be to run the configurator as root/admin which is definitely a bad practice.
- Some of the issues I ran into with
- We might have to maintain more code/logic as the installer and runtime implementation would be quite different.
That being said - I'm open to explore the possibilities as long as the maintainer don't think any of the above drawbacks might be a deal breaker.
Thanks. Btw it looks a cool feature with a future for development and integration with other software. Compliment to the author.
Thank you! :blush:
@Pancronos Thank you for testing and evaluating the feature! :pray:
Installed the windows installer version to test, typing btfltcp://10.0.0.1 request to open BF. All ok. All tab seems to work except Ports and VTX tab hang on waiting for data
Would you mind sharing your Betaflight (firmware) and ExpressLRS versions? Also does the issue occur only when connecting via the URI scheme or also on master (/ the latest releases) when manually connecting to 10.0.0.1?
On my side I couldn't consistently reproduce it for the tabs you mentioned but I suppose there might be something as I occasionally saw some MSP timeouts in the development console when browsing through the configurator.
If this bug is also present on master / the latest releases I can suggest we open a new issue since there might be a problem with the underlaying connection mechanism (which wasn't really changed in this MR).
I also have some concern on the flow of operations. Example i power my FC (a speedybee stack) via usb that also provide power the elrs, If configurator has set auto-connect what happens?
That is indeed a very good question! From what I have noticed, on a cold start the URI scheme would take precedence over the "auto connect" feature (since it seems to be faster to start establishing the network connection than to discover all USB devices). However that might not always be the case - thus what I can propose is that we automatically disable the "auto-connect" upon a URI scheme invocation?
Will i run 2 configurator one via usb/com and one via elrs?
AFAIK that's not really possible since there is only one configurator instance at any given time (be it a "cold start" or a "warm start"). As such the configurator can connect to either a TCP address or a USB device.
Is this PR intented to be "on the field" or for portable usage ? Again the idea is great, but i think needs some more in depth usage consideration.
To be honest the sole use-case I considered is the "portable" one (e.g. via the receiver's WiFi network with a shortcut in the ExpressLRS web UI). I wouldn't see much value in doing a TCP-based connection if the FC is already plugged to the host via USB (since I assume the USB connection to be more stable + versatile). However if you can think of any other potential use-cases that might need an adjustment in the implementation I would be very happy to take a look :relaxed:
Don't know why but now after connecting ELRS (my drone is with pc-usb that powers elrs) doesn't work with 10.0.0.1 but it works with elrs .local i attached console log where is goes in timeout on some tabs
Just tried btfltcp://10.0.0.2 request to open BFConfigurator but it return port error (no configurator windows were open)
