After getting the 3rd Smart Bulb, toggling them individually did no longer suffice and using openHab became a bit clunky for my taste. So I decided to put the RasPi to work as the Head of a little light automation. More precisely, I had 3 use cases:
- Steer my Tasmota-flashed light bulbs color in flexible groups (e.g. all at the same time or just the ones in the office, etc)
- Triggering predefined sequences of color changes (e.g. sunset/sunrise) and allowing ad-hoc additions to said sequence on the fly.
- Going through colors continuously, where each step is either determined by a certain logic or the result of some random distribution of colors.
In the image, the components of the solution are shown, together with the core interfaces. The purpose of each class in a bit more detail:
- Bulb Drivers/Shadow Bulbs: These classes serve a double purpose. First, they provide an abstraction of each actual bulb interface into a standardized one that receives commands from the other components. More precisely, the bulb drivers are all derived from the same abstract base class, such that bulbs with different interfaces can be addressed with the same interfaces. For instance, I still wrote a driver that communicated with the Tasmota-Interfaces of the bulbs through HTTP (for direct access if mqtt is down) and another one that used the mqtt-capabilities. The second purpose is, that the drivers are holding a state for the bulb. Most notably, the current Tasmota implementation does not readily allow access to the progress of a slow colour transition (which can be set to take up to 20 seconds). The Bulb Driver therefore acts as Shadow for the Bulb and provides the progress of a transition on request and sends out a MQTT-message once a final state is reached. To complete the shadow bulb the next extension will be to persist states and resend commands if a bulb is losing connectivity.
- Bulb Server: This simple HTTP-Server acts as a broadcast and proxy for bulb commands. It allows to forward HTTP-provided commands via MQTT to single bulbs or predefined (and overlapping) groups of bulbs, e.g. to allow setting the speed of color transitions for all bulbs simultaneously through HTTP-requests.
- Bulb Agent: This module holds asynchronous queues for state transitions of single or multiple bulbs at the same time. Whenever the queue is started, the agent will trigger transition to a new state of the bulbs in question, then wait for a predefined trigger (e.g. reaching the predefined state) to start the next, until the queue is empty. When the queue is empty and no "auto-fill generator" is activated, the agent will go to sleep. However, if such a generator function is set (e.g. a random generator provides a random hue as next target), then the queue is automatically re-filled until the agent is stopped. The starting/stopping and adding of steps or sequences to the queue as well as setting auto-fill generators is possible through another HTTP server.
- The User: As a simple interface to the two web servers (lightserver and lightagent), I use an app called "HTTP-Shortcuts". This app allows to trigger post request with configurable parameters, such as colors, numbers (for speed of transitions) or Boolean values (START/STOP).