Graph-IT Wiki - Benutzerbeiträge [de]

Graphmodul li - LightPi

2019-03-18T14:41:51Z

Swassen: /* Der LightPi-Master */

Das Graphmodul li - LightPi bildet alles rund um den LightPi im Graphen ab. Mit dem LightPi können Gebäudeautomatisierungen durchgeführt werden.

== Der LightPi ==
Der LightPi ist eine Appliance mit 16 12V Gleichstrom Eingängen und 16 230V Wechselstrom Ausgängen die über einen verbauten Raspberry Pi ausgelesen bzw. geschaltet werden können. Der LightPi kann so zur Gebäudeautomatisierungen eingesetzt werden. Dieser Artikel beschreibt die Software, welche auf dem Raspberry Pi und im Graphen läuft um den LightPi an den Graphen anzuschließen.

== Der LightPi-Slave ==
Der LightPi-Slave ist die Software-Komponente die auf dem im LightPi verbauten Raspberry Pi ausgeführt wird. Sie verbindet sich mit dem LightPi-Master und teilt diesem in regelmässigen Abständen den Schaltzustand der Ausgänge mit. Wird eine Änderung eines Schaltzustandes an einem Eingang entdeckt, so wird dieses Ereignis ebenfalls dem LightPi-Master mitgeteilt. Des weiteren reagiert der LightPi-Slave auf Befehle des LightPi-Masters und schaltet daraufhin die Ausgänge. Der LightPi-Slave schaltet die Ausgänge nur auf Befehl des LightPi-Masters! Der LightPi-Slave ist in Python3 geschrieben und verwendet die Bibliothek [http://abyz.me.uk/rpi/pigpio/python.html pigpio] zum Auslesen und Schalten der Ein- und Ausgänge. Er verbindet sich automatisch mit dem konfigurierten LightPi-Master. Reisst die Verbindung ab, so wird automatisch versucht, diese wiederherzustellen. Die Datenpakete zwischen LightPi-Slave und LightPi-Master sind mit [https://msgpack.org/ msgpack] kodiert. Die Kommunikation erfolgt nicht verschlüsselt und auch nicht authentifiziert über TCP/IP. Eine sichere Netzwerkinfrastruktur ist also notwendig!

== Der LightPi-Master ==
Der LightPi-Master ist die Software-Komponente die auf dem Gebäudeserver läuft. Er öffnet einen TCP-Port und wartet auf eingehende Verbindungen von LightPi-Slaves. Er verarbeitet die Zustands- und Ereignis-Nachrichten der LightPi-Slaves und reagiert auf diese mit Befehlen an die LightPi-Slaves. Er verwaltet ein Menge von Statemachines die den gewünschten Schaltzustand der Ausgänge definieren. Der LightPi-Master ist in PHP geschrieben und wird über die Datei <code>etc/master.json</code> konfiguriert:
{
"uri": "tcp://192.168.1.20:47974",
"peers": {
"master": {
"ip": "192.168.1.20", "lightpi": "master"
},
"NV1-01": {
"ip": "192.168.64.1", "lightpi": "lightpi01"
},
"NV1-02": {
"ip": "192.168.64.3", "lightpi": "lightpi03"
}
},
"machines": {
"NV01-01:A01": { ... },
"NV01-01:all": { ... },
"Alarm01": { ... }
}
}
Unter dem Schlüssel <code>uri</code> wird die IP-Adresse und der TCP-Port festgelegt auf dem der LightPi-Master auf einkommende Verbindungen lauscht. Unter dem Schlüssel <code>peers</code> werden die Unterverteilungen im Gebäude aufgezählt und die in ihnen installierten LightPis mit ihren IP-Adressen definiert. Die Unterverteilung <code>master</code> gibt einen zusätzlichen Endpunkt zum Einspeisen von Ereignissen. Die Unterverteilungen <code>NV01-01</code>, <code>NV01-02</code>, etc. stellen die Sensoren und Aktoren für die Statemachines zur Verfügung. Auf diese Art und Weise kann man einen LightPi an einer Unterverteilung tauschen ohne die Definition der Statemachines zu verändern. Die Namen für die Unterverteilungen können frei festgelegt werden. Unter dem Schlüssel <code>machines</code> werden die Statemachines definiert. Es können beliebig viele Statemachines angegeben werden. Ihre Namen können ebenfalls frei festgelegt werden. Im folgenden ein paar Beispiele:

=== Statemachine NV01-01:A01 ===
"NV01-01:A01": {
"off": {
"transitions": {
"on": [ "NV1-01:A01:toggle" ]
}
},
"on": {
"transitions": {
"off": [ "NV1-01:A01:toggle" ]
},
"actors": [ "NV1-01:A01" ]
}
}
Die Statemaschine <code>NV01-01:A01</code> hat zwei Zustände: <code>on</code> und <code>off</code>. Unter dem Schlüssel <code>transitions</code> sind die aus dem jeweiligen Zustand heraus erreichbaren Zustände notiert und eine Liste von Ereignissen, bei denen der Zustandswechsel durchgeführt wird. Aus dem Zustand <code>off</code> ist der Zustand <code>on</code> erreichbar. Ist die Statemachine aktuell im Zustand <code>off</code> und wird tritt das Ereignis <code>NV1-01:A01:toggle</code> auf, so wird in den Zustand <code>on</code> gewechselt. Tritt dann erneut das Ereignis <code>NV1-01:A01:toggle</code> auf, so wird zurück in den Zustand <code>off</code> gewechselt. Die Namen der Zustände und Ereignisse können frei gewählt werden. Allerdings unterteilt sich die Menge der Ereignisse in die Symbolereignisse mit frei wählbarem Namen und die Sensorereignisse mit wohldefinierten Namen. Das Ereignis <code>NV1-01:A01:toggle</code> ist ein Symbolereignis. Symbolereignisse können vom LightPi-Master aus mit dem Programm <code>event.php <event></code> ausgelöst werden. Zu den Sensorereignissen gibt es im nächsten Beispiel weitere Erläuterungen. Unter dem Schlüssel <code>actors</code> im Zustand <code>on</code> sind die Ausgänge gelistet die in diesem Zustand geschaltet sein sollen. Der Aktor <code>NV1-01:A01</code> bezeichnet dabei den Ausgang <code>01</code> an der Unterverteilung <code>NV1-01</code>. Die Namen der Aktoren setzen sich dabei aus dem Namen der Unterverteilung, sowie der Aktornummer <code>01</code> bis <code>16</code> zusammen. Ein Ausgang kann durch mehrere Statemachines und Zustände geschaltet werden. Ist mindestens eine Statemachine in einem Zustand in dem ein Ausgang geschaltet sein soll, so wird dieser eingeschaltet. Ist keine Statemachine in einem solchen Zustand, so wird der Ausgang ausgeschaltet.

=== Statemachine NV01-01:all ===
"NV1-01:all": {
"off": {
"transitions": {
"on": [ "NV1-01:all:toggle", "NV1-01:S01:1" ]
}
},
"on": {
"transitions": {
"off": [ "NV1-01:all:toggle", "NV1-01:S01:1" ]
},
"actors": [
"NV1-01:A01", "NV1-01:A02", "NV1-01:A03", "NV1-01:A04",
"NV1-01:A05", "NV1-01:A06", "NV1-01:A07", "NV1-01:A08",
"NV1-01:A09", "NV1-01:A10", "NV1-01:A11", "NV1-01:A12",
"NV1-01:A13", "NV1-01:A14", "NV1-01:A15", "NV1-01:A16"
]
}
}
Die Statemaschine <code>NV01-01:all</code> hat wie die aus dem vorherige Beispiel die zwei Zustände <code>on</code> und <code>off</code>. Zwischen den beiden kann mit dem Symbolereignis <code>NV1-01:all:toggle</code> und dem Sensorereignis <code>NV1-01:S01:1</code> gewechselt werden. Wenn an einem Sensor an einem LightPi ein Zustandswechsel auftritt wird ein Sensorereignis ausgelöst. Der Name des Ereignises setzt sich dabei aus dem Namen der Unterverteilung, der Sensornummer <code>01</code> bis <code>16</code> und dem Sensorwert <code>0</code> oder <code>1</code> zusammen. Es wird auch immer noch ein zweites Sensorereignis ausgelöste, dessen Namen sich nur aus dem Namen der Unterverteilung und der Sensornummer zusammensetzt. Beispielweise <code>NV01-01:S01</code>. Im Zustand <code>on</code> werden durch diese Statemachine alle Ausgänge an der Unterverteilung geschaltet.

=== Statemachine Alarm01 ===
"Alarm01": {
"off": {
"transitions": {
"on": [ "Alarm01:toggle" ]
}
},
"on": {
"transitions": {
"off": [ "Alarm01:toggle" ],
"move": [ "NV1-02:S01:1" ]
}
},
"move": {
"transitions": {
"off": [ "Alarm01:toggle" ],
"timer": [ "NV1-02:S01:0" ]
},
"actors": [ "NV1-02:A01", "NV1-02:A02" ],
},
"timer": {
"transitions": {
"on": [ "Alarm01:timeout" ],
"off": [ "Alarm01:toggle" ],
"move": [ "NV1-02:S01:1" ]
},
"actors": [ "NV1-02:A01", "NV1-02:A02" ],
"enter": [
[ "timerStart", "Alarm01:timeout", 30 ]
],
"leave": [
[ "timerStop", "Alarm01:timeout" ]
]
}
}
Die Statemaschine <code>Alarm01</code> modelliert eine Alarmanlage. Im Zustand <code>off</code> ist die Alarmanlage ausgeschaltet und kann durch das Symbolereignis <code>Alarm01:toggle</code> scharf geschaltet werden. Sie ist dann im Zustand <code>on</code>. Tritt dann durch den Bewegungsmelder das Sensorereignis <code>NV1-02:S01:1</code> auf, so wird in den Zustand <code>move</code> gewechselt. Es wurde eine Bewegung entdeckt. Die Alarmsirene und der Alarmblitz an den Ausgängen <code>NV1-02:A01</code> und <code>NV1-02:A02</code> wird eingeschaltet. Wird keine Bewegung mehr entdeckt und das Sensorereignis <code>NV1-02:S01:0</code> ausgelöst so wird in den Zustand <code>timer</code> gewechselt. Bis hierhin wurden an den Zuständen Schlüssel verwendet, die aus den vorherigen Beispielen bereits bekannt waren. Im Zustand <code>timer</code> werden zwei neue Schlüssel verwendet: <code>enter</code> und <code>leave</code>. Hier werden Kommandos und ihre Argumente aufgelistet die beim Betreten und Verlassen des Zustandes ausgeführt werden sollen. Im Augenblick gibt es nur zwei Kommandos. Das Kommando <code>timerStart <name> <dauer></code> und das Kommando <code>timerStop <name></code>. Mit dem Kommando <code>timerStart</code> wird ein Timer mit einem bestimmten Namen und einer bestimmten Dauer in Sekunden gestartet. Läuft der Timer ab so wird ein Symbolereignis mit dem Namen des Timers ausgelöst. Das Kommando <code>timerStop</code> stop den Timer mit dem gegebenen Namen.

== Das Graphmodul li - LightPi ==

Graphmodul li - LightPi

2019-03-18T11:53:17Z

Swassen: /* Der LightPi-Master */

Graphmodul li - LightPi

2019-03-18T10:45:43Z

Swassen:

Lxdhost-Server

2019-03-14T13:26:26Z

Swassen:

Ziel dieser Anleitung ist eines ausfallsicheren LXDHost. Die Anleitung basiert auf der Anleitung [[Server-Basissystem]]. Das System hat zwei zusätzliche Festplatten auf denen die LXD-Container abgelegt werden. Die Festplatten sind mit LVM zu einer Volume-Group zusammengefasst. In dieser wird ein Logical-Volume vom Typ <code>raid1</code> angelegt. Als Dateisystem wird wieder BTRFS eingesetzt. Das Netzwerk wird so konfiguriert, das die LXD-Container direkten Zugriff auf das Netz haben und von dort per DHCP mit IP-Adressen versorgt werden können. Dazu wird das in der vorhergehenden Anleitung konfigurierte Interface <code>eno1</code> durch die Bridge <code>lxdbr0</code> ersetzt.

==Voraussetzungen==
Funktionsfähiges Server Basissystem

Die Dateien lxdh-setup und lxdh-config-example aus den git-Repository [[https://github.com/heiko-schlabach/Server-Basissystem]]

==Installation==
Der Server wird gebootet und der Benutzer <code>root</code> meldet sich am System an. Nun werden die Skripte aus dem Git-Repository abgerufen.
apt install git
git clone https://github.com/heiko-schlabach/Server-Basissystem
cd Server-Basissystem

Zunächst muss eine Konfigurationsdatei für das Skript <code>lxdh-setup</code> angelegt werden:

cp lxdh-config-example lxdh-config
nano lxdh-config

Nun kann das Skript lxdh-setup aufgerufen werden:

./lxdh-setup lxdh-config

Während der Abarbeitung wird der Benutzer nach dem Passwort für den LXD-Deamon gefragt. Anschliessend kann das System neu gestartet werden.

Server-Basissystem

2019-03-14T11:52:31Z

Swassen:

==Allgemein==
Das Ziel dieser Anleitung ist ein Ubuntu-Minimal-System mit folgenden Eigenschaften: Das System hat zwei System-Festplatten. Fällt eine der beiden Festplatten aus, so funktioniert das System trotzdem ohne Beeinträchtigung weiter. Dies umfasst auch den Neustart. Ein Hot-Swap der Festplatten ist ebenfalls möglich.

Es wurde keine Möglichkeit gefunden unter Ubuntu zwei EFI-Partionen synchron zu halten. Aus diesem Grund muss das System mit BIOS oder UEFI-Legacy gebootet werden.

Als Partitionstabelle wurde GPT gewählt. Für die zweite Stufe von GRUB braucht man dann eine zusätzliche kleine Partition vom Typ "BIOS boot". Diese muss auf beiden Festplatten angelegt werden. Es wird eine Größe von 1MB empfohlen. Ein Dateisystem darf in dieser Partition nicht angelegt werden. Die Partion wird unter Ubuntu bei Installation und Update des Bootloaders automatisch aktualisiert und synchron gehalten.

Die zweite Partition umfasst jeweils den Rest der Festplatte. Sie sollte den Typ "Linux LVM" haben. Die beiden großen Partition werden in einer LVM-Volume-Group zusammengefasst. In der Volume-Group wird dann ein Logical-Volume vom Typ raid1 angelegt. Das Logical-Volume muss nicht sehr groß sein, da nur ein Minimal-System installiert werden soll. Sollte der Platz knapp werden, so kann man das Logical-Volume und das enthaltene Dateisystem bis zu der Größe der kleineren Festplatte erweitern.

Als Dateisystem für das Logical-Volume wird BTRFS verwendet. Dies gestattet es, vor umfangreicheren Änderungen am Betriebsystem, einen Snapshot anzulegen. In den Dateisystem werden die drei Subvolumes <code>@</code>, <code>@home</code> und <code>@snapshot</code> angelegt, welche an <code>/</code>, <code>/home</code> und <code>/snapshot</code> eingehängt werden.

Zum Überwachen der Festplatten wird das Paket <code>smartmontools</code> installiert und eingerichtet. Zum Versenden von Systemmails wird das Paket <code>msmtp-mta</code> verwendet.

Das System wird nicht von einem Installationsmedium sondern mit <code>debootstrap</code> installiert. Deshalb kann zur Installation irgendein System verwendet werden, das mit den notwendigen Tools ausgestattet ist. Am einfachsten ist es den Server mit dem Live-System von einem "Ubuntu Desktop 18.04"-Stick zu booten. So kann man einerseits beim Systemstart das Tastaturlayout wählen und andererseits diese Anleitung in einem Browser öffnen.

==Voraussetzungen==

[[Server]] mit 2 Systemfestplatten SSD im Wechselrahmen

USB Stick mit Ubuntu 18.04 Desktop zum Installieren

Netzwerk mit DHCP und Internetverbindung

Die Dateien basy-bootstrap, basy-setup und basy-config-example aus dem GitHub Repository [[https://github.com/heiko-schlabach/Server-Basissystem]]

==Installation==

Der Server wird von einem "Ubuntu Desktop 18.04"-Stick gebootet. Dabei ist bei einem UEFI-System darauf zu achten, das der Server im Legacy-Modus gestartet wird. Man wählt die Sprache und das man Ubuntu zunächst ausprobieren möchte. Nach dem der Ubuntu-Desktop fertig gestartet ist öffnet man ein Shell und holt sich mit <code>sudo bash</code> Superuser-Rechte. Nun können die Skripte aus dem Git-Repository abgerufen werden.
apt install git
git clone https://github.com/heiko-schlabach/Server-Basissystem
cd Server-Basissystem

Zunächst muss eine Konfigurationsdatei für das Skript <code>basy-bootstrap</code> angelegt werden:
cp basy-config-example basy-config
nano basy-config

Nun kann das Skript <code>basy-bootstrap</code> aufgerufen werden:
./basy-bootstrap basy-config

Während der Abarbeitung wird der Benutzer nach dem <code>root</code>-Passwort für das System gefragt. Anschliessend kann das System neu gestartet werden.