Skip to content
adatum
  • Home
  •  About adatum
  •  Learn Azure Bicep
  •  SCOM Web API
Automation

Serverless application with PowerShell: Azure Event Grid

  • 30/05/201807/01/2025
  • by Martin Ehrnst

This is part one of my blog series describing how you can create a serverless application infrastructure using PowerShell. The scope and history behind, covered in the introduction post. If you haven’t read that I recommend doing so.

Azure Event Grid

In my serverless infrastructure design, I have chosen to use Azure Event Grid as a hub for the other components in play. The other components will write and subscribe to events/messages in Event Grid and perform their given task as ‘their’ event arrives. Event grid fit’s the concept perfectly as you act on state changes. You can publish as many events you like, but you don’t need to subscribe to every one. A lot of Azures PaaS offerings are already fully integrated which makes it easy to get started.

Other event based offerings in Azure are Service Bus and Event Hub. You can read a little on the differences here

Set up Event Grid custom topic

I am sure you are able to create resources in Azure so here’s a quick one. Feel free to use what ever you want for deployment, but for the purpose of screenshots, I’m using the portal. Just remember that the name you chose will be the url of your endpoint as well.


After the custom topic is successfully deployed, you are given the option to subscribe to events. Before doing that we are taking a break. Besides a graph showing incoming events you have no good way to see your events as they arrive. This makes it way more difficult to debug why stuff isn’t working. While writing this post I researched for a good way to solve this and stumbled across this blog post by David Barkol. He created a web app that lets you view events as they arrive. You can deploy it directly from GitHub using ARM. Do this while your coffee is brewing. And come back here in 10 minutes 🙂

 

Subscribe to Event Grid topic

Welcome back… If you have deployed the web app you can follow and create a subscription subscribing to all events. In a production scenario, it’s likely to have scoped your subscribers, but in order for Event grid viewer to function i’ll subscribe to everything.

new event grid subscription

Once deployed your overview page will look something like this. Showing all subscriptions within your topic and their corresponding metrics. Now lets try to send a custom event using powershell.

Send event to event grid using PowerShell

Basically, event grid accepts post request to an API endpoint, which is the name of your topic plus a suffix and the API version. your full URI looks something like this; https://adatumblogdemo.northeurope-1.eventgrid.azure.net/api/events?api-version=2018-01-01

To authenticate we will pass an ‘aeg-sas-key’ within our request header. You will find the keys for authentication in the keys pane. Further event grid events has a schema you willl need to follow, meaning that all post requests will need to have some properties defined and your custom event data will be in a data property. The basics of it all looks like this

[
{
"topic": string,
"subject": string,
"id": string,
"eventType": string,
"eventTime": string,
"data":{
"custom": "data"
},
"dataVersion": string,
"metadataVersion": string
}
]

More details on the schema can be found on Msft Docs

If we combine everything we know this far, we can use the script below to post messages to event grid. Please add your own url and access key. Everything else should work.

Assuming no error messages, jump in to your event grid viewer to view the raw content like this;

A corresponding graph in the Azure portal could look something like this. Here you will see incoming events and how many matches your subscriptions in the same graph. You can also see individual metrics per subscription.

event grid topic graph

 

Summary

In this part of my blog series on how to create a serverless application infrastructure using PowerShell. We have walked through how to set up a custom Event Grid topic and how to post messages or event to it using standard PowerShell commandlets. We also deployed a custom web application capable of reading our incoming events in real time.

 

In the next part: For part two we are going to create an Azure Function running PowertShell that subscribes and send Event Grid messages. This is key to build up our infrastructure wich consists of multiple Azure Functions in order to work.

 

Share this:

  • Click to share on LinkedIn (Opens in new window) LinkedIn
  • Click to share on X (Opens in new window) X
  • Click to share on Reddit (Opens in new window) Reddit
Get started with shell.azure.com Azure

Azure Cloud Shell

  • 14/12/201707/01/2025
  • by Martin Ehrnst

Azure Cloud Shell have been available through the Azure Portal for some time now. Just recently Microsoft released cloud shell as a “stand-alone” web page, shell.azure.com both Bash and Powershell (preview) are available.

That means you can access a Powershell (or bash) console from any browser at any time and from what I can see, both Azure RM and Azure AD modules are available. To get started, visit shell.azure.com and sign in.

First time setup

When you sign in using Cloud Shell for the first time you will have to create a storage account. I am not certain, but I assume the storage account is used for Powershell modules etc.

Select your subscription and continue.

azure cloud shell select subscription

First initialization can take some time, but when storage is created and Azure have done a few compute transactions, things should look something like this. In the below image I have started a Powershell session. From here on you can start exploring. Try to run help, Get-CloudDrive etc to get a little more information.

Azure cloud shell start

 

Cloud Drive

Cloud drive is the storage account for Azure Cloud Shell. I was a little interested in how it works and what possibilities it have. After a little investigation it turns out Cloud Drive is mounted in to cloud shell by default, mapped to letter Y: (see picture). Not sure how supported this is, but you can easially create folders, script etc inside your Cloud Drive which will be available on any device you use

Azure Cloud Shell cloud drive

 

Cmdlet examples

Azure Cloud Shell comes with all built-in Powershell modules and the whole AzureRM module loaded by default. And let’s not forget you also have text editors, source control and Pester available. To see a complete list of whats included in Cloud Shell, visit https://docs.microsoft.com/nb-no/azure/cloud-shell/features-powershell#tools

Apart from AzureRM (run Get-AzureRMCommand) you have Azure AD (AAD) available. For example Get-AzureAdUser.

I really like this new world, hopefully even better with Azure Cloud Shell.

Have fun!

Other resources

  • Azure Powershell Overview
  • Azure Resource Manager Overview

PS: If you run $PSVersiontable you will see that Azure Cloud Shell actually runs on the native powershell (Deskop), version 5.1 and not version 6 which is Powershell Core…

 

 

Share this:

  • Click to share on LinkedIn (Opens in new window) LinkedIn
  • Click to share on X (Opens in new window) X
  • Click to share on Reddit (Opens in new window) Reddit
Automation

Activate Webasto diesel heater using OMS and Azure functions

  • 03/10/201707/01/2025
  • by Martin Ehrnst

Looking at the above picture snow and winter is pretty awesome, but when you have to fire up your car outside your cabin in -15c (5f) you wish for summer. Not only is it extremely hard for your engine, but it’s also ridiculously cold to get inside the car! That’s why many cars in Norway are equipped with preheaters. A unit you can activate before starting or entering the car, heating up the engine (and in many cases the interior as well).
Just to put some numbers down, average temperature in Oslo January 2017 was -4.3, and coldest -12.6.

My child carrier, a Range Rover Sport, (one of Britains fines engineering that never fails) is equipped with a Webasto pre heater and controlled remotely by SMS command or an app. Communication is using WBUS, Webasto’s own language.

My goal in this post is to use data from the OMS Weather Data solution and Azure functions to automatically start my Webasto heater based on the observed temperature. I have to say, using the app directly way easier, but this is a very good opportunity to explore and play with cars, azure and automation.

 

Starting the heater

Many of these heaters and apps only communicate using SMS commands, but my heater controller can use internet connection as well, meaning there is an API of some sort it’s communicating with.

Using fiddler I found out how the app was communicating, replicating it using Powershell I ended up with this as a simple function to send commands to my heater. Typical commands are “cmd_heater_status” which asks for current status, and “cmd_time1:30,start” that starts the heater for 30 minutes.


To be honest, I wasn’t very pleased with the security here, but that’s something I will notify the company who make these controllers about.

Below is a typical output after requesting heater status.

heater : 1
gsm : 7
voltage : 12.0
h_temp : 25
flame : 0
date : 2017-10-1 19:13:9
valid : 1
status_date : 01/10
status_fdate : 01.10.2017
status_time : 21:13:09

Creating the Azure Function

After we have the basic functionality in place, we can add some logic to our script and create an Azure Function out of it. I have created a basic Powershell function below that accepts two input parameters. TempLow the temperature you have to be below to fire the heater, and heatingMinutes which is the number of minutes the heater will run.

The rest of the script is using our function above to request statuses and act upon our input and the heater response. I had to add sleep time within the script so that the Webasto controller had time process my commands.
Parameters like email-address and heaterId are defined as function environment variables

 

OMS / Log Analytics setup – query and alert.

Using data from the weather solution I created together with Cameron Fuller i created the following query to alert when observed temperature in Oslo is below a certain degree. This search is based on the new query language, Kusto. I reccommend everyone (including my self) to take a look at this Kusto cheet sheet.

YRno_CL | where LocationName_s == "Oslo" and TimeGenerated > ago(2h) | summarize AggregatedValue = avg(ObservedTemp_d) by bin(TimeGenerated, 15m), LocationName_s

Create an metric based alert based on the above query.

To kick off our Azure Function we set the alert to send a webhook with a custom json payload looking like this: (yes testing values)

{
"tempLow": "59",
"heatingMinutes": "40"
}

The test says webhook is sent successfully, and our function log confirms 🙂

 

Calm down John Snow, let winter come.

 

Share this:

  • Click to share on LinkedIn (Opens in new window) LinkedIn
  • Click to share on X (Opens in new window) X
  • Click to share on Reddit (Opens in new window) Reddit

Posts pagination

1 2 3 4 5 … 9

Popular blog posts

  • Webinar: Multi-tenant resource management at scale with Azure Lighthouse
  • Azure Application registrations, Enterprise Apps, and managed identities
  • Azure Monitor Managed Prometheus
  • Azure token from a custom app registration
  • OpsMgr & External Services PT2

Categories

Automation Azure Azure Active Directory Azure Bicep Azure DevOps Azure Functions Azure Lighthouse Azure Logic Apps Azure Monitor Azure Policy Community Conferences CSP Monitoring DevOps GitHub Guest blogs Infrastructure As Code Kubernetes Microsoft CSP MPAuthoring OMS Operations Manager Podcast Powershell Uncategorised Windows Admin Center Windows Server

Follow Martin Ehrnst

  • X
  • LinkedIn

RSS feed RSS - Posts

RSS feed RSS - Comments

Microsoft Azure MVP

Martin Ehrnst Microsoft Azure MVP
Adatum.no use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it. Cookie Policy
Theme by Colorlib Powered by WordPress