Das Script-Paket zum Download mit ein paar Installationshinweisen
Auf dieser Seite
Der erste Teil der PHP-Datenbank ist das Script-Paket auf dem Webserver. Ich gebe hier einige Hinweise zur Einrichtung – einschließlich einiger Hinweise zum Webspace. Das Thema ist allerdings etwas komplexer, daher kann ich hier keine einfache Schritt-für-Schritt-Anleitung liefern.
Als erstes gilt es, den Webspace vorzubereiten. Was wir brauchen, ist folgendes:
Diese Voraussetzungen sind praktisch Standard sowohl für kostenlosen als auch für kostenpflichtigen Webspace. Unterschiede gibt es häufig im Funktionsumfang: kostenloser Webspace fügt automatisch Werbung ein oder stellt nur Unterverzeichnisse oder Subdomains zur Verfügung, während kostenpflichtige Angebote in der Regel werbefrei sind und das Registrieren eigener Domains erlauben.
Für die Entwicklung des Script-Paketes habe ich eine eigene Subdomain im LAN eingerichtet und die PHP-Datenbank auf einem Ubuntu-Webserver in den Tiefen meines Kellers laufen lassen. Das ist natürlich optimal, weil ich damit volle Kontrolle über alles habe.
Bei meinem Freund, der Auslöser für dieses Projekt war, gibt es kostenpflichtigen Webspace. Wir konnten die PHP-Scripte in ein Unterverzeichnis legen und über seine vorhandene Domain zugreifen. Auch das eine praktikable Lösung.
Bei kostenlosen Angeboten mit Werbung ist es etwas fraglich, ob das Script-Paket funktioniert. Hier müsste man im Einzelfall ausprobieren, was geht und was nicht.
Für dieses Tutorial – und, zugegeben, aus Neugierde – habe ich mir kostenlosen Webspace bei bplaced zugelegt. Das ist etwas weniger optimal, weil anscheinend kein TLS zur Verfügung steht (oder ich die entsprechenden Optionen nicht gefunden habe). Aber es ist ausreichend und läuft bisher tadellos.
Die Sammlung ist damit unter http://luetgens.bplaced.net/homematic erreichbar.
Wenn die Seite nach der Installation der Scripte aufgerufen wird, erscheint eine kurze Hilfe zur Syntax der REST-API. Wurden bereits Werte eingetragen, können einige Reports für die vorhandenen Tabellen abgerufen werden.
Die PHP-Dateien, die für Ein- und Ausgabe zuständig sind, sind die folgenden:
set.php
Mit set.php können Werte in die Datenbank geschrieben werden. Das ist in der Regel der erste Schritt, um die Funktionsfähigkeit zu prüfen.
Als Parameter müssen Tabellenname und Wert angegeben werden. Ist die Tabelle noch nicht vorhanden, wird sie angelegt.
In meinem Fall würde also
http://luetgens.bplaced.net/homematic/set.php?table=test1&value=15
eine neue Tabelle test1 anlegen und den Wert 15 speichern.
html.php
csv.php
Vorhandene Datenbank-Einträge können im HTML-Format oder als .csv-Datei ausgegeben werden. HTML sieht halbwegs übersichtlich im Browser aus, .csv lässt sich zum Beispiel in Excel importieren und auswerten.
Notwendiger Parameter ist auch hier der Tabellenname. Weitere Optionen zur Auswertung sind unten beschrieben – und natürlich auf der Indexseite.
Mit der aktuellen Konfiguration kann jeder in den Daten rumfummeln und alles abrufen, was die Datenbank hergibt. Das geht so natürlich nicht.
Je nach Webspace und eingesetzter CCU-Firmware gibt es verschiedene Möglichkeiten, den Zugriff abzusichern.
TLS
Verschlüsselung für die Verbindung sollte eigentlich immer aktiv sein. Leider bieten nicht alle Webspace-Anbieter dies an, die Konfiguration ist problematisch oder der Webmaster (z. B. ich) hat wichtige Gründe, die dagegen sprechen (z. B. kein Bock).
wget auf der CCU prüft die Zertifikate freilich ohnehin nicht, womit die Hälfte der Transportverschlüsselung so oder so wieder perdu ist. Deshalb ist es auch nicht dramatisch, wenn die Verschlüsselung ausbleibt. Man muss aber unbedingt im Hinterkopf behalten, dass dann Daten unverschlüsselt durch das Internet geschickt werden.
Wenn TLS aktiviert wird, dann muss die URL für den Zugriff auf https geändert werden.
HTTP-Authentifizierung
Wenn möglich, sollte die Anmeldung mit Username und Passwort für das Verzeichnis aktiviert werden, in dem das Script-Paket liegt.
Zusammen mit TLS-Verschlüsselung ist das die sicherste Variante, um auf die Schnelle den Zugriff abzusichern. Ohne TLS klafft hier die offensichtliche Lücke, dass Username und Passwort unverschlüsselt übertragen werden.
Der ganz große Haken bei der Sache ist, dass das wget auf der CCU 1 keine HTTP-Authentifizierung unterstützt. Damit fällt diese Sicherungsmaßnahme auf der CCU 1 also aus. Ab CCU 2 läuft es.
Token
Als Minimal-Option besteht die Möglichkeit, einen Token in der config.php einzutragen. Dieser muss dann für alle Scripte des Paketes als Parameter übergeben werden, damit Daten angezeigt werden. Ohne Token gibt es nur eine Fehlermeldung.
Wenn als Token „geheim“ eingetragen ist, muss also dieser Token bei jedem
Aufruf übergeben werden. Beispiel:
http://luetgens.bplaced.net/homematic/set.php?table=test1&value=15&token=geheim
Weil der Token Teil der URL ist, kann ohne TLS jeder, der den Datenverkehr abhört, auch den Token im Klartext lesen und verwenden.
.htaccess
Viele Sicherheitseinstellungen werden über .htaccess konfiguriert. Dabei handelt es sich um Dateien, die wie alle anderen auch einfach auf dem Webserver gespeichert werden und bestimmte Optionen für Verzeichnisse und Dateien vorgeben, z. B. zur Anzeige von Verzeichnisinhalten, zum Zugriffsschutz oder zur Passwortabfrage.
Im Script-Paket liegt bereits eine passende .htaccess-Datei für das /config-Unterverzeichnis. Wenn der Webspace .htaccess in dieser Form unterstützt, kann niemand auf die Datei mit den Konfigurationsdaten in diesem Verzeichnis zugreifen.
Für das gesamte Script-Paket muss bei Bedarf eine passende .htaccess-Datei angelegt werden, die den Zugriff regelt – oder die Einstellung kann über die Weboberfläche des Providers oder Konfigurationsdateien des Webservers vorgenommen werden.
Für meinen bplaced-Webspace habe ich ein wenig mit .htaccess-Dateien rumgefummelt, um das Verzeichnis mit Passwörtern abzusichern. TLS habe ich wie beschrieben nicht eingerichtet: Es handelt sich nur um eine Demo-Datenbank ohne schützenswerte Daten. Falls da jemand einbricht, findet er nichts und kann auch nichts kaputtmachen.
Ein „Einbruch“ in den Webspace hat keine Auswirkung auf die Sicherheit der CCU: Nur, weil jemand in meine Demo-Datenbank kommt, hat er noch lange keine Zugangsdaten für die HomeMatic.
Wie oben bereits angedeutet, bietet das Script-Paket einige rudimentäre Möglichkeiten, die erfassten Daten auszulesen.
html oder csv
Die erste grundsätzliche Entscheidung besteht darin, ob die Daten als html oder als kommaseparierte Werte ausgegeben werden sollen. Ersteres eignet sich besser für eine schnelle Übersicht im Browser (und sieht dort auch übersichtlicher aus), letzteres ist ideal, um die Daten in anderen Programmen weiterzuverarbeiten.
grid
Mit grid lassen sich Daten gruppieren: month, day, hour, 5min und raw. Bei grid=day wird für jeden Tag eine Zeile ausgegeben, bei grid=hour für jede Stunde usw. Bei grid=raw werden die Werte nicht gruppiert.
limit
Die Anzahl der Zeilen, die ausgegeben werden, kann (und sollte) beschränkt werden. limit=24&grid=hour gibt z. B. einen Report über 24 Stunden aus, wobei jede Zeile eine Stunde ist.
select
Wer in alten Daten kramen möchte, kann mit select=oldest die ältesten Werte einer Tabelle ausgeben statt der neuesten.
Die einzelnen Zeilen eines Reports bieten – außer bei grid=raw – noch eine Reihe statistischer Auswertungen. Auf der Beispiel-Seite ist beschrieben, wofür diese Spalten nützlich sein können.
Wenn es nur darum geht, auf die Schnelle ein paar Werte zu protokollieren, sind diese Möglichkeiten vielleicht schon ausreichend. Anderenfalls kann man natürlich alles aus der Datenbank rausholen, was drinsteckt – zum Beispiel zur Visualisierung auf einer Webseite oder ähnliches.
Das Paket mit den PHP-Dateien gibt es hier zum Download:
Es kann – nach Anpassung der Konfigurationsdatei und ggf. der vorhandenen .htaccess-Dateien – auf den Webserver hochgeladen werden und ist der komplette Server-Teil des Frameworks.
Falls jemand irgendwelche privaten Passwörter darin findet, die ich nicht bereinigt habe, bitte kurz Bescheid geben …
