Smart Home (KNX): Difference between revisions
Line 35: | Line 35: | ||
Am Anfang unseres Versuchsaufbaus werden wir die einzelnen KNX-Komponenten miteinander verbinden und mit Hilfe der ETS-Software programmieren. |
Am Anfang unseres Versuchsaufbaus werden wir die einzelnen KNX-Komponenten miteinander verbinden und mit Hilfe der ETS-Software programmieren. |
||
Das KNX-Modell sieht wie folgt aus. |
|||
Der naive Ansatz wäre, zuerst folgendes KNX-Modell vollständig zu realisieren und dann mit der Programmierung anzufangen. |
|||
[[File:KNX-Modell.jpg|thumb|center|KNX-Modell |
[[File:KNX-Modell.jpg|thumb|center|KNX-Modell]] |
||
Im Zentrum des Modells steht der KNX-Bus, mit dem alle KNX-Komponenten verbunden sind. |
|||
Einige der Komponenten wie der Dimmer-Aktor brauchen eine separate Stromversorgung und werden im Modell mit einem gelben Blitz gekennzeichnet. |
|||
Bemerkung: Der naive Ansatz wäre hier, zuerst das KNX-Modell vollständig zu realisieren und dann mit der Programmierung zu beginnen. Da aber keiner in unserer Gruppe ein KNX-Experte war und wir auch die ersten waren, die dieses Workshop-Thema bearbeitet haben, ging viel Zeit für "try-and-error"-Prozesse drauf. |
|||
Im Nachhinein empfehlen wir Anfänger eine "step-by-step"-Vorgehensweise. Das bedeutet, dass wir jedes Gerät einzeln in den KNX-Bus aufnehmen und mit der ETS-Software einrichten. Denn falls etwas nicht funktionieren sollte, ersparen wir uns die Fehlersuche im ganzen System. |
|||
1. Schritt: |
|||
[[File:KNX-Versuchsaufbau-1.jpg|thumb|center|KNX-Versuchsaufbau Schritt 1]] |
[[File:KNX-Versuchsaufbau-1.jpg|thumb|center|KNX-Versuchsaufbau Schritt 1]] |
||
Die erste Komponente in unserem KNX-System ist die Spannungsversorgung MDT STV-0640.01 (links im Bild). Dieser wird benötigt, um das KNX-Netz mit Gleichstrom (gelb/weiß-Anschluss) zu versorgen. Die Installation soll laut Betriebsanleitung nur von ausgewiesenem Fachpersonal durchgeführt werden. Da niemand von uns Elektriker war, half uns unser Kursleiter hier weiter. |
|||
Der dunkelgrau/rot-Anschluss versorgt die KNX-Komponeten mit einer Bus-Spannung, auf welche Informationen ausgetauscht werden. |
|||
Die Spannungsversorgung--Komponenten müssen nicht programmiert werden. |
|||
Bemerkung: Auf der rechten Seite im Bild haben wir ebenfalls eine Spannungsversorgung vom Modell MDT STV-0024.01. Dieser besitzt jedoch keine Bus-Spannungsversorgung, sondern versorgt nur die angeschlossenen Geräte mit Strom. Anfangs stand uns nur dieses Gerät als Spannungsversorgung zur Verfügung. Wir konnten die Geräte zwar anschalten und auch in der ETS-Software sehen, jedoch nicht programmieren. Erst mit Hilfe des Hersteller-Supports, den wir erst nach 3 Tagen erreichen konnten, wurde uns der Fehler bewusst. Daraufhin musste die Spannungsversorgung MDT STV-0640.01 mit separater Bus-Spannung angeschafft werden. |
|||
2. Schritt: |
|||
[[File:KNX-Versuchsaufbau-2.jpg|thumb|center|KNX-Versuchsaufbau Schritt 2]] |
[[File:KNX-Versuchsaufbau-2.jpg|thumb|center|KNX-Versuchsaufbau Schritt 2]] |
||
3. Schritt: |
|||
[[File:KNX-Versuchsaufbau-3.jpg|thumb|center|KNX-Versuchsaufbau Schritt 3]] |
[[File:KNX-Versuchsaufbau-3.jpg|thumb|center|KNX-Versuchsaufbau Schritt 3]] |
||
4. Schritt: |
|||
[[File:KNX-Versuchsaufbau-4.jpg|thumb|center|KNX-Versuchsaufbau Schritt 4]] |
[[File:KNX-Versuchsaufbau-4.jpg|thumb|center|KNX-Versuchsaufbau Schritt 4]] |
||
5. Schritt: |
|||
[[File:KNX-Versuchsaufbau-5.jpg|thumb|center|KNX-Versuchsaufbau Schritt 5]] |
[[File:KNX-Versuchsaufbau-5.jpg|thumb|center|KNX-Versuchsaufbau Schritt 5]] |
||
6. Schritt: |
|||
[[File:KNX-Versuchsaufbau-6.jpg|thumb|center|KNX-Versuchsaufbau Schritt 6]] |
[[File:KNX-Versuchsaufbau-6.jpg|thumb|center|KNX-Versuchsaufbau Schritt 6]] |
||
[[File:KNX-Versuchsaufbau-7.jpg|thumb|center|KNX-Versuchsaufbau Schritt 7]] |
[[File:KNX-Versuchsaufbau-7.jpg|thumb|center|KNX-Versuchsaufbau Schritt 7]] |
Revision as of 01:25, 8 November 2015
Komponenten
Aktoren
Schaltaktor
[Text]
Dimmaktor
[Text]
Spannungversorgung
IP-Gateway
[Text]
Sensoren
Adressierung
Physikalische Adressen
[Aufbau und Funktion der Adressen]
Gruppenadressen
Versuchsaufbau
KNX-Komponenten
Am Anfang unseres Versuchsaufbaus werden wir die einzelnen KNX-Komponenten miteinander verbinden und mit Hilfe der ETS-Software programmieren. Das KNX-Modell sieht wie folgt aus.
Im Zentrum des Modells steht der KNX-Bus, mit dem alle KNX-Komponenten verbunden sind. Einige der Komponenten wie der Dimmer-Aktor brauchen eine separate Stromversorgung und werden im Modell mit einem gelben Blitz gekennzeichnet.
Bemerkung: Der naive Ansatz wäre hier, zuerst das KNX-Modell vollständig zu realisieren und dann mit der Programmierung zu beginnen. Da aber keiner in unserer Gruppe ein KNX-Experte war und wir auch die ersten waren, die dieses Workshop-Thema bearbeitet haben, ging viel Zeit für "try-and-error"-Prozesse drauf. Im Nachhinein empfehlen wir Anfänger eine "step-by-step"-Vorgehensweise. Das bedeutet, dass wir jedes Gerät einzeln in den KNX-Bus aufnehmen und mit der ETS-Software einrichten. Denn falls etwas nicht funktionieren sollte, ersparen wir uns die Fehlersuche im ganzen System.
1. Schritt:
Die erste Komponente in unserem KNX-System ist die Spannungsversorgung MDT STV-0640.01 (links im Bild). Dieser wird benötigt, um das KNX-Netz mit Gleichstrom (gelb/weiß-Anschluss) zu versorgen. Die Installation soll laut Betriebsanleitung nur von ausgewiesenem Fachpersonal durchgeführt werden. Da niemand von uns Elektriker war, half uns unser Kursleiter hier weiter. Der dunkelgrau/rot-Anschluss versorgt die KNX-Komponeten mit einer Bus-Spannung, auf welche Informationen ausgetauscht werden. Die Spannungsversorgung--Komponenten müssen nicht programmiert werden.
Bemerkung: Auf der rechten Seite im Bild haben wir ebenfalls eine Spannungsversorgung vom Modell MDT STV-0024.01. Dieser besitzt jedoch keine Bus-Spannungsversorgung, sondern versorgt nur die angeschlossenen Geräte mit Strom. Anfangs stand uns nur dieses Gerät als Spannungsversorgung zur Verfügung. Wir konnten die Geräte zwar anschalten und auch in der ETS-Software sehen, jedoch nicht programmieren. Erst mit Hilfe des Hersteller-Supports, den wir erst nach 3 Tagen erreichen konnten, wurde uns der Fehler bewusst. Daraufhin musste die Spannungsversorgung MDT STV-0640.01 mit separater Bus-Spannung angeschafft werden.
2. Schritt:
3. Schritt:
4. Schritt:
5. Schritt:
6. Schritt:
[Schematische Zeichnung]
ETS
RaspberryPi
Nachdem wir die KNX-Komponenten miteinander verbunden und mit der ETS-Software programmiert haben, werden wir uns nun mit der Einrichtung des „SmartHome-Servers“ beschäftigen. Die Anforderungen an so einem Server sind in erster Linie ein niedriger Stromverbrauch, schnelle Reaktionszeiten, Platzsparsamkeit und möglichst niedrige Anschaffungskosten.
Das Raspberry Pi 2 Model B ist für unseren Anwendungszweck sehr gut geeignet. Als Betriebssystem verwenden wir die aktuelle Version „Raspbian Wheezy“, dass man sich auf der Homepage (https://www.raspberrypi.org/downloads/raspbian) herunterladen kann.
Um das Image auf die Speicherkarte zu schreiben und bootfähig zu machen, haben wir das Programm „Win32 Disc Manager“ (http://sourceforge.net/projects/win32diskimager - Windows) verwendet.
Bemerkung: Als Speichermedium verwenden wir eine microSD-Speicherkarte. Die Verwendung einer Marken-Speicherkarte mit guten Lese- und Schreibwerten wird dringend empfohlen. Die erste Installation auf einer no-name microSD uns nach einigen Tagen intensiver Nutzung leider kaputt. Das System stürzte häufig ab und wollte dann gar nicht mehr booten. Nach der zeitaufwendigen Neuinstallation auf eine Samsung Evo MicroSD lief das System dann flüssig und fehlerfrei. Der Speicherplatz von 8GB reicht im Grunde aus.
Nach dem Aufspielen des Images auf die Speicherkarte, wird diese in den Raspberry Pi eingesteckt, zusätzlich schließen wir einen Monitor per HDMI sowie eine Tastatur und Maus per USB an, bevor der Raspberry Pi angeschaltet wird. Nach dem ersten Hochfahren erscheint ein Menü, wo wir verschiedene Einstellungen vornehmen können.
Wichtig sind hier folgende Punkte:
1. Speicher auf komplette Karte erweitern.
2. [Optional] Eigenes Passwort setzen, default: username=pi; password=raspberry.
3. [Optional] Booten in Desktop-Mode, falls man nicht alles per Remote-Kommandozeile machen will.
4. Die richtige Zeitzone, Sprache und das Tastaturlayout sollte ausgewählt werden.
Bemerkung: Das o. g. Konfigurationsmenü könnt ihr später mit folgendem Befehl „sudo raspi-config“ im Terminal wieder aufrufen.
Auf der Desktop des Raspberry Pi angelangt, überprüfen wir, ob eine gültige Netzwerkverbindung per angeschlossenem LAN-Kabel besteht. Ein WLAN-Modul wäre hier alternativ auch möglich. Die IP-Adresse des Raspberry Pi kann über den Router ermittelt werden oder wir geben im Terminal den Befehl „sudo ifconfig“ ein. Die IP-Adresse sollte möglichst statisch gesetzt werden, um einfacher per SSH auf den Raspberry Pi zugreifen zu können, bzw. später auf unseren SmartHome-Webinterface. Für den Versuchsaufbau haben wir uns eine feste IP-Adresse vom Informatik-Institut geben lassen, an dem der Raspberry Pi dauerhaft angeschlossen war.
Nachdem wir den Raspberry Pi frisch aufgesetzt haben, laden wir uns die aktuellsten Softwarepakete und die aktuellste Firmware herunter:
sudo apt-get updatesudo apt-get upgrade sudo rpi-update
Anschließend starten wir den Raspberry Pi neu. Soweit haben wir alles Notwendige getan, um den Raspberry Pi als SmartHome-Server bereit zu tellen. Im nächsten Schritt werden wir uns der Installation der SmartHome Applikation OpenHAB widmen.
Openhab
Open Home Automation Bus (OpenHAB) ist eine Open Source Softwareplattform, die als Steuerzentrale für Komponenten zur Gebäudeautomatisierung von verschiedenen Herstellen dient. Es basiert auf dem Eclipse-Smart-Home Projekt und wird ständig weiterentwickelt. Die Entwickler sind bemüht die Konfiguration und die Bedienoberfläche benutzerfreundlich zu gestalten, trotzdem ist dieses System im Hinblick auf den Endkonsumentenbereich eher etwas für technikaffine Nutzer.
OpenHAB basiert auf Java, daher müssen wir prüfen, ob die neuste Java-Version auf den Raspberry Pi installiert ist. Diese ist standardmäßig im Raspberry-Wheezy Paket mit enthalten und kann wie folgt abgefragt werden:
sudo java –version
Eine manuelle Java-Installation kann wie folgt angestoßen werden.
sudo apt-get install oracle-java7-jdk
Nun machen wir uns an die Installation von OpenHab ran. Die aktuellsten Pakete findet ihr auf der Homepage von OpenHAB.
http://www.openhab.org/getting-started/downloads.html
Install OpenHAB Runtime
Als erstes erstellen wir uns einen Ordner, wo die Installation gespeichert werden soll und wechseln anschließend in diesen.
sudo mkdir /opt/openhab
cd /opt/openhab
Durch den folgenden Befehl laden wir das OpenHAB-Paket herunter.
sudo wget https://bintray.com/artifact/download/openhab/bin/distribution-1.7.1-runtime.zip
Bemerkung: Bei unserem Versuchsaufbau war die Version 1.7.1 die aktuellste. Neuere Versionen müssen ggf. in den Links ergänzt werden.
Anschließend entpacken wir die Archiv-Datei. Achtet darauf, dass Ihr euch immer noch im gleichen Ordnerverzeichnis befindet (hier: /opt/openhab).
sudo unzip distribution-1.7.1-runtime.zip
Die Archiv-Datei wird nun nicht mehr benötigt und kann entfernt werden.
sudo rm distribution-1.7.1-runtime.zip
Damit der OpenHAB-Dienst bei jedem Hochfahren automatisch startet, führen wir folgenden Befehl aus.
sudo update-rc.d openhab defaults
Für die manuelle Ausführung stehen folgende Befehle bereit.
sudo /etc/init.d/openhab start
sudo /etc/init.d/openhab stop
sudo /etc/init.d/openhab restart
sudo /etc/init.d/openhab status
Install OpenHAB Binding
Als nächstes müssen wir die Binding-Pakete installieren. Diese sind notwendig, damit OpenHAB über das HTTP-Protokoll mit den angeschlossenen Komponenten der Hausautomatisierung kommunizieren kann. Auf der OpenHAB-Homepage finden wir die Binding-Pakete unter "Addons". Um diese Paket auf unseren Server runter zu laden, wechseln wir in den Ordner Addons.
cd /opt/openhab/addons
und führen folgenden Befehl aus.
sudo wget https://bintray.com/artifact/download/openhab/bin/distribution-1.7.1-addons.zip
Die Archiv-Datei wird entpackt und kann anschließend wieder gelöscht werden.
sudo unzip distribution-1.7.1-addons.zip
sudo rm distribution-1.7.1-addons.zip
Bemerkung: Wenn wir nun in den Ordner "Addons" schauen, sehen wir, dass auch ein Binding-Paket für KNX-Geräte existiert. Hier sei nochmal darauf hingewiesen, dass die Bindings von der OpenHAB-Homepage wie oben beschrieben, verwendet werden sollten, da diese auf den aktuellsten Stand sind. Wir hatten bei unserem Versuchsaufbau gemäß eines Online-Tutorials die Bindings aus einem Github-Repository herunter geladen. Obwohl dieser auch ein KNX Binding-Paket beinhaltete, konnten wir einige KNX-Geräte wie den Taster nicht ansteuern. Auch diese Erkenntnis hatte uns viel Zeit und Nerven gekostet. Wahrscheinlich war das Paket nicht mehr aktuell gewesen.
Nun kopieren wir die OpenHAB Konfigurationsdatei. Alle zukünftigen Einstellungen schreiben wir in die „openhab.cfg“-Datei.
sudo cp configurations/openhab_default.cfg configurations/openhab.cfg
Jetzt wir starten den Raspeberry Pi neu. Nach dem Neustart überprüfen wir nochmal, ob der Dienst von OpenHAB auch wirklich automatisch gestartet wurde.
sudo /etc/init.d/openhab status
Im Grunde sind wir hier mit der Installation fertig. Über den folgenden Link könnt ihr auf das OpenHAB-Webinterface zugreifen.
http://localhost:8080/openhab.app?sitemap=<sitemapname>
Install OpenHAB Demo-Setup
Da wir in unserem Sitemap-Ordner /opt/openhab/configurations/sitemaps noch keine Vorlage haben, wird auf dem Webinterface auch nichts „sinnvolles“ angezeigt. Wir verweisen hier wieder auf die OpenHAB-Homepage, von wo ihr euch ein vorgegebenes Demo-Setup herunterladen könnt.
sudo wget https://bintray.com/artifact/download/openhab/bin/distribution-1.7.1-demo.zip
Entpackt das Archiv-Paket auf die OpenHAB Runtime-Version unter /opt/openhab und löscht anschließend wieder das Archiv-Paket. Die Befehle dafür solltet ihr ja mittlerweile kennen. :)
In eurem Sitemap-Ordner /opt/openhab/configurations/sitemaps sollte nun eine Datei „demo.sitemap“ vorhanden sein.
Ruft nun die OpenHAB Weboberfläche mit der Demoseite auf.
http://localhost:8080/openhab.app?sitemap=demo
Die Weboberfläche sollte wie folgt aussehen.
Der Aufruf über ein Smartphone oder Tablet bietet dem Nutzer eine angepasste Interface für mobile Geräte.
Angriffe auf das KNX-System
DOS-Angriff (IP-basiert)
DOS-Angrif (via KNX-Bus)
Alle Teilnehmer eines KNX-Netzwerks sind über zwei Drähte miteinander verbunden, über welche jeweils Gleichstrom fließt, der sogenannte Busstrom. Diese zwei Drähte sind zum einen der Plus- und zum anderen der Minuspol. Werden diese verbunden, ergibt dies einen Kurzschluss, wodurch keine Telegramme mehr verschickt werden können. Die Fehlersuche ist dann sehr aufwändig.
Paketreplay aus internem Netzwerk
Busmanipulation
Die KNX-Buskommunikation erfolgt unverschlüsselt. Damit kann jeder Teilnehmer Telegramme vom Bus lesen und auch schreiben. Das ist solange kein Problem, wenn keiner der Teilnehmer ausgetauscht werden kann. Wird ein Teilnehmer, zum Beispiel ein Taster durch ein IP-Gateway ausgetauscht, kann dieser wie jeder andere Teilnehmer auch die Telegramme vom Bus lesen und auch Telegramme auf dem Bus schreiben. Die Geräte müssen sich in dem Netzwerk nicht authentifizieren. Das ist besonders bei der Gebäudeautomatisierung mit Außenanlagen problematisch. Dort kann ein Angreifer einen Taster oder einen Sensor durch ein IP-Gateway austauschen. Dieses IP-Gateway verbindet der Angreifer via Ethernet mit einem mobilen PC. Danach kann er direkt mit der ETC-Software die Aktivitäten auf dem Bus auslesen und auch eigene Telegramme hinzufügen. Ist das interte Netz innerhalb des Gebäudes nicht vom Äußeren des Gebäudes abgegrenzt, können dann Schaltungen im Gebäude druchgeführt werden. Da oft viele Teilnehmer mit dem KNX-Bus verbunden sind, könnten auch sicherheitsrelevante Teilnehmer wie Alarmanlagen deaktiviert werden.