EdgeTX
GX-12 no rgb leds with 2.11
Is there an existing issue for this problem?
- [x] I have searched the existing issues
What part of EdgeTX is the focus of this bug?
Transmitter firmware
Current Behavior
rgb leds option it is not even showing in global functions
Expected Behavior
in global functions rgbleds option should show up to control the leds
Steps To Reproduce
updated to factory firmware from radiomaster to 2.11.0 from edgetx buddy and downloaded sd card content from edgetx buddy. going to global functions assigning a switch and no longer seeing the rgbled option although they are present in scripts folder
Version
2.11.0
Transmitter
RadioMaster GX12
Operating System (OS)
Windows
OS Version
No response
Anything else?
No response
All leds are used by the system on GX12. In 2.11 we have introduced a protection for the leds used by the system that did not exist previously
@3djc can you tell what that means? Are you saying leds will be controlled from somewhere else from now?
The 6pos leds are reserved for 6pos switch (and are controlled by it), something similar for SA/SD leds
@3djc just checked, no where it is allowing me set leds from the radio not even the 6 pos switches, however the previously set led are working but I cannot configure them
Are you using gx-12 radio? I dont see any options under sa and sd switches. It only allows to to edit name and switch type. And for 6 pos switches i have it under custom sw but it does not allow me to change any led or any thing. It just shows switches
On Sun, May 4, 2025 at 10:42 AM 3djc @.***> wrote:
3djc left a comment (EdgeTX/edgetx#6197) https://github.com/EdgeTX/edgetx/issues/6197#issuecomment-2849256851
Ok, you need to click on the switch name itself to bring this window: Capture.d.ecran.2025-05-04.a.16.41.26.png (view on web) https://github.com/user-attachments/assets/02597688-d686-4cec-82a2-9343d93188bb
— Reply to this email directly, view it on GitHub https://github.com/EdgeTX/edgetx/issues/6197#issuecomment-2849256851, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH6A4JOSOGNZILCMZ43D7P324YRNZAVCNFSM6AAAAAB4MQBJHGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNBZGI2TMOBVGE . You are receiving this because you authored the thread.Message ID: @.***>
I got how to configure the 6 pos switched it is per model now. but dont find it for SA and SD switches
I think @philmoz has a proposal/something already done for that. Initial release did not allow to set color on SA/SD
I can confirm the issue. I wrote a bunch of little LUAs to control the LEDs of SA and SD. Named Lblue, Lred, Loff and so on for the left Button (SA), and same for the right SD button: Rblue, Rred, Roff. Placed in the "RGBLED" Folder. The Option "RGBLED" in Special Functions is not available anymore. I copied my Scripts to /SCRIPTS/FUNCTIONS, now I can see them using "LUA" in Special Functions. But they don't show any Effect. It was a very big advantage to have control over this RGB-Leds, as an example if you use the momentary button by Sticky Switch as a 2-Pos, to get feedback. Like "Armed" is Red, and "Disarm" is blue. Please bring back this Function, it is really important.
There is no plan to bring it back, but we will allow SA/SD colors to be configured like the 6pos ones (and it already allow to turn those to 2 pos without the need for any SF)
That's really a pity. For Copters I use 3 colors for SA: Blue for Disarm, Red for Arm, and Yellow for a pending Disarm. When the FC is armed, and you press SA, then it becomes Yellow to show a disarm will happen once throttle is zero. If this happens, and the disarm occured, SA becomes blue again. I am not sure if this is possible in the future? This option was really nice. Not possible to have both? Either controlled in the planned way, or fully by LUA?
Maybe in the future, unsure, I would like an option to say this led can be controlled by lua, but then it pushes a lot of complexity toward users. Or maybe a general option to say all leds are controlled by lua only that disables all system led control
Just went back to 2.10 - this is not useful at all. I also miss the possibility to have a delayed switch. Like: SA is off (Blue). Short press activates the Haptic to announce something will happen if you press longer. After keeping SA pressed for 2 Seconds, it switches something on, and becomes Red. To switch back off, same procedure. Short press only warns by Haptic, long press then does something and indicates this by different switch color. For this, a manual choosen color of the Switch is absolutely a need. That´s how I arm/disarm my FixedWings, where a 2sec delay is ok. Taking the possibility to control the RGBs (at least of SA and SB) by LUA is a serious step back. But yes, it requires some users knowlede to use it in a proper way. Would be great to disable System LED control for the 6-Pos Switch and/or for SA/SB. In best case separated :-)
I strongly agree, which is why I suggested an addition option is somehow needed, whereby you can specify Lua is controlling a customisable switch. As this clearly needs to change, as we have gone one step forwards, and ten steps back, severely neutering the benefits of RGB LEDs for customisable switches, and LEDs generally for customisable switches. But it is more than just the LEDs, it is also how the switch behaves.
On Mon, 5 May 2025, 5:47 am FPVZaphod, @.***> wrote:
FPVZaphod left a comment (EdgeTX/edgetx#6197) https://github.com/EdgeTX/edgetx/issues/6197#issuecomment-2849385866
Just went back to 2.10 - this is not useful at all. I also miss the possibility to have a delayed switch. Like: SA is off (Blue). Short press activates the Haptic to announce something will happen if you press longer. After keeping SA pressed for 2 Seconds, it switches something on, and becomes Red. To switch back off, same procedure. Short press only warns by Haptic, long press then does something and indicates this by different switch color. For this, a manual choosen color of the Switch is absolutely a need. Taking the possibility to control the RGBs (at least of SA and SB) by LUA is a serious step back.
— Reply to this email directly, view it on GitHub https://github.com/EdgeTX/edgetx/issues/6197#issuecomment-2849385866, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJ66KLMJOE6SJXE4MPPF3D24ZVFDAVCNFSM6AAAAAB4MQBJHGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNBZGM4DKOBWGY . You are receiving this because you are subscribed to this thread.Message ID: @.***>
There is also at least one YT video showing how to set the GX12 Led colors (Painless360) - so this is going to be an ongoing support issue.
I would recommend reverting the change that breaks the Lua scripts - I was never happy with this change (removing user choice is not in keeping with the EdgeTx philosophy IMO).
Maybe in the future, unsure, I would like an option to say this led can be controlled by lua, but then it pushes a lot of complexity toward users.
And? Is that really a problem? If the users want that, they agree to the complexity. End of story.
Or maybe a general option to say all leds are controlled by lua only that disables all system led control
That could be a nice intermediate option, as if users just want the bling, they can have it. Might even be model specific rather than radio specific... i.e. you could have an option under customisable switches to disable them completely, and then pick a lua script to animate the leds.
There is also at least one YT video showing how to set the GX12 Led colors (Painless360) - so this is going to be an ongoing support issue.
This is always going to be an issue, and if we make reactive and rash decisions based on what youtubers do with pre-release firmware (even Lee), we'll really screw things up.
I would recommend reverting the change that breaks the Lua scripts - I was never happy with this change (removing user choice is not in keeping with the EdgeTx philosophy IMO).
I only partly agree with this... we need do things differently, but not just roll that back. User choice is indeed a key part of EdgeTX, but not at the expense of inconsident UI/UX and potentially dangerous situations. Just reverting the change is reactive and short-sighted in my view. We should instead be planning through exactly what the configuration paths should be, and making sure that Lua does not override UI/UX, but instead compliment it. i.e. If you have a customisable switch that sets a on and off colour, I don't think it is right that Lua can just come along and change it. Is the switch on or off now?
And it is not valid to say "but the user chose to do that"... because people copy 'n paste and download random stuff all the time, and then say "but why doesn't it work now". This is why there needs to be a way of indicating "hey, Lua/SF did that/is in control here now... blame the Lua script if something isn't working". i.e. this is why the Push CS SF exists... that makes it quite clear that the SF is responsible for changing the CS state (when configured). But I think this is something we will have to discuss internally, and probably work through to ensure all the bases are covered.
We'll have to agree to disagree.
In my view functionality was provided that, has a legitimate use case, is being used, and has been documented. A change was made that broke that functionality.
The correct response is to revert the breaking change and then work out if a better solution is needed.
And, IMO, it was the change that caused this that was 'reactive' and not properly thought through.
The correct response is to revert the breaking change
Which then brings back the bug(s?) that this was also responsible for fixing. So is not the correct response. What we still need is the next step, re-introducing that capability, but without bugs.
The only bug I am aware of was the led's flickering for SA and SD. I had already provided a solution for this; but it was rejected in favour of breaking functionality.
For me the proper solution is certainly not to let LUA fight with custom switches settings or try to arbitrate that battle.
You are modeler ? Let the UI choices handle the colors of the functional leds, you can still download LUA for cosmetics leds and use those without having to worry about led number of which led is what.
You are a programmer ? Disable functional led control by Etx completely (with a to be added radio wide settings), and do it yourself
It seems 2.10 (GX12-Version) had something permanently updating the 6-Pos Switch LEDs. So overwriting it by LUA caused violent flickering. Would it be possible to stop this permanent update, and only do it on demand (when one of this buttons is pressed), and allow the LUA scripts again? Then it would be possible to configure the ON-Color and the OFF-Color both to 0/0/0 (no light on) and do all by yourself via LUA. Or you configure them to the desired On/Off-colors and do by system control. Even better, add the option "---" instead of a color, so the system simply doesn't send any command to the button led. So for each On/Off of each butten the Values for R/G/B plus "nothing".
Does the hardware require a regular update of LED status? If not, then adding a "---" option seems like the best option. This clears the way for a LUA script. That said, I understand the need for a system-defined way to set the switch colors as default. While I understand the desire for maximum programmability, I don't want EdgeTX to become the Emacs of transmitters: the seasoned pros can talk all they want about superior functionality, but it still means declining adoption if it's beginner-hostile. In my opinion, the need for a standard system-menu method of setting colors is much higher than LUA script support. Having a "---" option will be a decent compromise, but it does mean two paths of setting the LEDs that will need to be tested.
Did the old method of LED lighting make it to this repository? I know that the current 2.10.6 release is not compatible with GX12, and the upcoming 2.11.0 uses the new method. Is the source code for the old method reachable for reference?
We violently agree, which is why I'm proposing a simple choice radio wide, saying leds are mine. There is a lot of extra complexity to have a per led choice, like the number of leds you can control would change, so the index leds would change depending on settings, unnecessary complications. Remember that gx12 is only one of the radio with rgb, most having a mixture of functional and cosmetic leds. So most users need to be able to download a "ambiance" lua that works on all radio and won't break their functional leds. Other are more advanced and want to manage leds themselves
Does the hardware require a regular update of LED status?
It seems not, as the SA and SD Buttons are (where) easy to change by LUA. Looks like they are just a chain of ws2812 LEDs?
