Since the introduction of Windows 10 IoT, the Raspberry PI was a new platform for the implementation of all kind of applications using the familiar development environments such as Visual Studio and C#. However, the Windows IoT platform did not support web application development out of the box requiring custom solutions (e.g. web server running as a background application).
Home AutomationA typical scenario for a Raspberry PI based application is home automation. Besides typical monitoring applications with a variety of sensors, the integration of different devices such as ventilation units, power meters, PV inverters, heating boilers, Z-Wave controls become an important issue.
Problem
The various devices provide a wide set of application and user interfaces ranging from web interfaces, REST based web API's to industrial Modbus TCP. Some of the systems provide remote access to cloud based services requiring different security support (two phase login, OAuth, custom secrets, passwords etc.).
Goal
The home control web application should provide a web interface for selected data, the integration to cloud based monitoring services such as ThingSpeak, and a consolidated REST based web API to simplify data access.
The Home Control Web Application gathers data from a various sources using REST based Web API's or Modbus TCP.
- ETA PU 11 Pellets Boiler
- b-Control EM300 Energy Manager
- Helios KWL EC 200 Ventilation Unit
- Fronius Symo Inverter
- Netatmo Weather Station and Modules
- Zipato Zipatile Z-Wave Home Control Unit
- BMW i Wallbox Charging Station
With ASP.NET Core 2.2 the promise of cross platform development of various application types (console applications, web applications etc.) become a reality. As it has been shown before, the deployment of ASP.NET web applications to a Raspberry PI running Windows 10 IoT is pretty easy - just compile the web application for the win-arm run-time platform and publish all to a directory on the Raspberry PI.
Software Components- Windows 10 IoT
- ASP.NET Core 2.2
- Serilog Logging Framework
- Syncfusion Essential Studio for ASP.NET Core
- Modbus TCP (NModbus Library)
- Swagger (Swashbuckle.AspNetCore)
The access to the various devices is implemented in custom libraries targeting the .NET Standard 2.2. This allows the use of the libraries in different applications (console application, Windows Universal application, ASP.NET Web application). All the internal specifics of the data access is hidden, exposing only the various data properties and read and (optional) write operations.
- EM300LR
- ETAPU11
- KWLEC200
- SYMO823M
- Fronius
- Netatmo
- Zipato
- Wallbox
- NModbus
In order to facilitate the access to the actual monitored (or controlled) data, property set and get routines are added to allow a dot-notation for properties supporting nested classes and simple arrays and lists.
Modbus
The devices providing a Modbus TCP interface are integrated using the NModbus Library with several extensions for additional datatypes such as strings, floats and double. The Modbus TCP protocol is used only on the internal network and is not exposed to the outside. This is also used for additional tools such as a gerneric command line Modbus application or an Modbus TCP gateway providing a REST based interface via HTTPS.
The standard ASP.NET web application template using razor pages and an Sqlite database for the individual user authentication has been used. Several pages are added to display selected data from the various components. An additional page is used to embed the Swagger Web API. The Swagger pages and selected other pages require authentication to be accessed. The ASP.NET Core Web application also uses HTTPS as the only protocol to access the pages. The Syncfusion UI components (community edition) are used for the display of gauges and charts but any other ASP.NET Core 2.2 compatible components could be used instead.
SignalR
A more recent development is the availability of the SignalR communication framework in ASP.NET Core 2.0. It is used to update the selected monitored data on the associated web pages automatically in the background.
Data Provider & Monitor Services
Simple singleton services provide the access to the instances for the various devices. The monitor services running in the background implement the automatic update of monitored data, accessing the devices (Modbus TCP, Web API's etc.) and synchronizing the local cached data instances. The update period is typically 60 seconds and one of the monitor services sends selected data to the Zipato home control unit further processing and display. As an example the CO2 value from the Netatmo indoor module is used to modify the color of a LED lamp based on the CO2 level.
REST API and Swagger
The monitored data from the various devices are also made available via set of consolidated REST based web API's. Swagger integration provided by the Swashbuckle project adds Swagger to the WebApi project combining ApiExplorer and the Swagger-UI to provide a rich discovery, documentation and playground experience to the REST API consumers.
DeploymentThe Home Control Web application can be deployed on the various platforms supported by the ASP.NET Core 2.2 framework. It also runs on a Raspberry PI 3 or Raspberry PI 2 B using Windows 10 IoT by simply publishing to a directory on the Raspberry PI. The necessary configuration files
As has been shown on the Internet the ASP.NET web application can be automatically started on reboot using a simple command file and the schtasks
command using Powershell.
The code has been updated to reflect the latest upgrade ASP.NET Core 2.2, and the latest Swashbuckle, Serilog, and NModbus library.
Windows 10 UWP App and Xamarin Android App
As an example a Windows 10 UWP app is provided using the REST based web services to retrieve selected data and display them accordingly.
The Xamarin Android app is a similar example of using the .NET Core Libraries and web services to display selected data.
Note:All source code is now available on Github (dtv42/HomeControl).
Comments