Web-Apps sind Programme, die im Webbrowser des Betrachters laufen. Aber
warum sollte man so etwas mit RaspberryMatic einsetzen? Das hat doch
schon eine GUI?
Jeder, der bereits ein RaspberryMatic-System aufgesetzt hat, kennt die RaspberryMatic-Weboberfläche. Mit ihr kann man alles einrichten, einstellen und programmieren, was bei einem Homematic-System notwendig ist.
Eines ist sie jedoch nicht: übersichtlich. Jemand, der das System nur oberflächlich kennt, findet sich darin kaum zurecht.
Es liegt also nahe, für solche Benutzer eine angepasste Oberfläche zu programmieren. Diese auf dem Raspberry selbst zu implementieren ist recht schwierig. Bei einer Webanwendung hingegen läuft die Weboberfläche auf dem Rechner des Betrachters, der wahrscheinlich um ein Vielfaches leistungsstärker ist, als ein Raspberry.
Und RaspberryMatic bringt im Prinzip auch alles mit, was man dazu braucht:
- einen Webserver, über den die App ausgeliefert werden kann
- mehrere APIs, mit denen Sensoren ausgelesen und Aktoren gesteuert werden können.
Allerdings, im Auslieferungszustand funktioniert diese Idee nicht – und RaspberryMatic trifft dabei nur eine geringe Schuld.
Grund ist ein in allen gängigen Webbrowsern eingebauter Schutzmechanismus: „Same Origin“. Dieser besagt, dass Sachen nur dann ungefragt von einem Webserver nachgeladen werden dürfen, wenn die aufrufende Seite (in diesem Fall die Web-App) auch von dort stammt.
„Same Origin“ bezieht sich hierbei leider nicht nur auf die gleiche Maschine, sondern auch auf den gleichen Port – und der Port, über den die APIs angesprochen werden, ist ein anderer als der HTTP(S)-Port, von dem die Web-App geladen wird.
Wenn die Web-App nun versucht, den API-Port anzusprechen, generiert der Webbrowser, in dem die App läuft, eine Nachfrage auf dem entsprechenden Port, ob der Zugriff gestattet ist: die sog. CORS-Anfrage. Diese versteht RaspberryMatic jedoch nicht und antwortet mit einem Fehler, der vom Webbrowser als ein „Nein“ interpretiert wird. Die Webbrowser blockiert dann die eigentliche API-Kommunikation.
Es gibt mehrere Möglichkeiten, dies zu beheben. Dieser Post beschreibt, wie man diesen Zustand „minimal-invasiv“ ändern kann.
Die hier beschriebene Lösung ermöglicht die API-Abfrage über den normalen HTTPS-Port und besteht aus einigen wenigen zusätzlichen Zeilen in einer Konfigurationsdatei. Damit wird die API-Abfrage wirklich „Same Origin“, die CORS-Anfrage entfällt und RaspberryMatic kann über eine Web-App gesteuert werden.
Hinweis: Die APIs sind eigentlich für „normale“ Programme (Skripts oder ausführbare Anwendungen) auf anderen Rechnern gedacht. Diese kennen den „Same Origin“-Schutz nicht und machen deshalb auch keine CORS-Anfrage.
Auswahl der API
RaspberryMatic kennt zwei APIs: die XML-API und die Homematic-Script-API.
Die XML-API verwendet zur Abfrage von Sensoren und Steuern von Aktoren – wie der Name schon vermuten lässt – XML-Snippets. Der Grund weshalb ich sie in diesem Beispiel nicht verwende ist, dass die XML-API keinen Zugriff auf die bei der Homematic-Programmierung häufig verwendeten Systemvariablen bietet.
Die Homematic-Script-API hingegen erlaubt das Ausführen beliebiger kleiner Homematic-Scripts. Diese Skripts können dann Sensoren abfragen, Aktoren steuern aber eben auch Systemvariablen lesen und schreiben.
Firmware ändern
Um die Firmware eines RaspberryMatic zu ändern, muss man sie zunächst entsperren, d.h. editierbar machen. Hierzu muss der SSH-Zugang im RaspberryMatic freigegeben sein (Einstellungen > Systemsteuerung > Sicherheit > SSH).
Dann kann man sich per SSH als Anwender eingeloggen und hat Root-Rechte. Das Entsperren der Firmware erfolgt dann mit dem Befehl:
mount -o rw,remount /
Nach dem Entsperren kann die Konfigurationsdatei lighttpd.conf des Web-Servers mit dem auf dem System installierten Editor vi editieren werden:
vi /etc/lighttpd/lighttpd.conf
Hängen Sie unten den folgenden Text am Ende der Datei an (Hinweis: Aufrufen des Einfügemodus bei vi erfolgt mit der Taste „i“):
$HTTP["url"] == "/regex.exe" {
$HTTP["request-method"] == "POST" {
url.access-allow = ("")
proxy.server = (
"" => (
"localhost" => (
"host" => "127.0.0.1",
"port" => 8183,
),
),
)
}
}
Speichern Sie die Änderungen… (vi verwendet hierzu ESC : w q)
„Sperren“ Sie die Firmware wieder gegen Änderungen:
mount -o ro,remount /
Stoppen und starten Sie den Webserver
/etc/init.d/S50lighttpd stop
/etc/init.d/S50lighttpd start
oder starten Sie im Zweifelsfall das System über die normale WebUI neu (Einstellungen > Systemsteuerung > Zentralenwartung > RaspberryMatic-Neustart).
Der Zugriff auf die Script-API ist nun auch über den normalen Webport mit einem POST-Befehl an die URL
/regex.exe
möglich.
Beschreibung der Änderung
Bei der Untersuchung des Problems hat sich herausgestellt, dass der RaspberryMatic-Webserver lighttpd auch für die Kommunikation der API-Ports zuständig ist und diese Befehle einfach an einen weiteren internen Port (in diesem Fall 8183) weiterleitet. Und genau das ermöglicht diese Änderung auch für den Zugriff über den normalen Webport.
Persistenz
Diese Änderung übersteht einen Neustart des Systems.
Hingegen überschreibt eine Neuinstallation der Firmware oder das gelegentliche RaspberryMatic Firmware-Update auch Konfigurationsdateien und damit diese Änderung. Nach einem solchen recht seltenen Ereignis muss die Änderung in der Konfigurationsdatei, wie oben beschrieben, erneut vorgenommen werden.
Sicherheitsaspekte
Beim Satz „erlaubt die Ausführung beliebiger Scripts“ sollten eigentlich die Alarmglocken klingeln. Um das Risiko zu minimieren, sollte der Zugriff auf die Homematic-Script-API nur verschlüsselt (HTTPS) und nur passwortgeschützt erfolgen.
Benutzer mit einem gültigen Passwort können jedoch beliebige Scripts auch über die normale RaspberryMatic-Weboberfläche ausführen, d.h. das Risiko ändert sich durch die Web-App also nicht.
Über „Systemsteuerung > Einstellungen > Firewall konfigurieren“ kann man, wie oben gezeigt, den Zugriff auf das lokale Netzwerk (192.168.0.*) einschränken.
Wenn solche Systeme hinter einem Internetrouter laufen und nur aus dem lokalen Netzwerk von einem autorisierten Benutzer angesprochen werden können, ist das Risiko also überschaubar.
Diese Konfigurationsänderung wurde mit den folgenden RaspberryMatic-Firmwareversionen getestet: 3.65.11.20221005 und 3.71.12.20230826.
Weitere Links zum Thema
- https://de.wikipedia.org/wiki/Cross-Origin_Resource_Sharing
- https://homematic-forum.de/forum/viewtopic.php?f=65&t=77331
