Expose Cloud Build Options and hide tabs and features #3332

haslinghuis · 2023-02-09T05:21:05Z

Keeps default behavior when BUILD_KEY or internet connection is not available
Retrieve cloud build options using BUILD_KEY in auto-detect and serial backend
Hides features which are not in cloud build (configuration tab and telemetry for receiver tab)
Shows tabs which are in cloud build and hide if not.

Please test with firmware betaflight/betaflight#12388 as this would address:

features can be enabled but we still have to save to eeprom to activate - this should be done in firmware with cloud build options but not sure how we macro that up with DEFAULT_FEATURES

🤔 Future improvements:

moving feature switch to respective tab
having port configuration on each tab with label for function, if there is already a function a warning will indicate saving will disable the previous function.
receiver configuration
motor protocol configuration

As example a very simple build for a LOS build:

we see:

As for a more sophisticated build like:

we see:

Originally we see features which are not available in firmware:

src/js/fc.js

src/js/serial_backend.js

blckmn · 2023-02-09T08:17:08Z

AUTOMERGE: (FAIL)

github identifies PR as mergeable -> FAIL
assigned to a milestone -> PASS
cooling off period lapsed -> PASS
commit count less or equal to three -> PASS
Don't merge label NOT found -> PASS
at least one RN: label found -> PASS
Tested label found -> FAIL
assigned to an approver -> PASS
approver count at least three -> FAIL

chmelevskij · 2023-02-10T11:46:17Z

src/js/BuildApi.js

+    requestBuildOptions(key, onSuccess, onFailure) {
+        const url = `${this._url}/api/builds/${key}/json`;
+        $.get(url, function (data) {
+            onSuccess(data);
+        }).fail(xhr => {
+            if (onFailure !== undefined) {
+                onFailure();
+            }
+        });
+    }


Can we promisify this instead then just use try/catch or then/catch? There are now n + 1 callback patterns in this codebase for callbacks 😆

We are getting the features from the cloud build information? This is not the way. What if the build is very old, we will store ALL the builds in the time? What if the build is a local custom build? If we want to get this information, I think we need to create MSP commands in the firmware, that can tell us what features/other UI elements are enabled or not.

if it's very old and not stored, just display defaults.

personally don't like the idea of more MSP. (more data storage). maybe with future MSP2, there is cli get to determine existence or not? unsure of a clear solution, ATM.

@chmelevskij was just following same pattern in the api.
@McGiverGim there is a msp call to retrieve the buildkey. With the buildkey we request data from the cloud api filling some MSP variables. We might be able to store the filter in the cloud api. We only can use this from semver 1.45.
Local builds will have no buildkey (need to check).
I'd like to lock some configuration fields with cloud parameters as to hide items that are not included in the cloud build but the user still was able to select. Thoughts?

As I say, in my opinion, the configurator must work with customs builds too, but the change to cloud build is a very big step and the Configurator had left outdated showing features that does not exist.
Maybe with the new MSP call with CLI we can ask for features to the CLI, if it shows an error then does not exist.

I think there's two different issues here.

The first is using the build key, the user can default their build options to that contained for that key. Key not being user specific but build specific. Without key (custom or key not found) the build options revert to default. The dependency on the api is not a problem here because, well you need it to get the build anyway!

The second is what actual features in configurator are enabled. Eg don't show GPS tab if GPS not built in. That should come from the firmware. Using the cli suggestion is good.

@blckmn sorted now:

Buildkey availability determines behavior.
The tab issue is also resolved.

McGiverGim · 2023-02-10T12:01:01Z

locales/en/messages.json

-    "featureSONAR": {
+    "featureRANGEFINDER": {
        "message": "Sonar"
    },


If for the user this is more a "Sonar", maybe is better to rename it in the firmware and not here?

Good call, will change RANGEFINDER to SONAR in firmware but RANGEFINDER is just one possible SONAR device?

McGiverGim · 2023-02-10T12:03:12Z

src/js/Features.js

+    self._features = features;
+
+    if (semver.gte(config.apiVersion, API_VERSION_1_45) && FC.CONFIG.buildKey) {
+        const filter = ["GPS", "DASHBOARD", "LED_STRIP", "OSD", "RANGEFINDER", "SERIAL_RX", "SERVOS", "SPI_RX", "TELEMETRY", "TRANSPONDER"];


I think we are having too much hardcoded elements. This will require to maintain in coherence firmware/configurator. I understand to do this for features, that is something that we are trying to remove so it will not grow, but I don't know if we are planning to do the same for other UI elements.

Yes this is hack, becomes the 'other' group contains also non-features. While features are very stable over time this PR is just enabling support for cloud parameters AND applying this to features as a demonstration.

Have removed the hack and added a property to the feature instead.
Also made sure it works with non cloud builds

McGiverGim · 2023-02-10T12:06:30Z

src/js/BuildApi.js

+    requestBuildOptions(key, onSuccess, onFailure) {
+        const url = `${this._url}/api/builds/${key}/json`;
+        $.get(url, function (data) {
+            onSuccess(data);
+        }).fail(xhr => {
+            if (onFailure !== undefined) {
+                onFailure();
+            }
+        });
+    }


We are getting the features from the cloud build information? This is not the way. What if the build is very old, we will store ALL the builds in the time? What if the build is a local custom build? If we want to get this information, I think we need to create MSP commands in the firmware, that can tell us what features/other UI elements are enabled or not.

haslinghuis · 2023-02-12T01:44:34Z

IGNORE THIS COMMENT :)

        self._features = features.map(feature => {
            return {
                ...feature,
                available: filter.some(opt => opt.includes(feature.name)) ? FC.CONFIG.buildOptions.some(opt => opt.includes(feature.name)) : true,
            };
        }).sort((a, b) => a.name.localeCompare(b.name, window.navigator.language, { ignorePunctuation: true }));

This works:

        for (const f of features) {
            if (FC.CONFIG.buildOptions.some(opt => opt.includes(f.dependsOn)) || f.dependsOn === undefined) {
                console.log('Adding:', f.name);
                self._features.push(f);
            }
        }

But this does not:

        self._features = features.filter(feature => FC.CONFIG.buildOptions.some(opt => opt.includes(feature.dependsOn) || feature.dependsOn === undefined))

nerdCopter · 2023-02-21T21:57:38Z

Seems to be populating cloud-build options properly with exception of the CRSF,GHST,SBUS multi-option which populates as SBUS.
Maybe the Radio Protocol field can be reverted to the same style as Other Options. @blckmn

haslinghuis · 2023-02-21T22:18:31Z

The CRSF,GHST,SBUS option should be removed as everybody should know some basics.

haslinghuis · 2023-02-25T20:41:02Z

Thanks, updated to semver 1.46.

haslinghuis · 2023-02-28T00:34:50Z

@nerdCopter please check again.

🤔 We might decouple features toggling tabs (like GPS) to being enabled by default (if GPS option is included in build)

nerdCopter · 2023-02-28T14:12:02Z

i'm seeing same behavior as last screenshot for 4.4.0. However, i'm not sure what to expect.
I cannot seem to test master at this time as it's broken for my unsoldered TMOTORF7 (Failed to open serial port after flash)

haslinghuis · 2023-02-28T14:25:56Z

@nerdCopter betaflight/betaflight#12308 was the last working for boards having same issue (all leds are solid indicating hard fault)

nerdCopter · 2023-02-28T15:04:09Z

@nerdCopter betaflight/betaflight#12308 was the last working for boards having same issue (all leds are solid indicating hard fault)

unfortunately #12308 not working for TMOTORF7 :( i'll pan through some older SHA's
edit: on second thought, older commits will not include #12388 :(

haslinghuis · 2023-02-28T15:09:54Z

#12388 needs a redesign now we are removing custom defaults.

nerdCopter · 2023-03-02T17:29:12Z

sorry @haslinghuis , i'm hiding last comment as it checks for 1.46 now. unsure how to further test without a live 1.46.

haslinghuis · 2023-03-02T17:31:34Z

You could test with commit #12425

nerdCopter · 2023-03-02T17:46:39Z

#12425 is still msp 1.45 unfortunately. suppose i can mod locally for the purposes of testing.

haslinghuis · 2023-03-02T17:53:05Z

It works with #12323 (after applying defaults)

Add cloud build options to auto-detect

sonarqubecloud · 2023-03-02T19:47:09Z

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

haslinghuis · 2023-03-02T19:47:46Z

@nerdCopter fixed the tab issue (inverting check and make available for 1.45)

github-actions · 2023-03-02T19:58:00Z

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!

nerdCopter · 2023-03-02T21:09:19Z

needs hide/show for servos toggle, then i think it's good to go. EDIT: 0a54e258 servos works.
caveat is the CRSF,GHST,SBUS option which i suppose needs to be a separate PR. want to re-iterate i'd prefer same look&feel as custom defines (bubbles)

nerdCopter

💪🚀

haslinghuis added the RN: IMPROVEMENT label Feb 9, 2023

haslinghuis added this to the 10.10.0 milestone Feb 9, 2023

haslinghuis self-assigned this Feb 9, 2023