D365 / Power Platform blog

Home » Azure » Having fun with DevOps, Microsoft flow, and LIFX bulb

After seeing how creative people are with their smart homes and light bulbs, I started exploring this area myself. After buying a light bulb from LIFX (Link at bottom of the post) I started playing with the API and added it to some of my codes to see what funny and smart I could do with this light bulb.

While playing around with this for a week I got an idea to integrate this with Microsoft Flow to get the light bulb to turn on and have a behavior based on the triggers we have available in Microsoft Flow.

The idea

I am a developer working through work items in Azure DevOps and more specified boards (where I have work items committed for each sprint). I need a creative way of getting notified if my work item got declined or approved by QA. As a result of the pandemic we are living in, I’m working from home and don’t sit next to QA at the office. At the same time, I want a more interactive way of getting notified when my work item gets approved/declined. So as of this idea, I want the light bulb to turn green if a work item owned by me gets moved into the “Closed” column. If the work item gets moved back to “Active” it needs to turn red.

The creation

I started off by navigating to LIFX’s homepage for creating an access token (www.cloud.lifx.com). When you could create a new token, you are only able to see the token once, so remember to copy the key.

Next up I went to Postman to test the API with my newly generated token. In LIFX’s documentation, you have several APIs you could call, based on what type of behavior you want the light bulb to have. For my idea, I want to use the “breathe” behavior which makes a pulsing effect and will catch my attention.

Now the time had come to create a Flow that will trigger when a work item is either moved to “Active” or “Closed”.

So to start at the top, you will choose where to find the work items from and which uses the work item has to be assigned to, for the flow to be triggered. Then under “Closed State” I’ve chosen “Closed” and “Active” because I want the flow to be triggered not only when the work item is “Closed”. (The trigger event is originally a pre-made trigger event by Microsoft but with some customizations).

Next, I added a condition tile, to check if “State” = “Closed” and a check which user made the changes to the “State”. The reason why I added a condition check on the “Changed By” is that I only want the flow to trigger when the QA user makes the changes. (Otherwise, the flow would trigger when I add the work item into “Active” and start working. (Which could end up being a disco in my office).

If the condition is true, then we send a post request using the HTTP tile, to the light bulb (using the details covered in the setup for postman). If the condition is false, we go through another condition to check if the “State” = “Active” and the user who made the changes is QA. This condition will then make the light bulb turn red because the QA declined our work item.

The result

Relevant url’s




Share this post

Scroll to Top