What if you put together Work From Home and Home Automation? Well, removing the common denominator (HOME) would mean Work Automation (sic!). I want to tell you about a tiny hobby project I have had at home, still related to work of mine: Whenever an Azure alert is triggered, my Trådfri smart light from IKEA flashes for a couple of seconds.
Summary (if you want to skip the long story below): The solution is a tiny web application. The publicly accessible url, exposed using ngrok, is registered as a webhook in an Azure Alert. It’s on Github, you’re welcome to use it as you please 😎:
The github repo (linked above) is self-expaining, but here comes the story. I used the same setup for Azure Alerts as described in my previous blog post:
When I was done setting up an alert, I thought: besides a notification in a Teams channel, I thought: what if I could show the alert visually using some LED or similar? Then I thought about Home Automation and a Trådfri RGB bulb I’ve got. That’s the beauty of the mentioned equation: Work From Home and Home Automation. We can pick the best parts of it and combine to something unique.
Since I have a kit from IKEA containing a gateway, a remote, and an RGB lamp, I wanted to do something with that. Unfortunately I didn’t find any routines (Google Home), applets (IFTTT) or automations (Home app in iOS) that could do it.
Luckily, there is a way of controlling the Trådfri lights, best described in this tutorial:
As in this tutorial I also used a Raspberry Pi Zero W, and it went very well, except one thing: Trådfri team introduced a change for the security code, I needed an additional step that was missing, more on that later.
The flow from an Azure Alert to the flashing light.
The tutorial says: the world is your lobster. My “lobster” is a webhook that makes lights flash on an alert, so I needed to have a simple web server (http.server) and a tunnel to my network (ngrok). It was best to take one step at a time.
Step 1. Connect
First, I wanted to make sure I could have a simple web server that could host my webhook. I followed the advice from that tutorial and used http.server python module:
I opened that page, (192.168.0.193:8000), and I could see “hej”, time to go further.
Step 2. Connect World
Next step was to open up this “web app” for the world, to make it accessible from outside my local network. ngrok is the best solution for that. I followed that guide to install ngrok on my Raspberry Pi Zero W.
Next, I found the IP Address and the security code of the IKEA Trådfri Gateway, using my router:
Then I created a new preshared key (that’s the news I mentioned above). With just the security code, you will get 4.01 “Unauthorized” when you try to control the lights, as described:
When I knew I could have a simple webhook service, locally (step 1) and on the WWW (step 2), and that I could control the smart light I’ve got from IKEA using code running on my raspberry pi, then connecting everything was easy. I created a repo for that and you can see that it is a very simple one:
The main part is in the server.py. When it gets invoked, it calls the flash function. It uses os.system to call the libcoap-client and time.sleep for delay parts needed in the flash action. The configuration is parsed using configparser and the server is a simple http.server.
In the end I registered the ngrok endpoint in my Azure Alert Rule Action Group:
Then I triggered my test logic app that failed reliably 🙂
After 1-2 minutes my smart light started flash:
Success 🎯🎯🎯🎯
Words of caution and Tips
Security
http.server does not provide the right level of security, it’s most for prototyping. For this tiny hobby project I have, it’s exactly what I need. Don’t use it as it is for production.
Treat the security code your preshared key appropriately, you don’t want to be hacked.
Flashing lights reacting to alerts is cool, but think about the work-life balance. Don’t have it in your bedroom 😎.
Inspect ngrok from other computer
By default the ngrok web inspect interface is only available from localhost (127.0.0.1), make it available across your network by configuring ngrok:
The router can assign new ip addresses to your devices. Reserve the ip addresses of your raspberry pi and your IKEA Trådfri Gateway. It will make your life easier.
Start ngrok closer to you and in the background
EU is closer to me, but also running the background is nice when you only have one terminal:
# -region eu
# >/dev/null & for running in the background
~/ngrok http 192.168.0.193:8000 -region eu > /dev/null &
This is a game changer: rather than wait for an alert to be triggered, you can just Replay it over and over again while you mickle-muckle your python code locally.
Keep running your server after logout
You just need to to have “nohup” when you start your server, ngrok has already what’s needed: nohup python3 server.py. With that the server will run even when you log out or, your ssh connection disappears.
Next steps
I’d like to end this post also by saying: The world is your lobster. Try out the flashing lights on Azure Alerts, or why not to replace Azure Alerts with Exoprise Alarms, or some triggers in Power Automate, perhaps, when a new site has popped up 🙂 Or maybe you want to elaborate the flashing behaviour, why not to use Morse code to send a message? Or maybe color-code the different types of alarms/alerts. Once again, the world is your lobster 🦞(or oyster 🦪, well whatever) .
Azure Alerts are awesome for monitoring of solutions in Azure. If you are about to set up your first Alert Rules in Azure, then it’s a guide for you. Configuring alert rules can be quite intimidating at first, with all the options, metrics, evaluation times, etc.
Here is a very very simple setup that can serve as a teaser and help you get started with the Azure Alerts.
I’ll use Teams as an easy way to set up notifications.
The core solution (alert handler) will be an Azure Function, also because it’s fast and easy to set up.
A reliable failing resource
“Reliable failing”, huh? Yes, this oxymoron is the best description of what we are looking for: a resource in Azure that can fail reliably (“fail faster”), so that we can trigger our alerts while developing.
To do that an easy way, we’ll just create a logic app and let it fail all the time.
Run it, and you’ll see how it fails as intended.
The runs history of my failing logic app
When you’re done setting up the alerts, you can remove the failing logic app.
Communication channel
On the other end we need a reliable communication channel.
Let’s pick a channel in a team and create an incoming webhook. I call my webhook alert-hook. (Just to make it easier to follow this guide, it will appear here and there)
Why incoming webhook? Because it is easy to create and send messages to, and also with the right notifications on that channel and the Teams mobile you’ll get the smoothest way of setting up push notifications! Isn’t it great to get your custom alerts directly on you mobile in real time?
Just to make one step at a time, already try the incoming webhook by calling it using PowerShell. Verified small steps make it easier to troubleshoot future potential issues.
When you see the “hello world” from alert-hook in your Teams channel, then you’re ready to proceed with the next step.
Alert Handler
Now it’s time to set up the core of that solution – a handler that will receive alerts and pass it to the Teams channel.
Why do we need an Alert Handler? Well, because you can’t send the alerts directly to a Teams channel (or whatever communication channel you choose), they have different schemas. But also, an Alert Handler is an opportunity to make an alert more readable (e.g. by formatting it as an adaptive card), and even filtering out some alerts or parts of them (e.g. in some scenarios only Fired Events (not Resolved) are relevant for notifications).
For the sake of simplicity, let’s just create PowerShell Azure Function in the Azure Portal. Just choose everything latest (in my case it was PowerShell Core 7.0, Consumption Plan, West Europe). If you uncertain, check this post:
We need those 4 steps. I created a simplified diagram of the properties that you need have in mind:
Alert Rule Scope
When you click on “New alert rule”, the Scope will be already defined, it will point to the “Failing Resource”.
Alert Rule Condition
There are so many signals and possibilities. In this guide, just choose “Runs Failed” as a Signal.
In the Alert Logic, select “Greater than or equal”, 1; 5 minutes Granularity Period and 1 minute Frequency of Evaluation. No comment on them right now. Just do it.
When we’re done, re-visit this page and try other things, right now we just want to have an alert directly when our failing resource fails.
Action Group
Action Group is what gets triggered. It is billed and that’s why it is connected to a Resource Group (it might be another resource group, it does not need to be in the same place as our “Failing Resource”). Just create a new one:
Here is a simplified diagram of an action group:
Action Group Action – Webhook
There are a couple of options for Notifications and Actions to try out. Let’s focus on the Webhook in this guide. In the picture it is called GenericTolleAlertHook.
Copy the Uri from the your function (“Get function url”) and paste it into the Webhook URI.
Important: enable the common alert schema. That will save much of the pain.
Common Alert Schema
The payload in the alert may vary. To make it more predictable for parsing in the alert handler, we just need to enable the common schema, which will be crucial when we will extact and send some data to the Teams channel.
Action Group Bonus Tip: It might be not obvious when you set up it in the Azure Portal, but an alert rule can have 1 or multiple action groups (!). And the other way around: An action group can be used in multiple Alert Rules.
That makes it very flexible, we could create one generic Action Group that notifies Teams and reuse it across alert rules.
Alert Rule Details
The last step is to give the rule a name and description. Keep the Severity as it is right now.
Alert Handler Improvements
We need one more thing to call this guide complete: rather than saying Hello World, we need to have “Alert Fired” and what alert (alert rule name), to make it useful for real.
Let’s re-visit the alert-hook function and make some improvements. Remember the common alert schema? Make sure you enable it in the Alert Rule -> Action Group -> Action. When you do that you will get payloads like these I get:
We’ll use the alertRule and monitorCondition properties, that we’ll send in the body of the incoming webhook to Teams:
Let’s test and run. Copy and paste a sample alert payload (with the common alert schema). The links are above.
It should result in a new post in your Teams channel:
Further improvements
A simple alert rule is configured. Enjoy! Discover more and if you would like new challenges here are some tasks that you can try:
Adaptive Card
Try to update the payload in the Teams incoming webhook to make an adaptive card.
Fired vs. Resolved
It might be good to have different paths for Fired and Resolved. I find it confusing when Resolved Notifications appear alongside with Fired Events. It’s better to suppress the Resolved notifications, or at least format them differently, or maybe even post them as answers to an existing posts (the original Fired posts)?
Summary
Azure Alerts are great. Start with a simple set up, see it working and improve continously. An ActionGroup can be reused, you can have a generic Action Group. That makes it easy to set up new alert rules and and you only need to update the action in one place only. Of course, the alert rules can have their specific actions as well, you can connect more than one action group to an alert rule. Use Common Alert Schema to avoid parsing errors and to achieve a generic action group.
Teams is a good notifications destination, especially for your first Alert Rule, it’s easy to set up, does not mean additional costs and (best of all), you and your colleagues can enable notifications the destination channel (channel with your incoming webhook), that way you will be immediately notified when something fails in your Azure Applications, – both on Desktop and in your mobile! Good DevOps, isn’t it?
Recently I needed to add an Alert Me link on Pages. Alert Me is a well known SharePoint functionality for notifying users about changes in list or list items. It is availabe in OOB SharePoint as a command in Ribbon if you go to a list view:
When you click on this ribbon command, SharePoint opens a modal dialog and takes you to layouts page: SubNew.aspx. To open a modal dialog and load a page is not a rocket science. So a custom “Alert Me” link is doable.
As the first step I copied the html markup from the ribbon and adjusted it a little bit.
Then the javascript code which gets the List ID and Page ID is very simple because this information is there in the magic _spPageContextInfo:
var takana = window.takana || {};
takana.alertMe = function () {
var url = String.format("{0}/{1}/SubNew.aspx?List={2}&ID={3}"
, _spPageContextInfo.webAbsoluteUrl
, _spPageContextInfo.layoutsUrl
, encodeURI(_spPageContextInfo.pageListId)
, _spPageContextInfo.pageItemId);
OpenPopUpPage(url);
}
This code will open a modal dialog in exactly the same way as the ribbon command in OOB SharePoint and let you subscribe to changes on that page. In this code I use String.format which is available on SharePoint pages and _spPageContextInfo which has existed since SharePoint 2010 and has been extended with more useful information about the current context.
Recent Comments