Enable or disable features according to port configuration

[haslinghuis]

Fixes: #329

[McGiverGim]

The idea is great, but has some sense to define the port and disable the feature?

If not, to me, the correct way is to remove completely the "feature" in the firmware, and make it enable it simply when defined the port.

[blckmn]

AUTOMERGE: (FAIL)

• github identifies PR as mergeable -> PASS
• 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]

Something like that woudl work as well

Suggested change

	serialPortConfig.functions.forEach(e => {
	if (e === 'RX_SERIAL') {
	enableRxSerial = true;
	}
	if (e.startsWith("TELEMETRY")) {
	enableTelemetry = true;
	}
	});
	if (serialPortConfig.functions.indexOf('BLACKBOX') >= 0) {
	enableBlackbox = true;
	}
	if (serialPortConfig.functions.indexOf('ESC_SENSOR') >= 0) {
	enableEsc = true;
	}
	if (serialPortConfig.functions.indexOf('GPS') >= 0) {
	enableGps = true;
	}
	let functions = serialPortConfig.functions
	enableRxSerial = functions.includes('RX_SERIAL');
	enableTelemetry = functions.some(e => e.startsWith("TELEMETRY"));
	enableBlackbox = functions.includes('BLACKBOX');
	enableEsc = functions.includes('ESC_SENSOR');
	enableGps = functions.includes('GPS');

[haslinghuis]

Thanks. Much easier to read.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[McGiverGim]

As requested, I can approve it if you want, but as I said, I think this is not the correct approach.

This is a workaround more that we need to maintain in the Configurator.

I think that if we want that something is enabled or disabled automatically, is better to remove the feature in the firmware and simply make it enabled by default. Or if we want to maintain the feature, enable it in the firmware not in the Configurator when it receives the MSP command.

The problem with the Configurator is that we need to maintain backward compatibility, if the things change between versions, we need to maintain old and new code. If we do this in the firmware part and it changes in a future, the old code is simply removed and new code replaces it.

[limonspb]

As requested, I can approve it if you want, but as I said, I think this is not the correct approach.

This is a workaround more that we need to maintain in the Configurator.

I think that if we want that something is enabled or disabled automatically, is better to remove the feature in the firmware and simply make it enabled by default. Or if we want to maintain the feature, enable it in the firmware not in the Configurator when it receives the MSP command.

The problem with the Configurator is that we need to maintain backward compatibility, if the things change between versions, we need to maintain old and new code. If we do this in the firmware part and it changes in a future, the old code is simply removed and new code replaces it.

i would agree, sounds reasonable

[mituritsyn]

Could VTX tab be hided with the same logic in this PR? Discussed it with @limonspb a week ago and was going to open own PR.

P.S. I like @McGiverGim proposion

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[github-actions]

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!