I'm shocked that this is a problem for you and the cult you've collected to come cheer for it 😆 How can something happen both so frequently and also be so unexpected?

I know the name wasn't your choice but it is also wrong. It is not permanent-- it can be changed when flashing or from the webui. It is just preventing going into bind mode so it should be named accordingly. I feel like there's no use case for blocking the BIND command from betaflight / edgetx / the lua, this only restricts the usability of the system and is solely a casualty of where you chose to place your code. It should only block the button and the 3-plug if that's what you folks keep doing by mistake, and be named / described accordingly.

The way this is implemented also has some issues:

• Because the receiver never enters binding mode, it keeps trying to enter binding mode over and over, which seems a little hacky
• The button still will reboot the receiver expecting to put it into binding mode but then nothing happens.

I don't want this code sprinkled all over the place to resolve those issues either, there should just be one line like you've got it, but with the rest of the code refactored to accommodate the new mode. No rush on that either, because we're past the 3.5 feature freeze so this will be for 3.6 if accepted (and also I am not enthusiastic about doing the 50 different case testing that this will require).

I'm shocked that this is a problem for you and the cult you've collected to come cheer for it 😆 How can something happen both so frequently and also be so unexpected?

There were some great answers in the pull request as to why the robot combat community doesn't like the new bind options. It's unavoidable risk due to the weirdness of robot combat.

I know the name wasn't your choice but it is also wrong. It is not permanent-- it can be changed when flashing or from the webui. It is just preventing going into bind mode so it should be named accordingly. I feel like there's no use case for blocking the BIND command from betaflight / edgetx / the lua, this only restricts the usability of the system and is solely a casualty of where you chose to place your code. It should only block the button and the 3-plug if that's what you folks keep doing by mistake, and be named / described accordingly.

The way this is implemented also has some issues:

• Because the receiver never enters binding mode, it keeps trying to enter binding mode over and over, which seems a little hacky
• The button still will reboot the receiver expecting to put it into binding mode but then nothing happens.

I don't want this code sprinkled all over the place to resolve those issues either, there should just be one line like you've got it, but with the rest of the code refactored to accommodate the new mode. No rush on that either, because we're past the 3.5 feature freeze so this will be for 3.6 if accepted (and also I am not enthusiastic about doing the 50 different case testing that this will require).

Yea I do agree it should only block the button bind and 3-plug option.

Do you want to drop the "Permanent" moniker and use "Administrated"? It seems like if we disable only the 3-cycle and button bind, only the "administrator" can change binding.

Any movement on this feature being added?

Let's get it renamed to "Administered" and I think we'd be happy with that

V4 (master) will be some time away. Could you rebase this on 3.x.x-maintenance and we could get this into a 3.6 or 3.5.?

I hope you don't mind, but I fixed up the rebase and force pushed the branch so it cleanly applies to 3.x.x-maintenance

Cool I didn't really know what to do but typing in the word rebase and 3.x.x-maintenace seemed to do something lol

Any movement here? I would like to have this feature for my combat robots

@CapnBry Any chance you could do the final review for this feature?

Just trawled through the various threads about disabling 3-plug binding. It's also a desirable feature for me, i've had several robots reset to binding mode as a result of regen braking while off. Current solution has been to return to 3.3.2 firmware to prevent this.