How To: Control your LIFX Lights from Twitch Chat using IFTTT

Today my girlfriend HelloMissPotter (who streams a variety of games on Twitch) was sent a few LIFX Bulbs and a ZStrip from LIFX for her to show off to her followers. I thought it would be cool for her stream viewers to be able to change the color of the lights behind her as she streamed.

A bit of background for my usual readers: on Twitch, viewers type into a chat window, and often streamers enable commands to do cool stuff, such as make song requests, find out how long the streamer has been streaming for, and much more. This usually takes the form of !command.

So, here’s what you’ll need.

  1. A Twitch account

  2. A Nightbot account (Sign in with your Twitch account)

  3. An IFTTT account

  4. A LIFX Account (make this on the mobile app when you set up the bulbs)

  5. A LIFX Bulb or ZStrip

Part One: Setting up IFTTT

First up, we want to go into IFTTT and create a new applet. We want to search and find Webhook. (This is a fancy term for website that triggers things).

Screen Shot 2019-06-22 at 5.39.10 PM.png

Then choose Receive a web request

Screen Shot 2019-06-22 at 5.39.20 PM.png

Since you can use this as many times as you want in IFTTT, you have to enter a unique name. I chose lifx_color, but you can call it whatever you like, such as your dogs name. Remember it for later.

Screen Shot 2019-06-22 at 5.39.31 PM.png

So, that’s the “If This” part done. In this case, we’ve chosen “if webhook with the event name lifx_color”. Now it’s time for the “Then That” part. In our case, its interacting with a LIFX bulb, so go ahead and search and find that.

Screen Shot 2019-06-22 at 5.39.42 PM.png

Here you’ll need to sign into your LIFX account. Once that is done, you’ll see the menu of possible actions. For this, we will choose Change color of lights, but you could explore the other options later.

Screen Shot 2019-06-22 at 6.20.22 PM.png

In the setup, choose your light. This will take a moment to load as IFTTT asks LIFX for a list of your lights.

Now, leave most unchanged, and scroll to the bottom of the card.

Screen Shot 2019-06-22 at 6.20.55 PM.png

In the Advanced options field type “color: “ (no u), then click on the Add Ingredient button. Choose Value1. Then type a semicolon to close off the small bit of code. We’ll populate value1 with a color value later on.

Screen Shot 2019-06-22 at 6.21.27 PM.png

The final result should look like color: ;
(The underline and 1 are a browser plugin I have installed for spelling. Colour is the correct way to spell this in my part of the world.)

Screen Shot 2019-06-22 at 6.21.42 PM.png

Next up is to extract the Webhook URL from IFTTT for use later in Nightbot/Twitch.
Click Services

(I have been tinkering more than you might have…)

(I have been tinkering more than you might have…)

Click Webhooks

Screen Shot 2019-06-22 at 6.45.24 PM.png

Click Documentation and you’ll see this rather scary page. I’ve blacked out my keys so you don’t fiddle with my lights. Remember: with this, you’ve exposed to the whole world the ability to change your lights, but you need a rather long and obscure URL, so you’re probably safe.

In the first red box, enter the name of the webhook event you chose, remember we went with lifx_color above.
In the next, type ‘red’.
Now, the moment of truth, click Test It. In no more than 20 seconds, your lights should change to red.
(Hint: For LIFX, make sure the lights are not red, and the app is closed - they tend to fight for control).

Huzzah! You should be successful. If not, double check these instructions. Make sure the event names match, you chose Value1, and you typed the code correctly as per the screenshot.

Screen Shot 2019-06-22 at 6.45.52 PM.png

From here, you have a URL to use. However, to include the color, you need to add a bit to the end of it. And that is ?value1=red. (Or your colour of choice)

So, your full Webhook URL for NightBot/Twitch will be:
https://maker.ifttt.com/trigger/lifx_color/with/key/XXXXXXXXXXXXXXXX?value1=color


Part Two: Setting up NightBot

Next up, log into NightBot and navigate to Commands, Custom. Click + Add Command.


In here, choose a name for your command, I will use !color and my chat participants will type !color red, !color green … etc.

In the message field, we will use the urlfetch command, which basically access a website. Huzzah, early we set up a wehbook which is also a website, which when accessed changes our lights color! This hopefully should be starting to make sense.

Now we need to write the command and add a bit of code to pass the name of the color through. The command is:

$(urlfetch <url_from_earlier>?value1=$(querystring))

Notice how I substituted red for $(querystring), this means “put what the person typed after !color in here”. So if they type !color green, the result will be:
$(urlfetch <url_from_earlier>?value1=green))

Here’s a full screenshot to show my working command.

You can also change other settings like user level (Mod, Sub, You, Anyone etc) and Cooldown.

You can also change other settings like user level (Mod, Sub, You, Anyone etc) and Cooldown.

Next up, you need to add Nightbot to your twitch chat as a moderator, so in Nightbot’s Dashboard you need to click Join Channel, and follow the instructions provided to make Nightbot a moderator.

Now, head to your twitch chat and type the command and a color afterwards, and once again wait up to 20 seconds for the command to work and see your lights change!

In this post, we used red and green as color options, but you can also do: white, red, orange, yellow, cyan, green, blue, purple, or pink. You can read more here, where you can test even more.

For experts who know hex colors, you can also use these, even in your command, so !color ff0000 will set the red. Google is your friend for finding more options.

To suppress the output (eg “Congratulations! You've fired the lifx_color event”) from the API, you can put your own result such as “You changed my lights! (give it a sec…)” in another command, such as !colorresult, and the put !colorresult in the Alias field in the dialog above.

The Must-Follow Best Practices for Your Push Notifications

I’ve been working at Carnival.io a while now, and I’ve worked with many fortune 500 companies and startups to help them get set up with push notifications, and advising on their stragies for content. I’ve seen some great strategies, and I’ve seen some less great strategies. So in this post, I want to discuss what those great strategies, these best practices, are, and how you, a developer or marketer, can use them in your app.

Push is important. Push is probably as important or even more important than the rest of your app’s UX. Why?

71% of all app uninstalls are triggered by a push notification! 🚫📲 pic.twitter.com/T75cIpqTcl

— Chris Maddern (@chrismaddern) July 22, 2016

The good thing about notifications is they remind your users that your app is installed. A bad thing about notifications is they remind your users that your app is installed.

Get that touchpoint wrong, and you’ve lost that user, perhaps for life. Usage, feedback and revenue are all gone. Bad push practices can really harm your bottom line.

Secondly, it’s important to remember this simple truth:

Push Notifications go to people, not devices.

So here they are, my best practices for push notifications. These can be thought of as four pillars*:

  • When: Make them timely
  • Who: Make them relevant
  • What: Make them precise
  • Tech: Implement them correctly

When: Make them Timely

So my first tip is make push notifications timely. And what I mean by this is to try predict the right time to contact your user. Can you be more flexible than just when you want?

Respect Local Timezone

Respect their timezone. It might be easy to say “Oh it’s 6 PM here in New Zealand, lets send out a push to all commuters”, only to have your audience asleep in other parts of the world. If you have a sale or time-sensitive event, try send in the local timezone for the user. This will stagger the pushes over a window and might even reduce load on your server, if that’s required. A decent push service should give you this option.

Use Backoff Times

Sometimes you might want to send multiple pushes per day, or different services that interact with your app with to inform the user. Consider having a hard limit on this. The limit is relative to the value, but something like a 5–10 max per day would suit most applications. Chat apps for example, won’t have a limit, but 25 marketing messages in a day is probably (read: definitely) going to annoy your users. Consider developing internal priority for some notifications types over the other, perhaps favouring transactional pushes over generic.

People Sleep

While I imagine most people have their phones on do-not-disturb overnight, or at least on silent. But consider this: do you read all your notifications in the morning? Or do you clear them all immediately maybe after reading the important ones?

If you’re part of that overnight noise, you have a lower chance of standing out. Perhaps restrict the amount of pushes you send over night and send a summary style push in the morning, a few hours after waking up.

Who: Make them Relevant

The most important thing is to keep pushes relevant to the user.

Don’t send content for anyone

Ultimately the most valuable pushes are the pushes for me. Chats, deals based on history, or news alerts based on preferences. Don’t send me junk and certainly don’t something that can’t apply to me, for whatever reasons.

Personalize based on Journey

Many services offer personalization based on journey. This could be anything to do with the context of the app. What level of the game you’re on, which items you have in your cart, which news stories you’ve read. How long you’ve had the app installed, or how long it’s been since you’ve last used it. There’s a bunch of marketing and engagement automation possible based off just some basic data points — have a think what could be awesome inside your app!

Use Transactional Push

Alternatively, but not mutually exclusively with audience segmentation, is transactional push. These are the 1:1 pushes that go to a single users only. Perhaps their package is shipping, or they have a chat, or they’ve got a new like. These sorts of notifications are perfectly personalized by definition, but still must adhere to the other best practices, such as timeliness.

Personalize with Names

Use the persons name in a push, if you have it (and your users would remember where they gave it to you — don’t be creepy). For example: “Sam, we have new Doctor Who toys. Tap here”. Oh, and don’t ever say “click” if you’re on mobile. We don’t click there. /peeve

What: Make them Precise

The rule is simple here and there’s only one.

10 Words

Generally speaking, you have about 10 words to make your impact, so use precise language. Be obvious what you want. Make the call to action clear. “You have a new chat from Ben”. “A new deal for you. Tap here for more” “Sam sent you a friend request”. 10 words. Use them wisely.

The Tech: Implement Them Correctly

Notifications are quite tricky to implement, beyond the confusing mess of provisioning and certificates, but taking the time to do them right further helps with reducing the scary 71% stat above.

Ask for Permission Carefully

That alert box that pops up for notification permission may be one of the most important dialogs for your apps. Preempt it. Onboard your user well. Explain “Hey, here’s why we want to send you pushes and here’s what you get out of it. Are you in?” If you explain the value before you present that alert, you’ll get a much higher opt in rate. I’ve seen rates go from 20–30% opt jump to 70–90% with these techniques. This also applies to all other dialogs such as location or bluetooth as well. Explain the value, then ask the user to give up some privacy.

Use a 3rd Party Service

Don’t try do this yourself. 3rd party services are all relatively cheap for the value they provide. They worry about scaling, reliability and have good feature sets. Just use another service.

Preload Content

If your push drives a user to some in app content, you should really be pre-loading that with the available API first. This will delay the push by 20 seconds or so, but when they open the app, the UI should be ready to go. No one wants to be taken to a loading screen.

Duplicate Notifications Inside Your App

It’s almost too easy to clear notifications. You should always try and duplicate the notification content inside the app. This could be an activity log, a chat history or a notifications log. Make it so users can always re-read the alert text of a notification. I really like Tweetbot’s implementation of this.

Expose Settings

If your app has different scenarios in which to send push, let the user turn off hearing about certain situations. Additionally, You can also use the Notifications API on iOS or Android to see which alerts your user has enabled. For example; if they have turned off push, you can detect that and present the benefits again, and if they say yes, you can deep link them to the Settings app. This, over time, will slowly increase your opt in rate again.

Rich Push

In additions to notifications with Actions or Text Input, iOS 10 and Android forever lol brings Rich Push, which allows you to show a selection of Images, GIFs and Videos in your push previews. In iOS 10 you can even do arbitrary views too, and you can learn more about that here.

So that’s my best practices for Push Notifications. Remember:

  • Push Notifications go to people, not devices
  • Who. What. When. Get the Tech Right.
  • Get them right or your bottom line will suffer

And that’s my thoughts so far. If you have any best practices, please comment or tweet me — I’m @samjarman, I’d love to hear them!

Content also inspired from this Google IO talk by Pete LePage.