Hi In my device it has an RGB system LED that indicates status and it has no other leds on the system not even lan led's and trying to mimic the led function of the original device or better it.
It seems I can't really just drive the led's as individual gpio using the /base-files/etc/board.d/01_leds file as it looks as it just stitches a led to a function.
Is there a means of implementing logic in a stock way? as at the moment it seems the led's would mix not showing the intended colors to indicate function.
Is there some board specific logic somewhere I can control or implement LED logic this or is this a per device script up to the user to sort themselves?
It very much depends on whether there are LEDs listed under /sys/class/leds/. You won't get very far attaching anything except very basic indicators to GPIO-driven LEDs. (That being said, you don't really tell us what the "led function of the original device", or even what the "original device" is.)
It usually starts and ends with attaching triggers to DTS-defined LEDs to be driven by the kernel.
The device is a new target I'm trying to implement the TP-link x80-5g.
There is a list of the status led's below from a oem perspective but it is configurable with Alexa skill in the phone app where one can customize it somewhat.
Yellow pulse Deco is resetting
Yellow solid Deco is starting up
Blue pulse Deco is ready for setup
Blue solid Deco is setting up
White pulse Deco is upgrading firmware
White solid Deco is registered and all is well
Red pulse Deco is disconnected from main Deco
Red solid Deco has an issue
Yes but this is a script that is not implemented unless a user implements it themselves so it seems.
if I implement the board as it is basically the rgb led would be uselless without a script or something or am I missing something?
can I implement logic in the dts with a timer and shift register or something so only one led functions at a time?
I may be dense, but I fail to see how any of that maps in any way to regular OpenWrt operation. The parts of that list that aren't hardcoded in the startup sequence seem to indicate operations specific to the "Deco" firmware.
Most don't apply. OpenWrt has no concept about "ready for setup", "all is well", "has an issue" or "is disconnected from main Deco" (whatever that means, I assume some sort of mesh).
What remains is basic indication of "reset" (a pre-boot condition that is certainly coming from the device itself), "startup" and "upgrade", the latter two indicated by OpenWrt in the same manner across all devices on the "system" LED.
The point is that at the moment the device only has one RGB led all the TP-Llink Deco line of products only have a single status led on them there are a few other devices with RGB led's also and they can't really be utilized in OpenWrt it is geared around one function one led.
I'd like to utilize it in a similar to the stock setup does, and I can't really do that it seems.
I envisioned something like this :
Yellow pulse device is booting
Yellow solid device is ready
Blue pulse wps inactive
Blue solid wps active
White pulse wan disconnected
White solid wan connected
Red pulse lte disconected
Red solid lte connected
green pulse 2.4 g inactive
green solid 2.4g active
magenta pulse 5g inactive
magenta solid 5g active
cyan pulse fan inactive
cyan solid fan active
RGB LEDs are usually three separate LEDs, none of which are yellow, yellow is a combination of two LEDs. IIRC OpenWrt uses the LED it finds at /sys/class/leds/*:power to indicate bootup. So you'll probably not get "yellow" to indicate startup.
Same here. While OpenWrt can use LEDs to indicate connectivity of an interface by default, it does so using a singular LED. "White" is a combination of all three LEDs.
As for the rest, you are of course free to implement that as a script. I'm pretty sure such a script will never go into OpenWrt, though, since your usecase is very much individual to yourself.
(Also, if "white solid", i.e. all three LEDs permanently on, means "wan connected", how do you imagine to ever indicate anything else on that RGB LED?)
I don't know if bring up the idea to extend logic to control the I/O though formal scripts that can be hot patched per device or something during the build process?
my device also has external lte antennas with a gpio switch there is no formal way to control that either.
My idea was to setup some logic to roll through each state with a 7 to 1 mux and stay on each of the 7 possible color states for 2-3 seconds and skip ones not in use or inactive there is a few ways of doing it.
Green would be the most boring and standard indicator, some router firmware powers on with one LED so that support can diagnose hard brick vs soft brick. You need to film bootup to see if that is the case.