IoT Hub is a service that was designed for IoT device connectivity, and this is the main reason for choosing this exact service. The IoT Hub provides per-device identity and revocable access control, which is crucial for IoT in general and particulary for IRPi - we have to ensure that the users are safe, or else a hacker can contol frequently used item in the victim's house or houses. IoT Hub is also optimized for scaling, can support millions of simultaneously connected devices. This is a big part of IRPi, the goal is to let everyone control every IR device from anywhere.
Azure suggests few options for hosting websites: App Service, Cloud Service, Virtual Machine, and Service Fabric. We chose to use App Service as it fits our goals best - it allows quick deployment and handles scaling. In the following paragraph we describe the main pros and cons for each option.
App Service - This service handles scaling and load balancing. It also allows quick deployment and is relatively easy to use. This service does not allow remote desktop access. If one wish to start using an App Service for an existing site, small changes might be needed.
Cloud Service - This is a legacy service and it's recommended not to use it in new projects.
Virtual Machine - The main advantage of a Virtual Machine is that you can take a local project and upload it 'as is'. But as this is a Infrastructure-as-a-Service (IaaS) and not a Platform-as-a-Service (Paas), maintenance is needed. Therfore for a new projects PaaS is preferred.
Service Fabric - This service is similar to App Service, it makes scaling and load balancing easy, and allows quick deployment. Service Fabric also allows more direct controll over the underlying infrastructure. This service is relatively new.
Service Fabric also offers the features we need, but we don't need the control over the underlying infrastructure and preferred to work with a service that exists for a longer time.
Deeper overview can be found here.
Azure Functions are a strong tool given by Azure. They allow to run short pieces of code without building an application or infrastructure around them.
When using Azure Functions, there are 2 possible types of pricing plans:
- Consumption plan - pay for the time your code runs.
- App Service plan - run your Azure Functions on the infrastructure used for an existing App Service with no additional cost.
As we host our site using an App Service, we chose the App Service plan.
We have coded 3 Azure Functions:
Store recordings - This function is triggered when a D2C (Device to Cloud) message arrives to the IoT Hub. The function parses the message and insert it to an Azure Storage Table named IRRecordingTable.
Execute schedule tasks - This function is triggered once a minute. For any message in the Azure Storage Table named IRScheduleTable, it checkes wheter it should be transmitted now, and if so the function invokes a corresponding direct method.
Handle API calls - This function is triggered when an HTTP Post request is sent to it's URI. It handles requests that contain the following parameters: DeviceID, ProductName and ActionName. For any such request it reads the wanted IR message from IRRecordingTable and invokes a direct method for the relevant device.
Azure Storage Table
There are two main databases that Azure provides, these are Azure Storage Table and SQL Azure. SQL Azure is great for when you want to work with structured data using relations, indexes, constraints, while Azure Table Storage is great for centralized structured data without relations. Each row in an Azure Storage Table is unikly defined by a PartitionKey and a RowKey, they're also used for physically partitioning the tables, which provides load balancing and scalability.
We chose to work with Azure Storage Table rather than SQL Azure because of the load balancing and scalability factor and also because it is much cheaper when you work with bulk storage.
The following diagram explains what happens when a web user clicks on a transmit button:
- A GET request is sent to the Web app sufficient info to know which IR message the user clicked on.
- The Web app asks the Storage Table for the appropriate IR message in the IRRecordingTable with the information from the GET request.
- The Storage Table retrievs the IR message and sents is back to the Web app.
- The Web app invokes a direct method which tells the IoT Hub which device should transmit and what message.
- The IoT then communicates with the chosen device and forwards him the IR message to transmit.
The following diagram explains what happens when a web user wishes to record a new message:
- The web user chooses a device, product name and action name and then clicks a button to start recording. After the click, a GET request is sent to the Web app with the device ID.
- The Web app then invokes a direct method which tells the IoT Hub which device should start recording.
- The IoT communicates with the chosen device and tell it to start recording.
- When the web user wishes to end the recording, he presses the appropriate button. This sends a GET request to the Web app with the device ID, product name and action name as parameters.
- The Web app then invokes a direct method which tells the IoT Hub which device should stop recording. It also forwards the product name and action name chosen by the web user.
- The IoT then communicates with the chosen device and tells him to end the recording and gives him the rest of the parameters.
- The chosen device sends a D2C message with the recording, product name and action name.
- An Azure Function listens to messages from endpoint devices. When a D2C message is sent from a device the Azure Function handles it.
- The Azure Function inserts a new item to IRRecordingTable with the given IR message, product name, action name and device ID.
The following diagram explains the proccess of making a shedule and auto executing it:
This is what happens when a web user wishes to schedule a new message:
- The web user chooses a message to schedule and then sets a trigger time for when it should be trasmited. After a click on the submit button a GET request is sent to the Web app with the appropriate parameters.
- The Web app adds a new row to the IRScheduleTable with the information from the GET request.
The following proccess is automatic and runs as an Azure Function every minute:
- The Azure Function asks for the information stored in IRScheduleTable.
- The Storage Table retrievs the desired table and sends it back to the Azure Function.
- For every message in the table that its schedule time arrived, the Azure Function ivokes a direct method to tell the IoT Hub which device should transmit and what message.
- The IoT then communcates with the chosen device and forwards him the IR message to transmit.