Visual smart home notifications with WLED

A smart home sometimes needs to notify its users of certain events or states. Instead of installing dedicated notification devices, why not use the smart lights which are present in most smart homes anyway? This turned out to be much more difficult than it sounds. However, I found that WLED, a great firmware for LED light strip controllers, offers an interface almost predestined to implement visual notification effects, and so I wrote and published a Node-RED node which does exactly that. Visual notification effects, simple to use, without side effects. It’s open source and now available on GitHub, npm, and the Node-RED library. Watch the demo video below and read on for more details.

Motivation

I often forgot to take out the laundry when the washing machine finished, so I installed an automation which sends a notification to my phone. However, the phone is mostly muted, I seldom look at it, and so this didn’t really solve the problem. So how can the home notify me that my attention is required? I don’t (want to) use smart speakers or displays, and didn’t want to buy additional hardware either. There are already lots of smart lights across the home, and they are just waiting to unfold their true potential ;) The requirement is very simple: Upon a trigger, display a short light pattern in a specific color, then continue with whatever it did before. Just like the color notification LEDs that some Android smartphones used to have. For example, blink three times in red when the laundry is done, or more generically, remind me to check the phone for notifications and read the details.

Challenges

I mostly use Ikea Tradfri and Philips Hue Zigbee bulbs, and so I first looked into these. They come with built-in effects defined by the Zigbee specification, e.g., Blink and Breathe, and I assume other brands will thus offer them too. However, they turned out to not be well suited for notifications for the following reasons:

• Inconsistent animation: The specification only gives examples of how the effects should look like, and so they are of course implemented differently by different brands. This inconsistency leads to bad user experience.
• No power state handling: The effects turn the lights on if they are off, but not off again afterward. So this needs to be handled additionally by the home automation software to restore the light state from before the effect. Unfortunately, there is no event what tells when an effect has finished, so the effect durations need to be manually measured and hard-coded. This leads to a huge maintenance overhead.
• Inconsistent command handling during effect: When a command is received while an effect is ongoing, e.g. because a user or automation switches the power state or changes color or brightness, bulbs behave differently. For example, Hue applies it with a delay and might stop the effect, Tradfri immediately applies it and stops the effect. Ideally, no commands should be sent during an effect, which is a big challenge for automation that requires lots of implementation effort.
• No color change: Due to the command handling mentioned above, it is not possible to change the color during an animation. Some brands might not even allow setting the color of some effects, because the specification suggests specific colors for some effects (e.g., the Okay effect should be green).
• No animation control: Speed cannot be controlled at all, intensity might be controlled by setting the brightness beforehand, but that again depends on the implementation. So a single effect, e.g. Blink, cannot be customized for different types of notifications.

A way to work around these issues is implementing custom effects directly in the home automation platform by sending a sequence of on/off/brightness/color commands with transition times to form smoothly animating effects. While this theoretically allows an infinite range of different effects, it is still severely challenged:

•  Zigbee network congestion: Sending lots of commands in succession, maybe even multiple times to multiple lamps, easily results in an overload of the Zigbee network, which not only interferes with the effect but also other devices on the network. Not an issue for Wifi bulbs.
• State handling: Similar problem to the approach above. The home automation platform needs to store the light state from before the effect, execute the effect, then apply the state from before, and additionally – which is the tricky part – prevent intermediate commands from negatively affecting the ongoing effect, while at the same time not losing requested changes to retain a nice user experience. Lots of edge cases are waiting to be handled.

To avoid this, some lights could of course be dedicated to only showing notifications, but that’s a waste of resources.

Solution

I also use the great WLED firmware for LED light strips, and studying its documentation I found the perfect solution: The UDP Realtime control protocol, which is also used by Ambilight software like Hyperion and Prismatik. This protocol allows controlling the individual LEDs and thus allows to implement any kind of visual effect, which of course also covers notification effects. While active, it simply overrides the internal configuration, with the single exception of the overall brightness setting. Whatever the WLED light is doing, whatever commands it receives from users or automations, it applies them, but they do not become visible as long as the notification effect is active. If the notification effect turns on the light, it’s automatically turned off afterward. If a user explicitly turns it on in between, it stays on. So no command is lost, and no state handling is necessary at all. It just works as expected.

Even though state handling does not need to be implemented, now the effects need to be. However, this is the cleaner approach as it is simple, results in a consistent experience across WLED lights, and it doesn’t introduce UX-inhibiting edge cases. I use Home Assistant (written in Python) but decided to implement this as a Node-RED node in TypeScript, which I’m much better at. Also, I hope it’s more universally useable, although I’m aware of the increased usage barrier for home automation.

The initial version comes with one effect called “blink” whose appearance can be configured in terms of speed (effectFrequency, i.e., how long one full blink takes), duration (effectCycles, i.e., how often the blink is repeated), and of course its color (effectColor), which allows for many different looking notifications.

Usage

Simply install it in your Node-RED instance from npm or the Node-RED library as outlined in the documentation, and follow the examples to trigger notifications from Home Assistant. The configuration of the node is super simple and only requires the hostname or IP address of a WLED instance to get started. Contributions are welcome, and there’s a discussion about usage with Home Assistant.