Optimization Web API
Implementierung
Nach einigen Wochen der Modellierung erfolgte nun die Implementierung des Modells und der notwendigen Solvermechanik in .NET/C#. Als Entwicklungsframework aus meiner Sicht aufgrund der zwischenzeitlichen Plattformunabhängigkeit von .NET Core, mehr denn je, die unbestrittene #1 unter den Programmiersprachen, vor allem im Enterprise Bereich, wenn auch nicht geeignet um die Bedürfnisse heutiger Python Script Kiddies zu befriedigen. Man möge mir den Seitenhieb verzeihen.
Der Solver und das zugehörige mathematische Modell wurden in eine net8.0 Web API gepackt und in einem Windows Service gehostet.
Wetter API
Um das Optimierungsmodell mit Wetterdaten zu versorgen, können dem Service die prognostizierten Außentemperaturen über den Request als Input übergeben werden. Diese Daten können beispielsweise aus dem angebotenen Wetterservice von Loxone herangezogen werden.
Werden die Wetterdaten nicht über den Request übergeben, so bezieht der Optimierungsservice diese über
welche die prognostizierte Außentemperaturen unter Angabe von Längen- und Breitengrad und einiger Steuerungsparameter auf stundenbasis für die kommenden 24 Stunden bereitstellt und eine hervorragende Alternative für Nicht-Kommerzielle Anwendungen darstellt.
Awattar API
Das Energieoptimierungssystem lebt vor allem von der Ausnutzung von Stunden mit reduzierten Stromkosten. Entsprechende Stromtarife erfreuen sich immer größerer Beliebtheit. In meinem Fall fiel die Wahl schon vor längerer Zeit auf Awattar Hourly. Einerseits ist eine entsprechende REST Web API verfügbar, andererseits bietet Awattar auch zusätzliche Goodies, wie zum Beispiel Charts mit Strompreis-Prognosedaten für den kommenden Tag. Für eine fundierte Entscheidung über die Verschiebung der Wärmeerzeugung sind diese variablen Stromkosten also von großer Bedeutung.
Details zur Awattar API für Loxone sind unter folgendem Link verfügbar.
https://www.awattar.at/services/loxone
Nachstehende Endpoints der Awattar API werden durch Awattar bereitgestellt:
http://api.awattar.at/v1/marketdata/current.yaml
http://api.awattar.at/v1/marketdata/current.yaml?tomorrow=include
Aus Gründen der Flexibilität des Services werden die Stromkosten ausschließlich über Input-Parameter im Optimierungs-Request bereitgestellt. Die Awattar API wird daher über Loxone integtiert, wo die Awattar Anbindung ohnehin aufgrund der erforderlichen Statistikaufzeichnung gemacht werden muss. Die Einbindung der Awattar API wird daher im Kapitel Loxone Integration behandelt.
Swagger/Open API Dokumentation
Die angewendeten Request und Response Objekte des Optimierungsservices sind unter nachstehendem Link dokumentiert.
https://www.factorysensesoftware.at/energyoptimization/redoc-static.html
Diese gilt es an späterer Stelle über unsere Loxone Automatisierung zu füttern und das Ergebnis für die Wärmepumpe aufzubereiten.
Deployment
Das Deployment erfolgte auf einem angemieteten V-Server mit 8 Kernen und 18 GB RAM auf Microsoft Windows Server 2025 Datacenter. Eine Maschine, durchaus geeignet um vom Multi-Threading des Solvers zu profitieren.
Der Service läuft auf dem virtuellen Server als Self-Hosted Windows Service, meine bevorzugte Hosting Methode. Die HTTP Requests werden vom integrierten Web-Server für ASP.NET Core Anwendungen, Kestrel, verarbeitet. Das garantiert eine leichtfüssige und performante Lösung. Und nebenbei erspart man sich die Installation und den Betrieb eines dedizierten Webservers, wie zum Beispiel Microsoft IIS oder ähnlichem.
Außerdem werden dadurch Service Restarts bei etwaigem Programmabbruch vom Windows Service gehandelt. Logging wird über Windows Applikationslogs bewerkstelligt.
Es wurden bereits so einige Hindernisse überwunden, die a priori nicht am Radar waren. Trotzdem sind wir schon weit gekommen und das System funktioniert bis hierhin tadellos. Für all jene, die geistig noch nicht ausgestiegen sind, warten allerdings noch einige weitere Überraschungen wenn es um die Integration der Intelligenz mit Loxone und der Vaillant Wärmepumpe geht.
