Estimated reading time: 16 minutes
In this article, and accompanying video series, we’ll look at why IOT deployment with the Power Platform might be a good approach for you to bring information from the physical world into the digital one, what the options are, and walk through a business process automation example of setting up a device, Azure services and bring the data into Teams and the Power Platform.
When you apply the Power Platform and Microsoft Teams features to improve business processes, you will eventually find problems that are not solved by digitizing the paper-based processes, replacing existing small line-of-business apps, or creating new apps quickly to solve new problems. Simply replacing a clipboard with a tablet app for data entry might leave the underlying problem unsolved.
Sometimes you’ll want to reach out for information or data that exists outside of a networked computer system because the key part of a broken process today is a human factor.
Whilst IOT (Internet of Things) may be a buzzword today, what it encompasses isn’t new, and there are mature, simple ways to bring useful data into Microsoft 365 so that the problem you are solving – such as someone forgetting to record a reading from a physical device – doesn’t require a siloed tactical solution, and instead can enable automation or data analysis using the Power Platform.
Table of contents
Why even consider IOT deployment with the Power Platform?
IOT covers everything from environmental monitoring in a farm field, logistics or stock control in a warehouse, electric vehicle chargers at the roadside, all the way through to the smart light bulbs in your home. An IOT deployment can help the business collect and utilize the information meaningful way, remove human error from laborious tasks (like reading a sensor), and provide automation and consolidated analysis of data and trends from multiple sources for useful insights that would otherwise be unclear.
As you engage with the business to identify where Microsoft 365 can help, such as with health & safety, logistics, operations, facilities teams, and others, you should look for opportunities where an IOT deployment could form part of the Power Platform and Teams solution. You can then choose devices, sensors, or suppliers that are certified to work with the Microsoft platform and are likely to be more secure and under IT controls.
If you work in any business that has physical premises, then you’ll already have IOT devices of some kind. Often these will be a potential security threat because the devices will have been bought and installed by departments such as facilities management and will have closed ecosystems, connecting either to on-premises management systems or the vendors’ walled-garden cloud service.
Beyond your initial foray into IOT deployment with the Power Platform for providing useful management information (MI) data, a future step could take you into AI Builder, one of the tools within the Power Platform, to provide predictive analysis. The Power Platform tooling is not just for data coming from within Microsoft 365, it is for all data. Telemetry data from an IOT deployment is data that simply needs to be brought into a useful, accessible location. The Power Platform includes solutions that might mean you don’t need to use a data scientist, a team of developers, or build a solution using the underlying Azure services directly.
Use-cases for IOT deployment with Teams & Power Platform
In this section, we will dive into business process automation examples using IOT deployment with the Power Platform and Microsoft Teams. There are many use-cases where low-cost, secure solutions based upon Azure-certified plug-and-play IOT devices, configured to send data to the Power Platform solve a business need. With very little effort, you can use the Microsoft 365 products you’ve already bought, and provide a better solution than you’d get by buying a separate solution.
In order to set the stage for these use-cases, I want to describe the Microsoft 365 solutions used with the IOT deployment: Dataverse (or in some cases, Microsoft Lists) as a location to store data; Power Apps to allow us to build a UI that can be shown in Teams; Power BI for data presentation; and Power Automate to receive data and trigger workflows based on events that are recorded.
As a starting point for identifying use-cases for this scenario, look for processes that are human-intensive; find out if there’s a known, regular cost incurred by people forgetting to perform the task or creating errors.
One retail customer I worked with recently had an estimated cost to the business of approximately $4,000 per week across all their stores due to people not checking refrigeration devices regularly enough. If a refrigerator failed or temperature control was altered, and it wasn’t noticed in time the stock had to be disposed of.
That is a great example of where IOT deployment with Teams and the Power Platform is appropriate, provides demonstrable savings immediately, and fits into an existing process automation project that is leveraging the Microsoft 365 products they already own. Dataverse is included within Teams, which allows the solution to be rapidly prototyped with a low cost to move into production. It can easily be improved to include approvals processes, data visualization, or even use Power Automate to raise service tickets in other systems.
Whilst health, safety, and environmental monitoring use-cases span many industries, you’ll find other common examples such as room occupancy, and desk usage where there are discrete solutions available, but they will either be expensive and integrate with Microsoft 365 or be low cost and live in their own closed ecosystems.
If you are using Microsoft 365 and need a desk booking system, it’s likely you will be using either one you’ve built in Power Platform or the Microsoft desk booking app rather than something bought as a bespoke solution. If there’s a need to automatically check-in people using sensors, then you may find the best solution is to use a solution built on this model with sensor data coming in via Azure (rather than working out how to interface a third-party solution for desk occupancy with your Teams solution).
Outside of generic use-cases, you’ll find retail and hospitality have a lot of common, similar needs including customer satisfaction devices and digital signage. In construction, manufacturing and utilities, solutions already exist that you can buy cheaply off-the-shelf and interface with Azure for transport, logistics and fleet monitoring or stock control.
What are your options for new devices or interfacing existing systems?
Almost all IOT devices available that are cheap and widely deployed use similar basic hardware, based on platforms such as Expressif’s ESP chips. The major difference between devices is the code that is deployed to them. You would be surprised to discover that a smart light switch you might buy from Amazon might use the same microcontroller unit (MCU) as a customer satisfaction button placed outside a toilet at a workplace, a device recording the GPS location for a truck, or the temperature of a refrigerator.
Whilst that doesn’t necessarily mean you can change the firmware on existing devices in-place today, it does mean that you will often find the same or similar devices sold by different suppliers, who develop code for, test, and deploy the devices as Azure-certified devices that you can deploy code to.
For existing industrial sensor devices, such as those used in critical, legacy systems that use industry-standard protocols used for telemetry data and machinery control, you’ll use gateway devices; often based on ARM-based hardware, on industrial circuit boards using components like Raspberry Pi Compute Modules. Solutions such as these are very different from a Raspberry Pi you might run at home, as the compute module interfaces with a circuit board created by the device manufacturer that includes the circuitry necessary to interface with the legacy telemetry solution, using protocols such as MODBUS, EtherCAT, RS432 or similar, and processing that data and sending it onward over the LAN.
The first class of devices, often deployed as completely new solutions – using lower-cost MCU type sensor interfaces – are most likely to meet the needs of solving business problems like those mentioned earlier in the article, where the data isn’t collected today and there is a business problem to solve. The higher-end devices within the budget IOT space usually run Azure RTOS, which is Microsoft’s real-time operating system for IOT devices. These devices will actually have ARM or RISC-V processors within, but the RTOS will be effectively running a single process rather than an interactive operating system.
Lower-end devices may not be compatible with Azure RTOS, but may run Open RTOS, which is a similar solution, with Azure SDKs available from Microsoft to allow you to interface with the Microsoft Cloud. If you have looked at devices that are programmed using the Arduino IDE then you will be on familiar ground; Micropython, ESPHome and Tasmota are similar in concept and run on the same classes of devices. Azure RTOS and Open RTOS are more complex, but that doesn’t matter – the devices you buy and deploy outside of a PoC will be pre-programmed by your supplier or the manufacturer.
Gateway device will run high level operating systems you know, like Linux or Windows. You’ve deployed Windows IOT on mini PCs if you’ve bought Microsoft Teams Rooms; but Microsoft’s Linux solution aimed at IOT solutions you might not have encountered before. Azure Sphere combines a Linux-based operating system that can run Docker Containers and also run isolated RTOS instances. It is part of the same ecosystem that Azure RTOS and Open RTOS live within that can interface with Azure’s IOT services.
Thankfully Microsoft provides a certification process for devices in your IOT deployment. The Azure Certified Device Catalog includes IOT sensors and gateways you can purchase from various manufacturers and resellers.
How to you set up devices to prove your concept?
With our certified IOT deployment devices, let us turn our attention to how to set them up. For the example in the video, we’ve used Microsoft’s Azure IOT Dev Kit. This allows us to test the Azure RTOS on a fully supported device that includes a variety of sensors. Whilst the development kit might be most useful to a device manufacturer, you can use it to prove a range of scenarios without investing in many different devices.
The IOT Dev Kit is available from industrial IOT suppliers, such as RS Components, and even on Amazon. Whilst it may not be pretty, and won’t look like the “plug and play” devices for similar pricing you’ll buy for your real deployment, it gives you enough flexibility to test various scenarios and crucially, help you make sure you know your requirements before picking devices.
But how do we get the data from the devices into the cloud? We have several Microsoft-supported solutions for connecting an IOT deployment in a way that allows us to easily push data into Teams and the Power Platform.
Azure IOT Central is Microsoft’s “Application Platform as a Service”. This is a pre-built platform that contains a pre-configured set of Azure services suitable for IOT.
Azure IOT Hub, along with other services, such as IOT Explorer, Device Provisioning Service and Event Hubs can also be used to create your own supported platform; in a way IOT Central is similar to Windows 365 – you don’t have to configure or scale it in the same way you might need to do so for Azure Virtual Desktop; but the same underpinning services are used under the hood.
In addition to Azure-based options you could use open source solutions – such as various MQTT servers, which can be deployed into Azure (or on-premises) using Docker Containers – or ran natively on Linux & Windows servers; and from there we could create scripts using PowerShell or Python that subscribe to messages and push them direct into Microsoft 365. However – as a starting point – we’ll go for an end-to-end solution that is built on Microsoft’s existing cloud services and go for as close to a SaaS solution as we can. You know it make sense…!
In our device setup video, we’re following the core guidance from Microsoft’s Quick start for the Azure IOT Devkit, running Azure RTOS. If you are testing with devices such as ESP32 development boards then you’ll find similar Microsoft Docs Quick start guides that allow you to create a PoC using those devices.
We’re combining that with using Azure IOT Central so that we can use the Device Provisioning Service to onboard devices quickly and manage them in a similar (but more basic way) to Intune.
The only relatively complex part of the Quickstart guide is editing specific source code files to configure WiFi settings and copy and paste device ID scope and Shared Access Secret (SAS) keys obtained from the web UI in Azure IOT Central (see Figure 3).
All the command line steps in the quick start guide, such as the command scripts to install the compiler, the command script to compile the code, and the process to copy the firmware – which is literally copying it to an emulated disk drive presented by the device (see Figure 4) – require no knowledge of development or IOT to complete.
After completing the steps in Microsoft’s quick start guide with the Azure IOT Dev Kit, you’ll have IOT sensor data available to you (see Figure 5) so that you can build a PoC solution within Teams with very little effort.
Pushing data to Microsoft Teams and the Power Platform
We have many options available for storage of streaming telemetry data in Azure; and whilst some applications of IOT might need long-term data storage or a level of retention that must exist outside of the lifecycle of a Microsoft Team, we’ll focus on getting the data into a Dataverse for Teams environment that has no additional cost associated with it.
This means we need to create the Dataverse environment the right way by creating a new Power App attached to an existing Team, and then creating a Dataverse table that will be used to store data (see Figure 6).
The Power App itself might not be needed by a user – it may be that the data itself is visualized somewhere else, such as Power BI, or more likely, you automate the business process based on triggers from the telemetry data.
In IOT Central, we create one or more rules. The rules are based upon the sensor values, and each included sensor condition will result in that sensor’s data being passed to the Power Automate flow.
To send all data as it is received, we’ll create a rule that will trigger based on any sensor value that is higher than a reasonable minimum. In the example in our video series, we chose that any temperature value higher than -1000 will trigger the rule (see Figure 7). A normal condition, such as higher than -1 might not trigger that rule in a refrigerator measuring in Celsius, for example.
In our example we also create a second rule which is triggered based upon the condition we want to monitor for; however, you may find the second rule superfluous as subsequent Power Automate flows could be based upon the values in the Dataverse table as they are added.
Power Automate is essential as the glue between Azure IOT Central and our Dataverse table. We create a new cloud-triggered flow that uses the Azure IOT Central connector and then adds a new row in Dataverse (see Figure 8).
The beauty of receiving the data into Dataverse this way is twofold: using a Teams-based environment is a good way to use your existing Microsoft 365 licensing, and it is also very simple. Azure IOT Central’s rule is visible to us via the native Power Automate connector for Azure IOT Central, and the received values can be dropped into our table in a two-step process.
The next steps after getting the data in are not necessarily simple but they can now leverage your Power Platform skills. Anything that you would do based upon a new Microsoft List item, or a button pressed in a Power App, a new Form submission, you can now do based upon IOT telemetry data received. Because the data is now within Microsoft 365, and subject to your tenant’s data controls; and because the IOT device platform is fully under your organization’s control, you help reduce the threat of introducing IOT solutions into your environment that could pose a security risk.
That’s not to say you should place them on the normal LAN – the same rules still apply – however you have the option to keep the devices on internal networks that are only able to access a specific IP range or Azure vNet.
But more than that – you get the wider business benefit of being able to leverage all the data collected by your various process automation activities in management information, business reporting, and potentially to help with solving problems the business hasn’t yet identified. And to test it all out will cost you less than $50.
I’m a big fan critical process data being sent to the user, Email or Teams, rather than the user having to delve into a Monitoring or SCADA system to get that data. Only when there an issue to perform diagnostics, should they need to delve into more complex Apps. Also charts, not text, have the most brain bandwidth. A series of charts that have broken thresholds can tell you more about the state of a complex system in 5 minutes than hours spent otherwise. Need I add I was the Senior Process Eng at the world’s largest Aluminium refinery for almost a decade and spent the past decade with Exchange-Lync-SfB-Teams.