Software apps and online services
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).
A 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.
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.).
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
- Siemens SENTRON PAC 3200 PowerMeter
- Helios KWL EC 200 Ventilation Unit
- Fronius Symo Inverter
- Netatmo Weather Station and Modules
- Zipato Zipatile Z-Wave Home Control Unit
With ASP.NET Core 2.0 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.
- Windows 10 IoT
- ASP.NET Core 2.0
- Serilog Logging Framework
- Syncfusion Essential Studio for ASP.NET Core
- Swagger (Swashbuckle.AspNetCore)
The access to the various devices is implemented in custom libraries targeting the .NET Standard 2.0. 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.
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.
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.0 compatible components could be used instead.
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 cloud based ThingSpeak serivce for further processing.
Note that one benefit is that further processing can be implemented in the monitor services. Since the Zipato Z-Wave home control system support custom rules to be used, the access to additional data not directly supported can be implemented. The corresponding monitor service pushes selected data to the Zipato home control system every minute. 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.
The Home Control Web application can be deployed on the various platforms supported by the ASP.NET Core 2.0 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
Note: Since the authentication uses a Sqlite database and the required e_sqlite3.dll is not automatically copied to the this was done manually by copying the winsqlite3.dll from the
Windows\System32 directory to the publish directory on the Raspberry PI and renaming it.
The code has been updated to reflect the latest upgrade to Swashbuckle 2.0 and the latest NModbus library.