Hausbus

Wechseln zu: Navigation, Suche

Anforderungen[Bearbeiten]

Zentral/Dezentral[Bearbeiten]

Grundsätzlich kann so eine Steuerung zentral oder dezentral arbeiten (wobei natürlich auch Mischformen denkbar sind).

Zentral[Bearbeiten]

Beim zentralen Ansatz gibt es einen Master, der zyklisch alle Sensoren (Thermometer, Lichtschalter, usw.) abfragt und dann die entsprechenden Aktionen auslöst.

+ wenig Intelligenz bei den Sensoren/Aktoren nötig
+ bei Konfigurationsänderungen keine Änderungen bei den Sensoren/Aktoren nötig.
+ keine Multimasterfähigkeit nötig
- je mehr Sensoren vorhanden sind, desto länger dauert ein Abfragezyklus. Da so ein selbst gebauter Hausbus ja auch Raum für Erweiterungen bieten soll, sollte man schon mit 100-200 Sensoren rechnen (Lichtschalter, Thermometer, Glasbruchsensoren, Rauchmelder usw. usf)
- Wenn die Zentrale ausfällt, dann fällt die gesamte Steuerung auf einmal aus

Anmerkung: Falls, wie im dezentralen Fall die Sensoren von sich aus Zustandsänderungen melden, aber die Nachrichten nur an den Master schicken, entfällt der Nachteil durch das Polling. Dafür muss der Master allerdings asynchron eintreffende Nachrichten verarbeiten können (das kommt dann als Erschwernis dazu).

Dezentral[Bearbeiten]

Beim dezentralen Ansatz senden die Sensoren (z. B. Lichtschalter) Botschaften an die Aktoren (z. B. die Glühlampe).

+ Die Buslast hängt von der Anzahl Ereignisse ab und nicht von der Anzahl Sensoren. Ein Glasbruchsensor, der nie aktiv wird, verursacht auch keine Buslast.
+ Keine Schaltzentrale nötig (also kein Single Point of Failure)
- Multimasterfähigkeit bei allen Sendern (also allen Sensoren) nötig.
- Konfigurationsänderungen müssen immer an den entsprechenden Aktoren/Sensoren gemacht werden. Dazu muss man sie entweder fernkonfigurieren können oder mit dem Konfigurationsgerät direkt an die jeweiligen Geräte.

Geschwindigkeit[Bearbeiten]

Solange man nur ein einzelnes Wohnhaus (und nicht etwa eine Schule oder eine Fabrik) ausrüsten will und nur die üblichen Sensoren/Aktoren hat, ist praktisch jeder Bus schnell genug. Andererseits erlauben RS485 und der CAN-Bus bei den in einem Haus vorkommenden Kabellängen auch durchaus Geschwindigkeiten von 1 MBit/s, wodurch man auch andere Anwendungen damit realisieren könnte.

--> Hohe Geschwindigkeit heißt höherer Aufwand und höhere Kosten <--

Ein Hausbus sollte deshalb in der Geschwindigkeit auf die notwendigen Bedürfnisse abgestimmt sein. Folgende Rechnung lässt sich aufmachen: Ein Frame mit einem einfachen Event z. B. "Taste 4 des Moduls 0x2007 gedrückt" lässt sich mit allem Nötigen wie Priorität, Parity-Bits Anzahl Datenbytes und Checksumme in 6 "Byte" à 10 Bit verpacken. Bei einer Geschwindigkeit von nur 10 kHz dauert die Übertragung ca. 6 ms. Erlaubt man pro Frame max. 12 Datenbyte, ergeben sich 18 ms. Wobei 12 Datenbyte eigentlich nur zur Konfiguration der Knoten nötig sind. Uhrzeit, Datum, Temperaturen usw. kann man meistens mit 2 - 4 Datenbyte melden. Da mit der CAN-Topologie kollisionsfrei Daten übertragen werden und ein Hausbus im Allgemeinen keiner hohen Belastung unterliegt, ist es realistisch sonstige Verzögerungen zu vernachlässigen. Ich habe in meinem Fünf-Personen-Haushalt den Bus nach "Bus-belegt-Verzögerungen" gescannt und in drei Monaten vier dieser Ereignisse festgestellt. Das bedeutete 12 ms anstatt der erwähnten 6 ms.

Warum sollte man schneller werden, wenn eine Verzögerung von 200 ms in der Realität nicht festgestellt wird. Die Verzögerung einer Leuchtstofflampe empfinde ich da schon eher als störend.

Sollten wir eine Schule mit solch einem Bus betreiben und 166 Kinder stürmen in die Pause und betätigen dann alle einen Taster, verzögert sich das letzte Ereignis um nicht ganz eine Sekunde.

Vergleich von Hausbussystemen[Bearbeiten]

(es gibt auch noch DALI für Lichtsteuerung epanorama)

NRF24L01[Bearbeiten]

+ keine Leitungen
+ sehr günstig, geringe Kosten pro Knoten
+ multimasterfähig
+ übertragungssicher (d.h. bei Übertragungsfehler werden Daten automatisch wiederholt)
+ Herstellerunabhängig
+ fertige Funkmodule mit 8-Pin-Steckverbindung erhältlich
+ über USB-Dongle vom PC ansteuerbar
o Protokoll zum Teil bereits im Chip (Beaconing und Vermaschung muss selbst programmiert werden)
- keine genormten Hausbus-Protokolle

Diskussion im Thread NRF24L01+ als Hausbus

EIB / KNX[Bearbeiten]

+ nur 2 Leitungen für Daten, Power und GND
+ kein Abschluss-R nötig, alle Bustopologien
+ multimasterfähig
+ übertragungssicher (d.h. bei Übertragungsfehler werden Daten automatisch wiederholt)
+ Herstellerunabhängig (eine Vielzahl von Herstellern bieten Komponenten für alle erdenklichen Anwendungen)
- Chips nur schwer erhältlich und teuer
- nur industrielle Module erhältlich, kein Selbstbau
+ Freebus als Selbstbauvariante? Freebus Homepage (Deutsch)

CAN-Bus[Bearbeiten]

+ Protokoll bereits im Chip
+ multimasterfähig
+ übertragungssicher (d.h. bei Übertragungsfehler werden Daten automatisch wiederholt)
+ hohe Störsicherheit durch differentielle Übertragung
O Preis ist ausgewogen
- es werden 2 Leitungen Daten + Power + GND benötigt
- Abzweigungen vom Bus sind problematisch (max. 1 m?)
- Abschluss-R notwendig

RS-485[Bearbeiten]

+ sehr günstig
+ Schnittstellenbausteine können direkt an den USART eines Mikrocontrollers angeschlossen werden
+ Buslänge von 1200 m möglich
+ hohe Störsicherheit durch differentielle Übertragung
- Abzweigungen vom Bus sind problematisch (max. 1 m?)
- Abschluss-R notwendig
- von Haus aus nicht multimasterfähig, muss per Software realisiert werden

1-wire als Hausbus[Bearbeiten]

+/- zentrales System
+ sehr günstig
+ sehr einfache Verdrahtung
+ integrierte Peripheriebausteine erhältlich (Thermometer, I/O-Bausteine, etc.)
+ über einfaches Selbstbauinterface vom PC ansteuerbar
+ Bus kann mit Pullup-Widerstand direkt von einem bidirektionalen Microcontrollerpin angesteuert werden
+ professionelle Softwareinterface frei erhältlich (unterstützt bis zu acht Busleitungen)
+ mit einfachem Pullup-Widerstand maximal 200 m Buslänge zulässig
+ mit aufwendigerem aktiven Pullup maximal 500 m Buslänge zulässig
+ integrierte Interfaceschaltungen für I²C, USB und Serielle Schnittstelle erhältlich
+ ausführliche Darstellung zur Buslänge in Appnote 148 verfügbar
+ Peripherie ohne separate Spannungsversorgung möglich
+ umfangreiche Herstellerunterstützung durch technische Dokumente
- nicht multimasterfähig
- max. 75 Bausteinabfragen/s
- Peripherieschaltungen nur als integrierte Bausteine erhältlich
- in Software realisierte Peripherie verstößt gegen US-Patente
- keine differentielle Übertragung, dadurch deutlich störanfälliger
- keine genormte Kabel- und Steckerbelegung

I²C als Hausbus[Bearbeiten]

+ billig
+ multimasterfähig
+ viele direkt anschließbare Slave-Bausteine vorhanden
+ mit Treiber IC Kabellängen von 100m und mehr möglich
- differentielle Übertragung nur mit Mehraufwand möglich
- ohne differentielle Übertragung störanfällig
- ohne Treiber IC nur Kabellängen unter 10 m möglich
- als "Inter-IC-Bus" zur Anwendung innerhalb von Geräten konzipiert

Ethernet[Bearbeiten]

+ multimasterfähig
+ sehr schnell
+/- mit TP-Kabel (100Base-T) Sternstruktur, Leitungslänge bis 100 m
+/- mit Koaxkabel (10Base-2) Busstruktur, Leitungslänge bis 185 m
+ Verkabelung und Stecker sind genormt
- aufwändig anzusteuern (hoher Hardware- und Softwareaufwand)
- (teuer) d.h. für Selbstbau aufwendig
- (hoher Stromverbrauch des TCP/IP Treibers/PHY-ICs)

Powerline[Bearbeiten]

+ Nachrüstbar (keine zusätzliche Verdrahtung erforderlich)
+ nutzt vorhandene Netzinstallation
- erzeugt ein breitbandiges Störspektrum (nur bei dLan), das über die Netzinstallation unkontrolliert abgestrahlt wird
- kann Funkbetrieb, insbesondere im Kurzwellenbereich, stören (bei Powerline im 125kHz-Bereich sind Störungen des Kurzwellenfunks ausgeschlossen)
- funktioniert ohne Phasenkoppler nur auf gleichen Phasen (Phasenkoppler besteht aus drei Kondensatoren)
- Netzteile mit vernünftigen EMI-Filter filtern auch das PL-Signal (hinter Netzteilfiltern wird meist kein Bus-Signal mehr benötigt)
- geringe Übertragungsrate (ohne breitbandige Störspektren zu erzeugen)
- Modems werden im Störungsfall von der RegTP außer Betrieb genommen und werden dadurch wertlos (VDE Konformität erforderlich, Layout anspruchsvoll - Labortests?)
- Kann von Energiesparlampen bzw von deren Vorschaltgeräte gestört werden (moderne Transceiver ICs sind relativ störsicher. Aber: Kosten)
- Netzspannung! (es gelten nicht mehr allein Niederspannungsrichtlinien)

LON[Bearbeiten]

LCN[Bearbeiten]

+ Nur ein Draht zusätzlich zu 230V-Leitungen notwendig

HS485[Bearbeiten]

von ELV

+ Verwendet RS-485-Standard
+ Günstige Komponenten erhältlich, allerdings nur noch Restposten
+ Eigenbau möglich, da Protokoll dokumentiert
- Wird nicht mehr aktiv weiter entwickelt (Nachfolger: HomeMatic, allerdings inkompatibel)

HomeMatic[Bearbeiten]

Homepage

+ Es gibt Funk- und RS485-Komponenten (HomeMatic Wired), die auch gemeinsam eingesetzt werden können
+ Das Wired-Protokoll ist teilweise dokumentiert, ein Nachbau von Komponenten ist möglich. [1]
- Komponenten nur von einem Anbieter

HomeMatic Wired Protokoll ist (inkompatibler) Nachfolger von HS485 (ELV) [2]

Qbus[Bearbeiten]

Homepage

+ Zwei Leitungen reichen für Daten und Stromversorgung der Komponenten
+ Busleitungen verpolungssicher
- Zentrale nötig
- Komponenten nur von einem Anbieter

RWE SmartHome[Bearbeiten]

Homepage

+ Keine Leitungen nötig

Dupline[Bearbeiten]

Homepage

+ Kommt mit zweipoligem Kabel aus
+ Stromversorgung der Busgeräte über den Bus
+ Einfaches Protokoll, sollte leicht nachzuprogrammieren sein für eigene Erweiterungen
+ Garantierte Antwortzeiten / Raktionszeiten (Echtzeit-System)
- Weniger Flexibilität als andere Bussysteme

Links[Bearbeiten]

Forum[Bearbeiten]

Allgemein[Bearbeiten]

CAN[Bearbeiten]

EIB / KNX[Bearbeiten]

RS485[Bearbeiten]

Ethernet[Bearbeiten]

Powerline[Bearbeiten]

EnOcean[Bearbeiten]

Sonstiges[Bearbeiten]