Ein Kunde hat uns Einblicke in seine selbst aufgebaute Hausautomation gegeben, die seit mehreren Jahren stabil im Einsatz ist. Die Lösung basiert auf einem Raspberry Pi in Kombination mit I²C-Baugruppen und der CODESYS-Laufzeitumgebung.
Vielen Dank an Alexander für die ausführliche Beschreibung und die Bilder!
Übersicht
Die Steuerung besteht aus:
- Raspberry Pi 3B+ als zentrale SPS
- Multiplexer zur Erweiterung des I²C-Busses
- 16 digitale Eingänge und 16 digitale Ausgänge
- 2 Analogkarten mit je 4 Ausgängen
- Dezentralen Ein-/Ausgangsmodulen im Dachgeschoss
Die Außenposten sind aktuell über einen I²C-Extender angebunden. Die Leitungslängen betragen etwa 12 bis 15 Meter. Ein Leitungstreiber für größere Distanzen ist bereits vorhanden, aber noch nicht im Einsatz.
Keller:
- „RPI_und_i2HSx_ext“: Raspberry Pi (3B+) mit Multiplexer
- „Ausgaenge_I2HA“ / „Eingaenge_I2HE“: jeweils 16 IO-Karten
Dachgeschoss:
- „entfernte_I2HE_und_I2HA“: Außenposten mit je zwei Ein- und Ausgängen
Steuerung
Schaltschrank
Im Schaltschrank laufen alle Fäden zusammen: Hier befinden sich Raspberry Pi, I²C-Module und die gesamte Steuerungstechnik der Anlage.
Da die Adressen der Analogkarten nicht mit denen der Digitalkarten überlappen, habe ich sie parallel zum Multiplexer angeschlossen.
I2C-Master
Als SPS setze ich die Multi-Core-Laufzeitumgebung von Codesys ein, ohne die die Mehrkernfähigkeit bislang zu nutzen.
Eingänge
Insgesamt sind 16 digitale Eingangskarten über einen Multiplexer angeschlossen.
Ausgänge
Über 16 digitale Ausgangskarten, die ebenfalls über einen Multiplexer angeschlossen sind, werden die Aktoren im Haus geschaltet.
Architektur und Besonderheiten
Statt der SPS-eigenen Treiber verwende ich ausschließlich Ihre Funktionsbausteine, auch für den Multiplexer. Für die Analogbausteine sind sie meines Erachtens zwingend erforderlich, da diese empfindlich auf zu kurze Ansteuerintervalle reagieren.
Mit den Funktionsbausteinen lassen sich diese Intervalle einfach programmatisch anpassen, wogegen man bei den Treibern zunächst an die -hierfür zu kurzen- Standardzyklen der SPS gebunden ist. Ob sich diese anpassen lassen, habe ich seit der Umstellung auf Funktionsbausteine nicht weiter untersucht.
Im Multiplexbetrieb bieten die FBs auch bei den Digitalkarten, die mit den SPS-Treibern grundsätzlich problemlos laufen, Vorteile, da der der Zugriffszeitpunkt gezielt gesteuert werden kann.
Warum Funktionsbausteine statt Treiber?
Die Steuerung nutzt ein zentrales „Master-Control-Programm“ (MCP), das den gesamten Ablauf organisiert.
Der Ablauf ist wie folgt:
- Aktivierung eines Multiplexer-Kanals
- Einlesen aller Eingänge
- Schreiben aller Ausgänge
- Wechsel zum nächsten Kanal
- Nach Abschluss aller Kanäle: Ausführung der Steuerlogik
Danach beginnt der Zyklus erneut.
Vorteil:
- gezielte Steuerung der Zugriffszeitpunkte
- stabile Kommunikation auch im Multiplexbetrieb
Anfangs hatte ich mit einer Ablaufsteuerung experimentiert, um die IO-Verarbeitung darüber zu organisieren. Das in Structured Text (ST) implementierte MCP hat sich jedoch als so flexibel und zuverlässig erwiesen, dass ich davon nicht mehr abweichen möchte.
Anwendungen
Die erste Anwendung war die Steuerung der Haus-Zwangsbelüftung. Die Papst(*)-Lüfter werden über eine Gleichspannung von 0 bis 5V angesteuert. Diese Lösung läuft seit Jahren stabil; anfängliche Abstürze der Analogkarten konnten durch die Verwendung der Funktionsbausteine und längere Ansteuerintervalle vollständig behoben werden.
Ich habe gesehen, dass sie bei Ansteuerung der EBM-Papst-Lüfter andere OPs empfehlen, vermutlich wegen der Rail2Rail-Eigenschaften.
Bei „meinen“ Lüftern (ist ein Set der Firma Sevi) ist das anscheinend nicht nötig, vermutlich, weil ich nicht bis auf 0 Volt runtergehen muss.
Die Lüftersteuerung ist teilweise noch in FUP bzw. CFC umgesetzt und aufgrund mangelnder Erfahrung unübersichtlich. Inzwischen nutze ich bevorzugt Structured Text und versuche, neue Automatisierungsaufgaben konsequent damit umzusetzen.
Ein weiterer wichtiger Anwendungsfall ist die Brauchwassererwärmung über Überschussstrom mittels Heizstab. Zwar bietet der Wechselrichter hierfür eine eigene Funktion, die SPS ermöglicht jedoch deutlich flexiblere Lösungen.
Darüber hinaus dient die SPS als Schnittstelle zur Datenerfassung (Gaszähler, Briefkasten, Fensterkontakte, Steckdosen, Beleuchtung etc.) sowie allgemein zur „Smartifizierung“ des Hauses. Praktisch ist beispielsweise die Steuerung von Licht und Rollläden per Smartphone.
Node-RED ist ebenfalls integriert und ersetzt zunehmend die Codesys-Visualisierung. Die Kommunikation erfolgt über Modbus.
Fazit
Die Anlage läuft seit über 4 Jahren stabil im Dauerbetrieb.
Besonders hervorzuheben:
- robuste I²C-Kommunikation trotz Multiplexing
- flexible Softwarearchitektur
- kontinuierliche Erweiterbarkeit
Das Projekt zeigt sehr schön, wie leistungsfähig eine Kombination aus Raspberry Pi, CODESYS und I²C-Modulen im praktischen Einsatz sein kann.