This blog series is based on a private project and not customer related. But it might show you how easy it is to solve real world problems with Azure services.
As a short teaser, this is my current custom OMS solution dashboard that I will explain throughout this blog series:
- Part 1 describes the initial situation and my decision criteria for the devices, tools and services I used to build the solution.
- Part 2 describes the overall technical architecture, some technical details and some lessons learned
- Part 3 describes how I created the dashboard tiles and the alarmin based on the data I collected
If you are not interested in neither the background of my solution nor the technical details and just want to see the solution at work, please jump straight to part 3 
My initial situation
I have several remote locations (storage or cellar rooms) that I need to monitor regarding temperature, power loss/outage and humidity (optional).
Objectives for my solution
Precisely I wanted to achieve these objectives:
- Get an alert as quick as possible, when the room temperature fall out of a defined range
- Get an alert as quick as possible, when there is a power outage in one of the locations
- Get an overview (dashboard) of the current state of all locations from wherever I might be
- Get an alert whenever one of the monitoring devices in a location dies (malfunction or other issue)
- [Optional] Track the temperature on a very basic level
- [Optional] Track and alert the humidity in the room
- Spent as little time and as little money as possible
![🙂]()
Sensor devices
Some guys will say: this is a perfect job for a raspberry PI, isn’t it? Unfortunately, I don’t have a clue about the PI and I do not have any kind of internet or Wi-Fi connectivity at the remote location. Just some very basic 2G connectivity with rather poor reception (cellar, you know…).
Because I did not want to re-invent the wheel I searched for temperature monitoring sensors with GSM and SMS capabilities. Finally I came up with a device called DRH-3015 Temperature Guard. It has an external temperature sensor that can be programmed and queried via SMS text messages:
I bought a couple of these devices. They work fine by sending text messages in case of a power outage (there is a battery backup module built in) or if the temperature falls out of the defined range. Unfortunately, this device cannot send status messages on a defined regular interval. You will always have to trigger the status message by sending a text message from your mobile phone. So for every measured value you have to pay twice: One trigger message and one message with the value as an answer!
I hoped that there were more intelligent devices availabe and after a while I found another device called KKMoon RTU5023 (available from a large US/international online retailer).
It provides some very nice features in addition to the DRH-3015:
- External antenna connector for better 2G quality of reception
- Allows to monitor temperature and humidity
- Can send status messages (reports) on a scheduled base
- You can call the device from an authorized mobile phone number. The device will not answer the call, but cancel it immediately so the call is free of charge. But it will trigger a status message sent to the caller. So querying the status of the device will cost you just one text message instead of two!
Currently I have three DRH-3015 and three RTU-5023 in place in four different locations.
Designing the solution
Now that I had my devices, how could I achieve my objectives? I quickly realized, that OMS Log Analytics is the perfect place for collecting all sensor information, creating nice dashboards and sending alerts based on the collected data. But how do I get the data into OMS?
Yes, I know. Would I have used a raspberry PI I would be able to send the sensor information straight up to OMS via our REST-API.
But as I just have devices sending text messages, I needed to find a way to:
- Send text messages to the device automatically to trigger a status message (for the DRH-3015 devices)
- Receive text messages and transfer them into a custom OMS log record (for out-of-band messages from both device types and periodic status messages from RTU-5023 devices)
- Convert the text message into a standardized custom OMS log record
While playing a bit with the devices I also quickly noticed, that after I manage to receive these text messages automatically somehow, I have to transform and standardize them. And this can be challenging:
Unfortunately the devices have different kinds of formats for regular status messages and out-of-band alert messages. Even within the same type of device they can use different formats depending on the firmware used:
Receiving, parsing and extracting text is a perfect job for a PowerShell script! Running PowerShell scripts automatically in the cloud is offered by Azure Automation runbooks! So I will need at least one Azure Automation runbook.
But how do I trigger and receive text messages? By searching for the terms “azure automation text message” I quickly came up with a service called Twilio. Twilio offers virtual mobile phone numbers in almost any country and a REST-API for sending and receiving text messages via this specific phone number.
Based on these thoughts and findings this is my plan for the technical solution and the upcoming next steps:
- Trigger and receive text messages via Twilio
- Get data from Twilio with an Azure Automation runbook
- Send modified data to a custom log in OMS Log Analytics via an Azure Automation runbook
- Built a dashboard based on the custom log records in OMS
- Create E-Mail alerts based on the custom log records in OMS
I will describe the overall architecture and some technical details in part two of this series.