Dorfautomatisierung

Dorfautomatisierung 2019 idea
Dorfbus für die neuen Räume
Ort	neuer / alter Hackerspace
Beteiligt	xportdus , mraerino, timm, nomaster

Siehe auch dieses Google-Doc zu ModBus.

High-Level-Entwurf

Skizze von xportdus

Wir wollen verschiedene Busse nutzen können. Dazu gibt es pro Bus einen spezifischen Controller, der an diesem Bus hängt und (gemeinsam mit allen anderen Bus-Controllern) an einem Netzwerk. An diesem Netzwerk hängt auch der Dorf-Controller (unsere zentrale Steuerungskomponente). Einzelne Geräte (Sensoren / Aktoren) hängen an genau einem Bus.

Die Bus-Controller und der Dorf-Controller kommunizieren über das Netzwerk mit einem noch zu bestimmenden Protokoll. Dieses Protokoll erlaubt es dem Dorf-Controller den gewünschten Zustand aller Geräte an die einzelnen Bus-Controller zu kommunizieren. Diese bilden diesen Zustand dann auf ihren jeweiligen Bus ab. Zusätzlich ermöglicht dieses Protokoll den Bus-Controllern Events (z.B. Tasterdruck, Auslösen eines Bewegungsmelders, neuer Temperaturwert) an den Dorf-Controller zu kommunizieren, welcher dann daraufhin konfigurierbare Aktionen auslöst. (TODO: Wo werden Geräte hinzugefügt?)

Aber nicht alle Sensoren müssen bzw. können Events auslösen. Es gibt auch welche, die nur triviale Aktionen auf dem jeweiligen Bus auslösen können (Lichtschalter -> Licht). Diese Reaktionen erfolgen rein im Bus-Controller. Die sie auslösenden Events werden nicht an den Dorf-Controller übertragen, das Ergebnis (neuer Status der Lampe) schon.

Hardware

Der alte „Dorfbus“ setzt auf SI2C - eine Art „i2c-Standard“ auf. Gegenüber dem Original ist hier aber nur eine Übertragung vom Master (Server) zum Slave (Aktor) möglich. (Für mehr Details siehe den verlinkten Wiki-Artikel und Lichtsteuerung.)

Bedingt durch die neuen Räumlichkeiten müssen / sollten wir hier auf einen neuen echten Industriestandard umbauen, an dem auch neue Leute aktiv mitwirken können. Auch werden wir den alten Dorfbus nicht einfach an die neuen Räume anpassen können.

Welche Standards kämen da in Frage?

KNX

Im Bereich der Hausautomatisierung gibt es hier den KNX-Standard. Dieser ist aber - bedingt durch die meist recht teure Spezialhardware - eher ungeeignet.

Bei diesem Bus erfolgt die Übertragung der Daten in Richtung Aktor durch Erhöhung der Busspannung. Die Antwort erfolgt als Stromantwort seitens des Aktors. Dieses ist recht schön ersichtlich auf Seite 4 im Datenblatt unten.

Modbus

Im Bereich der Mess- und Regeltechnik und auch in größeren Objekten hat sich der „Modbus“ als Standard durchgesetzt.

Die rein elektrische Schnittstelle ist ein RS485-Bus, der nur 2 Drähte benötigt.

Über ein 4-poliges Kabel kann also sowohl die Versorgung mit Strom als auch die Datenübertragung erfolgen. Die Anbindung an den Master erfolgt über eine Standard Serielle Schnittstelle nach dem Master-Slave-Prinzip. Die Stromversorgung für die reine Steuerung kann von einer zentralen Stelle sogar Akku-gepuffert erfolgen. Dies kann hilfreich sein z.B. bei der Türsteuerung, wenn der Strom ausfällt.

Mit sehr kleinem Aufwand können auch eigene Aktoren gebaut werden. (Arduino Nano und RS484-Wandler). Dieser können dann auch LED-Anzeigen / LC-Display / Temperatur- / Feuchtefühler / Onewire-Leser / RFID-Leser / Aktoren enthalten. Der „Mitmach-“ und Bastelfaktor ist hier also ganz besonders hoch.

CAN

• CAN-Bus (Controller Area Network)
• ISO 11898-2 (Highspeed-CAN) und ISO 11898-3 (Lowspeed-CAN)
• Der CAN Bus Controller selber kümmert sich um die ganze Übertragung incl. der "Datensicherung"

Zigbee

Einfache Funktionen wie Lichtsteuerung sind natürlich auch über Zigbee möglich. Ein Vorteil hier ist das Funkmesh - damit entfällt das Verlegen von Kabeln. Es gibt zahlreiche Chips, Shields und fertige Geräte so das eigene Aktoren gebaut werden können, das meiste aber bereits günstig zu bekommen ist.

DMX

DMX ist das alternativlose Bus-System der Veranstaltungstechnik. Es gibt einen riesigen Markt an Geräten, die darüber angesteuert werden, zum Beispiel PAR-Scheinwerfer (Bühnenbeleuchtung), Fluter (flächige Beleuchtung), Nebelmaschinen (die Cave ist überall), Moving Heads (wir haben welche im Keller!).

Funktionsweise: 512 Client-Adressen auf einem dreipoligen Kabel. Geräte werden daisy-chained (hintereinander geschaltet) und belegen jeweils eine Startadresse und 0 bis n weitere Adressen, zum Beispiel für einzelne Farbkanäle bei RGBW-Leuchten. Zu jeder Adresse wird eine Einstellung zwischen 0 und 255 gesendet. Das macht man mit einem Controller. Aus elektrischer Sicht ist es auch ein RS485 Bus.

Der Controller ist ein mehr oder weniger bezahlbares Stück Hardware (Lichtpult) oder Software, die über einen DMX-Adapter mit dem Bus spricht. Dies erfolgt entweder direkt per USB-DMX-Adapter oder über das Netzwerk mit einem standardisierten Protokoll: Art-Net.

Vorschlag fürs Chaosdorf: in jedem Raum, der gestaltete Beleuchtung erhalten soll, kommt jeweils ein DMX-Bus rein, der über einen DIY-Adapter angesteuert wird (Raspberry-Pi mit DMX und PoE-Shield). Ein von uns gebauter Backend-Service spricht auf der einen Seite Art-Net zu den Controllern und auf der anderen Seite unsere Dorf-API, um die Veranstaltungs-Beleuchtung in den Rest der Technik zu integrieren.

Schaut euch mal den Art Net DMX RDM Umsetzer von Ulrich Radig an ( link siehe unten ) - hier sollte man nur mal nach der Art der Übertragung schauen - es kann sein das die da UDP machen. Auf diese ganze Hardware setzt dann z.B. das Projekt www.pcdimmer.de auf. Ich denke mal das die ganze Sache eher was für Sonderbeleutung im Partybereich ist. Es schadet aber nichts entsprechende Anschlüsse vorzuhalten.

Vorteile:

• große Auswahl an günstigen Geräten
• Veranstaltungstechnik können relativ viele Menschen
• Ansteuerung der Controller über Netzwerk spezifiziert bei Art-Net

Nachteile:

• DMX-Scheinwerfer sind im Regelfall nicht für sparsamen Idlebetrieb konzipiert. Die bunten PARs in meinem Fundus (u.a. der unter verlinkte mit UV) brauchen ~6W im Idle, was bei größerer Menge einiges ausmacht. ⇒ Bitte nur mit vorgeschaltetem Relais zum ganz ausknipsen. --Derf (talk)
• DMX arbeitet nach dem Master-Slave-Prinzip, wobei hier ein Rücklesen von Daten seitens der Aktoren nicht möglich ist (im Prinzip wie der alte Dorfbus). Es gibt RDM (Remote Device Management) für DMX was eine Rückmeldung der Geräte ermöglicht.

MQTT

MQTT ist ein Nachrichtenprotokoll, was TCP/IP-basiert arbeiten kann, aber nicht muss.

Vorteile:

• brauchen wir wahrscheinlich eh fürs Dashboard
• einfaches Protokoll mit Libraries für quasi jede Programmiersprache
• günstige Hardware verfügbar (ESP)

Nachteile:

• braucht einen zentralen Server
• eigentlich nur sinnvoll nutzbar mit funktionierendem Netzwerk (TODO: Stimmt das?)

Fazit: nur als Add-on für Datenexport und zur Steuerung nicht-essenzieller Geräte verwenden

Welcher Hardware gibt es?

Modbus

Reine Modbus-Aktoren gibt es als reine Platinen-Version für deutlich unter 10 €:

• Schaltaktor 4 230 Volt Relaisausgänge und 4 Eingänge
• Schaltaktor 2 230 Volt Relaisausgänge und 2 Eingänge

https://github.com/TG9541/stm8ef/wiki/Board-C0135

• Stromzähler Drehstrom mit Modbus-Interface
• Stromzähler Wechselstrom mit Modbus-Interface
• Arduino Client (ohne USB Interface wird nicht benötigt)
• Schnittstellen-Wandler Modbus (Rs484 <-> TTL Seriell)

Zigbee

Es gibt viele komplett fertige Geräte (z.B. Taster, Schalter, Temperatursensoren, Leuchmittel, schaltbare Steckdosen) für relativ wenig Geld (unter oder um 20€).

DMX

• PAR-Scheinwerfer weiß für Vorträge
• PAR-Scheinwerfer bunt (mit UV!) für Deko
• Hazer (Nebelmaschine) für Cyber
• Mini-Controller für einfache Bedienung
• DMX Shield für Raspberry Pi
• www.ulrichradig.de - Projekte mit Licht viele kleine Helferlein die auch einfach nachgebaut werden können - da Quelloffen

MQTT

Die große Auswahl von Sonoff und OBI (wifi-stecker-schuko-weiss Type 1 oder link2home-wifi-steckdose-zeitschaltuhr-weiss Type 2).

Diese können recht einfach auf auf Tasmota "umgeflasht" werden und sind dann im 2,4 GHz WLAN zu erreichen und können über MQTT angesteuert werden. Ruhestromverbrauch unbekannt.

Software

Wir wollen ein Webinterface, in dem Leute rumklicken können und damit Aktionen auslösen. Zusätzlich wollen wir u.a. zeitgesteuerte Aktionen.

dorfmap

Wir könnten die bisher verwendete Software (Wiki, Backend, Frontend) an einen neuen Bus, einen neuen Grundriss und neue Gerät anpassen. Die konzeptionellen Probleme der Software löst das aber nicht.

Aber das UI ist schon nett. Vielleicht einfach nur das Backend austauschen?

Der Hauptentwickler des bisherigen Backends empfielt: Frontend beibehalten (10/10 auf intuitive Bedienung), Backend neu. --Derf (talk)

Der Hauptentwickler des bisherigen Frontends finet: Frontend behalten +1, ist easy anzupassen. SVG vom Grundriss ersetzen fertig (Annahme: API bleibt gleich) Damit geht dann alles was on/off mit rate limit und selection ala blinkenlight out of the box. Presets & actions kommen eh aus dem Backend und müssen dort implementiert sein.

Wenn API Änderungen gerne mich ansprechen, sollte alles recht easy sein. -- marudor

neue Software selber schreiben

Wir könnten eine komplett neue Software selber schreiben. Das wäre der flexibelste Ansatz, aber auch der zeitaufwändigste. Wir haben eh schon (zu?) viel selbstgefrickelte Software.

OpenHAB, Home Assistant, Node-RED, fhem , ...

Name	einfach auf einem Raspi installierbar?	nettes Webinterface	API	Aktionen im Web konfigurierbar?	KNX	modbus	CAN	ZigBee	DMX	MQTT	geschrieben in
openHAB	fertiges Image	ja	ja	teilweise	ja	ja	nein	ja	ja	ja	Java
Home Assistant	fertiges Image	ja	ja	nein	ja	ja	nein	ja	3rd party plugin	ja	Python
Node-RED	curl -> sh	ja	wahrscheinlich	ja!	ja	ja	ja	ja	ja	ja	JavaScript
fhem.de	fertiges Paket	unglaublich viele mäßig schöne	unklar	nein	ja	ja	unklar	unklar	unklar	ja	Perl

TODO: Persistenz nachschauen?

allgemeine Überlegungen

• Fertige Lösungen haben wahrscheinlich einen niedrigeren Zeitaufwand nötig als selbstgebaute Lösungen - dafür sind sie möglicherweise teurer. (Ja, wir sind ein Hackspace, aber Infrastruktur sollte funktionieren und zu viel Zeit hat auch niemand.)
• Wenn einer selber Basteln mag, sollte wir hier ein MODBUS Hardware Interface definieren. An dieses kann dann jeder seine eigenen Aktoren andocken. Dieses sollte so gebaut sein das selbst bei einer Fehlfunktion nicht alles zusammen bricht.

Erfassen von Umweltdaten

• Aktuell haben wir aus dem Bestand 1 Phasen Stromzähler im Dorf liegen. Diese liefern über eine S0-Schnittstelle ( Optokopler ) entsprechende Impulse in Abhängigkeit des Stromverbrauchs. Üblich sind hier wohl 1000 Impulse/kWh. Diese Impulse könnten mit einem ATMEGA328 gezählt werden und dann per Modbus bereitgestellt werden ( eigenes Projekt auf dem Modbus ).
• Fenster auf <-> Heizkörperventil zu
• Darstellung des Energieverbrauchs auf einem Teil des Grafana Displays

Ausfallsicherheit / Graceful Degradation

• Das bisherige Setup mit Webinterface auf einem Pi, der den Bus steuert, ist sinnvoll.
• Wir erinnern uns an den Ausfall von Helios. So etwas sollte die Dorfmap in ihrer Kernfunktionalität nicht großartig stören.
• Auch der neue Dorfbus sollte auf einem eigenem Raspi laufen - im Idealfall sogar mit USV-Stromversorgung (z.B. Netzteile mit Akku-Regelung).
• Kleine Verbraucher (z.B. LEDs) können direkt über den Bus mit Strom versorgt werden. (Hallo, Notfallbeleuchtung Orientierungslicht!)
• Was ist, wenn der Pi ausfällt?

-> da der Pi sich immer nur zum Polling der Clients auf den (Mod-) Bus aufschaltet wird, ist es denkbar hier einen 2. Pi mit auf den RS485 Bus zu hängen. Dieser kann dann mit einer Kopie der Steuerung direkt hochgefahren werden. Es könnte/müsste zu Erhöhung der Ausfallsicherheit immer ein 2. Pi in Lauerstellung bleiben.

• Schaltbefehle wie z.B. Licht sollten auch an den Aktoren selber ausgelöst werden können.
• Andere Dienste (welche?) können dann wiederum via Netzwerk auf den Raspi zugreifen.
• Funkschalter bzw. Wifischalter sind eine Möglichkeit, sollten aber nur dann zum Einsatz kommen, wenn es keine andere sichere kabelgebundene Lösung gibt. Funkübertragungen kann man immer unbeabsichtigt oder beabsichtigt stören.

Ruhestromverbrauch

• Bei allen Systemen sollte auch der Ruhestromverbrauch im Hinterkopf behalten werden.
• Wie operative berichtet hat, liegt unser Ruhestromverbrauch bzw. unsere Ruheleistung bei rund 800 Watt (im Shutdown).
• Es gibt hier sicherlich we* Eventuell auch itere Geräte, die abgeschaltet werden können, wenn keiner im Dorf ist.
• Idee: "Masterbus", der diese Devices dann an die 230 Volt zuschaltet. (Siehe auch Anmerkung zu DMX oben.)

Schalten von 230 Volt

• Idee: Schaltaktor selber als Leiterplatte in einem schutzisolierten Gehäuse anfertigen, der dann mit 3,3 oder 5 Volt direkt 230 Volt schalten kann. Dann kann auch jeder gefahrlos 230 Volt schalten.
• Modbus-RTU-4-Weg-Relaismodul ( 4 Eingänge , 4 Schaltausgänge für 230 Volt ) www.ebay.de/itm/Modbus-RTU-4
• Modbus-RTU-2-Weg-Relaismodul ( 2 Eingänge , 2 Schaltausgänge für 230 Volt ) www.ebay.de/itm/Modbus-RTU-2
• Beide Aktoren - haben per default immer die Busadresse 001 und muss dann auf einen Wert zwischen 002 und 255 Programmiert werden. Es gibt auf Module mit Kodierschalter zum Einstellen der Bus Adresse.