Change the state of customizable buttons via special functions #5487
Comments
|
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. |
|
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 |
|
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:
***@***.***>
|
|
Let me give you other usage exemple, that definitely would need SF:
In those two scenario, a customisable switch with SF would be perfect, has it gives you visual feedback of the state, yet provide automation |
|
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. |
|
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 ? |
|
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:
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. |
|
"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 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 |
|
"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. 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. |
|
Maybe a simple V2 AND condition would come handy |
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. 🤷 |
|
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) |
|
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:
***@***.***>
|
|
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 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 |
Neither have I... At no point have I said anything about CS configuration being changed by the SF (as that is something that would be for a Lua script to do, as part of mutel setup script, perhaps)... I'm have solely been taking about the input to a CS.
Which is why I have being saying "we already know things can break there that way, is there not a better way?" Since normally we learn from mistakes, rather than continue to repeat them... Or so I'm told 🤪😂 |
|
As said, there is no repeating mistakes as the 6 switches are there (and cannot be configured out), so how could it be invalid ? |
|
The topic "Change the state of customizable buttons via special functions" sound some kind of crazy dangerous to me. Actually we were able to solve all of the needed control functions by the given possibility of SF and so on. Just my 5 cents. |
|
@Gerold68 do you own a radio with customisable switches (only Jumper does those currently) ? If you don’t, you probably can’t really grasp what those are, because as I said initially, I fully agree with you on physical switches, but those CS are in essence nearly a full software thing |
|
@3djc looking at my T15, you are right. So, if it is all about theses buttons I am with you. Maybe the missing haptic feedback is the reason that I do not use this buttons (also the ones of the TX16S) for things like flight-modes. |
~~ Er... can you say that again? I have no idea at all what you mean there... and I don't think you meant to contradict yourself from one reply to the next 🤣 ~~ edit: ok, bear with me for a minute, I think I might know what you meant Sidenote... maybe add a feedback option - none, beep, haptic - to the CS page/section - which applies to all CS buttons? |
|
Yeah, was thinking the same about your sidenote. What I was trying to say here (and the one earlier) is that the configuration of the custom switches is irrelevant for the SF I have in mind, The function is PUSH BUTTON, and the parameter is 1 to 6, matching the physical button. So the SF will never be invalid as the 6 physical buttons will always be there; no matter how CS are configured. In practice, where we look "is button SW1 pressed", it would become "is button SW1 pressed OR is SF PUSH BUTTON 1 active" |
|
Ok, I'm with you now there... so because you are not setting or toggling the state of the CS, but simply mimicking user input of a physical press, all the existing CS logic safeguards will take care of things like the grouping, and always on state. And I presume any attempt by the SF to toggle the button while the user is pressing it get rejected also? Or were you thinking of cheating and using the AND to avoid having to do that? 😇 i.e. I'm now curious as a scenario where that condition would be used in the context of a SF like this... |
|
Well, if you push and the SF push at the same time, result is the same, it is pushed (so cheating with the OR ( "is button SW1 pressed OR is SF PUSH BUTTON 1 active"), yeah). Could you elaborate on your "I'm curious" statement, I'm sorry I do not understand what you mean there |
|
Yeah, I was just hoping it wasn't going to cause something like it being turned of (since in the case of an always on toggle, each press toggles it's state)... while you are pressing it... You said you were thinking of adding "AND switch"... so how would it be used in conjunction with this? i.e. you've already triggered this SF to be called, so why the AND SW? Use case? I'm assuming you have something in mind already? |
|
ok understood. For the AND switch, i was thinking about checking current state (something like if this switch logical state is on, the push it to do a OFF only), but that would be subject to config changes. I could remove it, but then you would use a LS as a trigger, and that LS would be subject to config changes (but that config change dilemma almost cannot be solved by software only) |
|
I'll have to think about that AND switch a bit more... I think it may have a benefit... not sure yet. Whatever you do it is going to be subject to config changes... hence why I was saying the UI should be... you know... in the one place... rather than scattered across 3 or more screens... 🤣 i.e. you could quite easily reduce it down to just a single choice field for each CS row... as you would would really only need the trigger field - know the CS from the row, and if set to none, it's disabled. But even doing it that way, you may still need to make changes on the inputs/mixes/LS page if you were to say re-order the CS... so doing it via a SF means the makes the CS page/section doesn't get any more cluttered 🤷 |
|
Well you can have as many SF lines as you want pushing the same buttons not only one, and I think duration will be cool too |
|
Indeed, especially if that CS directly controls a channel... i.e. if were say a beeper channel, or control that only moves when the button is held down... etc. |
|
short offtopic: should the simulator in companion 2.10.3 support the customizable switches? |
|
Not yet |
|
Please have a look at #5497, this seems to be running ok in the testing i've done on radio. For now (and likely for said PR), I have limited to basic functionality (ie no AND or Duration) |
|
Most of the instances I can think of that would require the AND would probably involve using a LS as the trigger anyway, but if gonna leave duration out for now, I think it will be worth adding the AND still as a followup... i.e. you could have the trigger being a timer LS, but the button push only allowed if a "switch" in a given position... i.e. I think it may become useful for the "push CS" SF with multi-stage/chain logic, or being able to use a single LS to trigger multiple things, without needing secondary LS lines. |
|
AND is probably a pain as I don't want to change cfn struct. I think i I can manage the following duration behavior:
So lets say your switch is a toggle switch, and you set duration to 2s
If that behaviors makes sense, I'll code that |
|
Aw... now you're just teasing me... AND but not AND? 🤣 Yeah, that makes perfect sense :) |
Is there an existing issue for this feature request?
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
The text was updated successfully, but these errors were encountered: