Notification LEDs offer a great way to check for notification at a glance on the Moto G (2013) and Moto E. That being said, you may want greater control over them to check on charging status as well or even your eMMC (internal or external storage) activity. All of this is possible, assuming your device is already rooted.
XDA Recognized Contributor matmutant has written two detailed tutorials on how to control your device’s LEDs for various uses. As it turns out, both the Moto G and Moto E have two white LEDs each (note that both LEDs occupy the same hole; you can check matmutant’s blog post for detailed information on how he found this out). You can control them by writing to the files in the following directories:
- /sys/class/leds/white/: first LED, usually lights up when notifications are received. On the Moto G, this LED can be dimmed (by writing to the brightness file, as explained below).
- /sys/class/leds/charging/: second LED, available but never used by default by the system. Cannot be dimmed (at least not without modifying the HAL).
You’ll find two files of interest there:
- brightness: this file can be used to control the LED’s brightness and state (0 means “off”, anything higher (up to 255) indicates the brightness or simply means “on” if the LED can’t be dimmed).
- trigger: you can use several triggers to control the behavior of the LED. These depend on the device, but some interesting examples include mmc* to monitor the eMMC activity and battery-* to indicate the charging status.
LEDs for the Moto E
A useful example for this would be to use one LED to indicate the charging status, and the other for notifications. You can go even further by using an automation utility (e.g. Tasker) to change the LEDs’ state or triggers based on your own events.
It’s worth noting at this point that /sys/ is exported by the kernel on startup, in order to expose information about the hardware using sysfs; it can also be used to control devices via their attributes, as is the case here. (/sys/class/ offers symlinks to different classes of devices, using human readable names.) Because this is done at startup, the values you set will not persist after a reboot. Fortunately, you can use an init.d script so that your changes are automatically applied on startup. A short tutorial on how to do that is also provided. If your ROM doesn’t support init.d, then you’ll have to use an automation tool instead to run the necessary commands after startup.
For more detailed information on this, make sure to check the Moto G LEDs Custom Controls and Moto E LEDs Custom Controls threads, as well as matmutant’s blog posts about Controlling the Moto G LEDs
The post How to Control Both Moto G and Moto E LEDs appeared first on xda-developers.