Change the state of customizable buttons via special functions

[TGS78]

Is there an existing issue for this feature request?

• I have searched the existing issues

Is your feature request related to a problem?

I use one of the six customizable function buttons on my Jumper T20 to enable f.e. the Betaflight Air Extension. But I would also like to automatically switch off the Air Extensions when I change to angle mode. I know this function can be already achieved via the Betaflight Modes, but the LED of the customizable function button would then be incorrect. So changing the button state via a special/global function would be great. Additional Benefit: unused buttons could be also misused as f.e. a flashing indicator LED.

Describe the solution you'd like

Add the possibility to SET and TOGGLE the state of customizable function buttons via special/global functions.
How to deal with grouped buttons would probably need additional discussion.

Describe alternatives you've considered

No response

Additional context

No response

[pfeerick]

I would be strongly against this. We don't allow special functions to change the state of any other switches, and I don't think this should be any different. At best, maybe some additional logic added to customisable switches directly. But I'm not sure how that would look.

On a personal note, I have air mode only configured on the FC - and is only enabled when not in STAB or HORZ mode... I see no need for it to be manually controlled 🤷 I have it off in STAB mode primarily as I use that for takeoff and landing. Although I do need to play with BF 4.6s EzLanding mode, if that works as well as advertised, I may just leave AIR permanently on.

[3djc]

While I'm also strongly against it for physical switches where we would have a logical state not matching physical position, I'm actually in favor of that for customisable switches, because they have software controllable state indication, therefor the physical state (represented by led status) would keep matching logical state.

It would however still have to obey the switch setup: if you have a group of 3 switch that is always on for example, it would not allow to turn all off, or have 2 on. It would act as if you had pushed the button yourself, no less, but no more either.

On a side note, by putting your AIR and ANGLE in a group, you probably would achieve what you wanted

[pfeerick]

Probably not, as he would have ANGLE/HORZ/ACRO in a group so they are mutually exclusive, but AIR is another mode that can work in conjunction with any of those three. You'd need nested groups for that to work lol. I still do not beleive SF is the right mechanism, and that it should remain in the domain of customisable switches.

…

On Thu, 29 Aug 2024, 4:44 pm 3djc, ***@***.***> wrote: While I'm also strongly against it for physical switches where we would have a logical state not matching physical position, I'm actually in favor of that for customisable switches, because they have software controllable state indication, therefor the physical state (represented by led status) would keep matching logical state. It would however still have to obey the switch setup: if you have a group of 3 switch that is always on for example, it would not allow to turn all off, or have 2 on. It would act as if you had pushed the button yourself, no less, but no more either. On a side note, by putting your AIR and ANGLE in a group, you probably would achieve what you wanted — Reply to this email directly, view it on GitHub <#5487 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJ66KOCCONXTA7WOXPP723ZT27L7AVCNFSM6AAAAABNJOM5PCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJWHAZTCNBYGA> . You are receiving this because you commented.Message ID: ***@***.***>

[3djc]

Let me give you other usage exemple, that definitely would need SF:

• petrol powered plane, you want to control choke, but that it doesn't stay on for more than a minute
• you want to control your craft landing gears, but also that it retract those automatically above 60m

In those two scenario, a customisable switch with SF would be perfect, has it gives you visual feedback of the state, yet provide automation

[pfeerick]

No, it would only need to be done via a SF if you make it that way. Or are you saying it can't be a conditional set/reset option in the customisation screens section? Just because it is there, it would not that you don't get access to things like logical switches... that would like saying that mixes can't make use of logical switches 😆 Look back at what I said... I didn't say I am against programmatic control of the customisable switches... but of SF being be the mechanism to do so.

[3djc]

So basically we need to recreate the SF screen, but under custom switch section ???? I'm failing to see the logic of that. And it would require to allocate additional memory for a set of X alternate SF, that will need to be processed as part of SF handling.

I must not understand what you have in mind, because I cannot make sense of it, maybe you could draw a screen on how that would look like ?

[pfeerick]

Why exactly do you need to recreate the SF screen under customisable switches (CS from now on)? Don't you simply want a set or reset condition, for each CS , or CS group, which is only available depending on some rules about the CS setup. So perhaps a set/reset choice for each, when it is not in a group, which is either OFF, or specifies the trigger. If it is in a group, you then need to specify which CS in the group is to be selected, and what the condition for it to be selected is, etc.

One of the problems with it being under special functions, apart from it being yet another place to look to figure out how you configured things to work, rather than it all being in one place, is that you need to take into account whether a CS is a momentary, or part of a group that is supposed to be always on... and it makes no sense that this validation logic should be part of special functions?!

But before have any chance of figuring what the UI should/could look like... we first need to ascertain exactly what the requirements are... rather than just try to tack it onto existing structures... even if it is partly being processed as part of SF code, if that is where it makes sense to actually handle updating the CS.

For instance, off the top of my head I think these are the constraints:

• if a CS is a toggle, and not part of a group... it cannot be automated - user input cannot be overridden
• if a CS is 2POS, part of a group, without always on requirement, you want to be able to set a condition for each CS for it's on state
• if a CS is 2POS, part of a group, without always on requirement, you want to be able to set a condition for each CS for it's off state
• if a CS is 2POS, part of a group, with always on requirement, since one CS must always remain on, any attempt to turn them all off must be ignored, meaning you can only set an on condition for each CS

Am I missing any states/conditions/requirements?

How do we deal those CS rules if it is configured via SF UI, and not part of the CS UI? Plus, it really seems poor UX design, if you make changes to a CS/CS group which invalidates one of those rules, since now you need to go to special functions and edit it there when you realise it isn't working any more. And yes, I know this is possible to do in other parts of the UI, doesn't mean we should make the same mistakes here.

[3djc]

"if a CS is a toggle, and not part of a group... it cannot be automated - user input cannot be overridden"

Thats probably where it would be most usefull to be able to automate, see my examples above. In my view, you would be very simple: The SF would look like:

Trigger: whatever you want
Function: Push custom switch
V1: switch number (1 to 6 in current radios)

Thats all you need. What would happen is exactly what would happen if you manually pushed it. All you do is ask the radio to push that button for you when this conditions are matched

[TGS78]

"We don't allow special functions to change the state of any other switches, and I don't think this should be any different"

I agree, changing the status of physical switch would result in a mess, that's why I asked only for the customizable buttons.
Because you already can change the startup state of these special buttons, an exemption from this rule would imo not be an issue.

The simulated button press via SF like 3djc suggested would be best, then you as developer do not have to think about how to deal with button groups in your code. And in case somebody needs to SET a state to ON or OFF (not toggle) you can still achive by reading the current state and push again or not.

[3djc]

Maybe a simple V2 AND condition would come handy

[pfeerick]

"if a CS is a toggle, and not part of a group... it cannot be automated - user input cannot be overridden"

Thats probably where it would be most usefull to be able to automate, see my examples above. In my view, you would be very simple: The SF would look like:

Er... no, I think you forget JC - a toggle does does not latch, and can not be always on if it is not in a group, so is only active when you are actively pressing it 😆 🤦

I give up... if you want to make it so people can end up with broken configurations, and want to deal with the support issues, whatever. 🤷

[3djc]

I cannot understand how simulating button push could end up in broken configuration. A 'sf' push on a toggle without group will have it up for a short duration, like if you pushed it (not push and maintain)

[pfeerick]

And a SF off on a toggle that is on? Which can only be on while the user is holding it down? And a SF OFF to a cs that is a member of an always on group? And a SF ON/OFF to a cs which is now invalid as its configuration changed, but the SF hasn't been updated as you need to edit things in multiple places? I am trying to consider *all* of the possibilities first, not *just* the one use case of interest. If the UI allows you to configure invalid things, it (and the resulting configuration) are broken.

…

On Thu, 29 Aug 2024, 11:01 pm 3djc, ***@***.***> wrote: I cannot understand how simulating button push could end up in broken configuration. A 'sf' push on a toggle without group will have it up for a short duration, like if you pushed it (not push and maintain) — Reply to this email directly, view it on GitHub <#5487 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJ66KJAID6HUSYFC4XHDBLZT4LTFAVCNFSM6AAAAABNJOM5PCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJXGU4TMMJTGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[3djc]

I see where your concern is now, but I've not suggested you can set a CS on or off. As a reminder, the SF I'm proposing:

Trigger: whatever you want
Function: Push custom switch
V1: switch number (1 to 6 in current radios)
And I'm thinking about adding:
AND : and switch
Duration: time during which button will stay "pushed".

As for the SF been invalid, we have the same possibilities in so many case, reset a timer for example, everything around telem. Here it is actually better since the 6 buttons should still be there. If you push a button configured to none, then none will happen, it is not even invalid, just useless, but no different as if you would push said button with your finger