Hausbus

Aus der Mikrocontroller.net Artikelsammlung, mit Beiträgen verschiedener Autoren (siehe Versionsgeschichte)
Wechseln zu: Navigation, Suche

Anforderungen

Zentral/Dezentral

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

Zentral

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

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

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

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

NRF24L01

+ 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

+ 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

+ 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

+ 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

+/- 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

+ billig
+ multimasterfähig
+ viele direkt anschließbare Slave-Bausteine vorhanden
+ einfaches Übertragungsprotokoll
+ mit Treiber IC und/oder anderen Modifikationen Kabellängen von 100m und mehr möglich
- differentielle Übertragung nur mit Mehraufwand möglich
- ohne differentielle Übertragung, daher störanfällig
- ohne Treiber IC nur Kabellängen unter 10 m möglich (bei 400kHz)
- als "Inter-IC-Bus" zur Anwendung innerhalb von Geräten konzipiert

Ethernet

+ multimasterfähig
+ sehr schnell
+ Stromversorgung über Datenleitung möglich, mittels Power over Ethernet / PoE (802.3af-2003)
+/- mit TP-Kabel (100Base-T) Sternstruktur, Leitungslänge bis 100 m
+/- mit Koaxkabel (10Base-2) Busstruktur, Leitungslänge bis 185 m
+/- mit einer ungeschirmten, verdrillten Zweidrahtleitung (100Base-T1 / BroadR-Reach) Sternstruktur, Leitungslänge 15m. Auch kombinierbar mit PoE. Es werden spezielle BroadR-Switche benötigt. Ein BroadR-Netz kann mittels Media Converter in normale 100Base-T-Netze eingebunden werden.
+ Verkabelung und Stecker sind genormt
- aufwändig anzusteuern (hoher Hardware- und Softwareaufwand)
- Im Selbstbau aufwändig und teuer: Mikrocontroller mit (R)MII-Schnittstelle notwenig. Zusätzlich Physical Layer Chip mit Peripherie und relativ teuerer Buchse mit Übertragern benötigt. Layout ebenfalls aufwändig und fehlerträchtig. Benötigte Bauteile oftmals nur als SMD-Variante erhältlich.
+ Viele fertige Klein-/Kleinstcomputer mit Ethernetschnittstelle günstig erhältlich
- hoher Stromverbrauch des Physical Layer Chips

Powerline

z.B. X10, PLC-Bus

+ 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

LCN

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

HS485

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)

Modbus

+ verwendet RS-485-Standard
+ viel Hardware aus dem Industriebereich verfügbar
+ Eigenbau sehr leicht möglich, es sind freie Implementierungen für viele gängige Mikrocontroller verfügbar
+ offenes Protokoll
+ seit Jahrzehnten standardisiert, wird vermutlich noch lange existieren
- benötigt immer einen Busmaster, zB. openHAB, eine SPS oder eine eigene Lösung auf Mikrocontroller- oder PC-basis

HomeMatic

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

Homepage

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

RWE SmartHome

Homepage

+ Keine Leitungen nötig

Dupline

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

SmartBUS G4

Homepage Protokollbeschreibung Befehlssatz

Basiert auf RS-485
+ Offenes, aber patentiertes Protokoll
+ Sehr umfangreiches Produktprogramm
- Nur ein Hersteller

Yakko

Homepage - Der Link auf das „Hardware“-PDF funktioniert nicht. Die Hardware-Beschreibung ist im Protokoll-PDF enthalten.

Basiert auf RS-485
+ Open Source
+ Ausführliche Dokumentation
- Projekt scheint seit Ende 2007 nicht mehr betreut zu sein

Link Network Protocol via RS-485

SENG digitale Systeme - Nachrichtenbasierten Netzwerk-Protokoll auf Basis von Punkt zu Punkt RS-485 Übertragungsstecken

Eckdaten:

+ alle Teilnehmer sind gleichberechtigt, kein Token, kein Polling
+ übertragungssicher (d.h. bei Übertragungsfehler werden Daten automatisch wiederholt)
+ Installation und Betrieb ohne Vergabe einer Busadresse oder Installation eines Busabschlusses
+ Netzwerktopologie kann als Linie, Ring oder Baum ausgeführt werden
+ eine hohe Anzahl von Netzwerkteilnehmern ist möglich
+ Abstand zweier Teilnehmer kann bis zu 1000m bei 115200 bit/s Übertragungsrate betragen
+ vollständig RS-485 konforme, robuste Übertragungsstrecken
+ Kommunikation belastet den Mikrocontroller (mit DMA) kaum
+ einfache Lokalisierung eines defekten Knotens oder einer defekten Übertragungsstrecke
+ Adressierung einzelner Knoten, von Gruppen oder Gerätetypen ist möglich
+ innerhalb eines Netzwerkes Betrieb von Übertragungsstrecken mit unterschiedlichen Übertragungsraten
+ keine speziellen Halbleiter notwendig
+ integrierter USB Anschluss / Access point im Netzwerkknoten
+ Software Development Kit und Demo-Baugruppe (ARM Cortex-M3 MCU) verfügbar
+ komfortable und kostenfreie Entwicklungsumgebung (für ARM Cortex-M3) verfügbar
+ nicht kommerzielle Nutzung ist kostenfrei möglich
+ offengelegte Spezifikation
+ Anwendungsgebiete: Steuerungstechnik, Gebäudeautomation, ...
- bei kommerzieller Anwendung Kosten für Registrierung (einmalig 99€) und Lizenzgebühren pro Netzwerkknoten (ca. 0,05€)
- nur ein Anbieter (Stand Juni 2014)

Links

Forum

Allgemein

CAN

EIB / KNX

RS485

Ethernet

Powerline

EnOcean

Link Network Protocol via RS-485

Sonstiges

Abgerufen von „https://www.mikrocontroller.net/index.php?title=Hausbus&oldid=104781“