Customer Data Driven Light Shows
Smart lights have been maturing into a usable technology for a few years now. I was about to pull the trigger on a system for home when some redecorating started in the Zingle nerd room. I had ideas.
NPS Scores and Slack
Following the lead of just about every other tech company in 2014, we started using Slack at Zingle. Aside from my favorite purpose of spamming parrot emojis, we started using Slack to great effect for tracking customer satisfaction in 2016.
The big push from the product team in 2016 was to better track our customer usage and garner feedback. We installed the Intercom chat widget on our customer dashboard and began collecting data through Segment on nearly every mouse click and mobile touch.
We also began collecting zero to ten Net Promoter Scores from our web users with Wootric. This data was valuable, but the real magic happened when we integrated these ratings and comments live into Slack.
Let There Be (Blinky) Light
As we put up new white boards, band posters, and faux brick around the engineering room, we decided to ditch the fluorescent tubes for some pendant lights. I successfully pushed to equip them with Philips Hue smart light bulbs, controlled by a wifi hub with an open, RESTful API. I had a new toy. 🕹 💡
Light Control via Slack
It was simple enough to find an extensible Slack bot framework and an unofficial Python Hue SDK. After an afternoon setting up a quick Linode instance with a Python environment and writing scary regular expressions, our development team was issuing commands to our friendly neighborhood lightbot (Github project.)
Dance Party
The next logical step was to make the lights frolic a bit. The top image in this article showed a light having a dance party. This sets each light to a random color using 0.0–1.0 XY chromaticity values and setting the ‘alert’ effect that makes the light blink once.
NPS Scores, Whirling, Wig-wagging, and Pulsing
After some more experimentation, I came up with three effects to use in response to NPS scores from the Wootric bot.
I debated doing nothing at all for zero scores; we don’t exactly want to celebrate zeroes.
Some Technical Details Regarding Animations on the Hue Bridge
I have used some apps that start animations on Hue lights that continue to work even after the app is closed. It took some reverse engineering on my end to figure out how to do multi-stage animations directly on the hub. Here is some info on what I found.
Schedules
Schedules are most basically used for things like, “Turn the lights on every night at sunset.” Each schedule has a repeat count, a time interval, and a single command. There are two problems using just schedules for an animation.
- Each schedule can only have one command. That means one status change for one light or, at most, one light group. You cannot, say, turn one light on and one light off with the same schedule.
- It’s difficult to start two schedules on opposing intervals. You can delay before starting the second schedule, but that’s ugly and does not work as expected a full 100% of the time.
The wig-wag animation used for NPS nine scores is done with two schedules, started on a delay as explained above. This sometimes works incorrectly. It will soon be rewritten using rules with a generic status sensor now that I know better. 🙂
Rules
Rules can have one or more trigger conditions, and, most importantly, can have up to eight actions. These actions can be disabling and enabling schedules. They can also manipulate sensors:
Sensors
It is possible to manually create a sensor of type CLIPGenericStatus that can have its integer value changed via PUT requests, including PUT requests that come from a rule or a schedule (or another device entirely.) Rules can use the sensor status as a condition.
Putting All Three Together
I used a combination of one sensor, three rules, and three schedules to create an animation that would cycle between two states a few times and then finish. One schedule sets the sensor value to 1, the other schedule sets it to 2. There is a rule when the sensor value changes to 1to disable the “going to 1” schedule and enable the “going to 2” schedule. Each of those rules also changes the lights as appropriate for that stage.
The third schedule and rule is for cleanup, disabling and removing all schedules and sensors.
One Gotcha Regarding REST Paths in Rules and Schedules
The biggest problem I hit getting the above rule/schedule/sensor system working was a peculiarity of paths in the Hue Bridge API. It turns out that PUT paths in rules are of the form /lights/1/state, while PUT paths in schedules are of the form /api/your-user-name/lights/1/state. That one was not fun to find since an error in a schedule will not be thrown back at you when you create the schedule; it happens when the schedule actually fires.
The Code
The rtmbot Slack bot plugin is available in its entirety on Github with documentation.
As much as I would love to be a full time office light show engineer, there is likely more value in continuing to improve the Zingle iOS app than having automatic light shows for every possible office occasion, so it’s back to the app mines #fornow.
