Binding phrase set in configurator not applied after flashing.

[hydra]

Current Behavior

Binding phrase not applied.

Background: I ended up with a binding phrase mismatch between the TX (old phrase) and 2 new RX's (new phrase) when upgrading TX from 3.x.x to 3.2 using and flashing 3.2 to two never-previously-configured RXs. Likely this scenario will happen to anyone else purchasing new RX's, and flashing them for the first time with a previously used TX.

Steps to Reproduce

1. Binding phrase set in TX via Wifi Web UI.
   

Firmware: UNIFIED_ESP32_2400_TX_3.x.x-maintenance (dfa7d8).zip

2. Later...
3. Different binding phrase set in ELRS Configurator (1.5.5) (new install, no previous firmware built)

Log: ExpressLRSBuildLog_20230313181407382.txt

Firmware: RadioMaster_Boxer_2400_TX-3.2.0.zip

UID bytes: 137,14,68,83,145,153

4. Firmware flashed to TX module using Wifi.

UI says: 'target mismatch' -> 'flash anyway', 'force update' -> OK.

5. Old binding phrase still present.

Possible Solution (Not obligatory)

Details

Your Environment

• TX hardware: Radiomaster Boxer
• RX hardware: Radiomaster EP1
• Handset model:
• OpenTX version (including nightly number) (see screenshots)
• ExpressLRS version (TX & RX MUST MATCH): (see screenshots)
• Packet Rate: N/A
• Telemetry Ratio: N/A
• user_defines: N/A

[hydra]

I had the exact same problem when I went from v3.0.1 (61f27a) to v3.2 today on a different TX module (RadioMaster Ranger Micro 2.4Ghz).

Old firmware:
RADIOMASTER_RANGER_MICRO_2400_TX_v3.0.1 (61f27a).zip

New firmware:
RadioMaster_Ranger_Micro_2400_TX-3.2.0.zip

Build log:
ExpressLRSBuildLog_20230315153746209.txt

...
UID bytes: 137,14,68,83,145,153
...

[hydra]

From discord:

pkendall64:

The problem will likely be that the passphrase was entered via the UI so it saves the data to the SPIFFS partition. On boot we look at the SPIFSS first and use that otherwise we use the JSON > attached to the firmware.
So if you upload firmware with a different pass-phrase it's not going to use it because theres a SPIFFS file.
You can use "reset to defaults" and it will remove the SPIFSS file and reboot, then it will use the firmware attached JSON.

I'm guessing the same might also be true for 'HOME_WIFI_SSID', and 'HOME_WIFI_PASSWORD' and some of the other settings?

@pkendall64 I can think of some potential solutions...

1. in the configurator when setting options, tell the user which settings won't take effect if there's a previously saved option in the config on the device.
2. always reset the previously-saved config when flashing new firmware.
3. always reset the previously-saved config if there's a minor or major version number change (but not for bug-fix releases).
4. have a setting in the configurator that the user can select that will cause the previously-saved config to be erased on first boot.
5. in the configurator, distingush between compile-time options and settings that are defaults. perhaps by renaming items or putting them in a different section. e.g. 'BINDING_PHRASE' could be 'DEFAULT_BINDING_PHRASE' and the help popup/hover-over could explain that the default binding phrase is only applied when no binding phrase is loaded from a config. (edited)

[pkendall64]

I have to think about the right way to do it.

1. It's every setting in configurator
2. If we did this then users would not be able to set their bind-phrase in the web UI and be up and running
3. This is the one that I would tend to go to as a solution with the least downsides and changes
4. This one is not too bad either - a "Keep Existing Settings" checkbox
5. The idea is to remove all the compile time options (other than the debug ones) i.e. they are all settings

Like you mentioned in your list, I think #3 is probably the least invasive option. Although I think also having a banner on the web UI when their are customised settings (like we do for the customised hardware layout) would be a good indicator as well.

[paveltar]

Why there has to be a different source of truth in the first place? Who even bother with SPIFFS partition and not modify the JSON ?

[pkendall64]

Why there has to be a different source of truth in the first place? Who even bother with SPIFFS partition and not modify the JSON ?

Wen a user gets a device from the factory and wants to use their bind phrase, they enter it into the web-UI and that creates a JSON on the SPIFSS partition.

[stuntik]

Happened to me. I flashed Rp1 with 3.2.0 and a binding phrase, but it didn't bind to the TX16 with the same binding phrase until I cleared the binding phrase from the receiver. Wasted hours in troubleshooting.

Possibly its a different bug, since I saw in the receiver's web interface codes of my binding phrase

[uff-da]

So I am brand new to ExpressLRS, and I dowloaded the configurator 1.5.9 and flashed my TX and RX with 3.2.1 over home network wifi.
equipment: Radiomaster Ranger, and Radiomaster ER5A.
Neither flash updated the binding phrase I provided, nore the new value for the wifi auto on interval.
I had to go into the web interphase, and update and save manually for it to bind and work.
So I am guessing this is still an issue with the latest code?
FYI, the actual software on the module did update to 3.2.1, just not the settings I gave in the configurator.

[AlaskaJason1090]

So I am brand new to ExpressLRS, and I dowloaded the configurator 1.5.9 and flashed my TX and RX with 3.2.1 over home network wifi. equipment: Radiomaster Ranger, and Radiomaster ER5A. Neither flash updated the binding phrase I provided, nore the new value for the wifi auto on interval. I had to go into the web interphase, and update and save manually for it to bind and work. So I am guessing this is still an issue with the latest code? FYI, the actual software on the module did update to 3.2.1, just not the settings I gave in the configurator.

I just installed the 3.2.1 on a brand new TX 12 MKII ELRS and the binding phrase will not save. I have done a couple different firmware updates just to be sure. The Binding phrase doesnt save when going through TX wifi either. its verified 3.2.1.

[pkendall64]

What makes you say the binding phrase will not save? When you enter a binding phrase it generates a UID which you can see in the field below the binding phrase. It's the UID that is saved, not the binding phrase.

[uff-da]

from the looks of issue pull request 2149. this issue will be fixed in V3.3 when ever that is.