The original implementation of rainbow was heavilly platform dependent. This tries to change that. It removes the original integration from omnia-rainbow and turris1x-rainbot packages and introduces the new one in rainbow. The rainbow package requires custom backends that implement platform dependent operations.
The rainbow script tries to mimic the original rainbow applications but it also introduces the new possibilities. The most notable change is addition of priority levels and slots. Those are intended as a way for various applications to share control of LEDs without colliding with each other. This way we can for example use LEDs to signal running update or that there is notification for user present in web interface.
With this rainbow also now supports triggering based on activity. The activity sources are defined by kernel and rainbow can only set them.
One more addition are animations.
The primary consideration in rainbow design here was what it actually should do now when it is mostly expected to have LEDs support in the kernel. There is led init script and leds configuration options in system config provided by OpenWrt. What rainbow provides on top of that (over just runtime modification) are additional options (although we might want to expand led service instead) but primarily it approaches single RGB LED as the one LED instead of three LEDs (or one weird one). Thus it allows more direct and understandable control and configuration over just led triggers. The aim is to reduce hacks in the current version in the future and have rainbow as a shared interface to the LEDs for system programs.