More docs

source/actor/shelly_ger.md

@@ -0,0 +1,38 @@
+# Shelly Modul
+Mit dem Shelly Module können Shelly-Geräte der Gen 1 über MQTT angesteuert werden.
+
+Mit Shellies lässt sich eine stabile und kostengünstige Ein- und Abschaltung von Maschinen realisieren.
+
+Für den Anfang empfehlen wir die Shelly Plug S, durch die Zwischensteckerbauform könnne alle Maschinen mit einem Schutzkontakstecker angesteuert werden und es sind bis zu 10A Dauerstrom möglich.
+
+Sollte eine Maschine mehr als 10A benötigen gibt es den etwas teureren Shelly Plug, dieser kann dann auch bis zu 16A schalten.
+
+Die Shellys müssen für eine Anbindung an den Server mit dem MQTT-Server verbunden werden.
+Da Shellies in der Gen 1 leider kein MQTT über TLS können empfehlen wir diese in einem seperaten Netz abzukapseln und das Netz direkt an dem MQTT Server anzubinden.
+
+Um auch die Maschinen bei einem Ausfall von FabAccess verwenden zu können, empfehlen wir den Knopf nicht abzuschalten.
+Jedoch sollte dann der Shelly schwerer zu erreichen sein. Da wir mit FabAccess keine Lösung entwickeln, die absoulute Sicherheit zum Ziel hat, empfehlen wir die Shellies auch nicht einzukleben.
+Wenn ein Nutzer den Shelly aussteckt oder ein anderes Kabel in das Gerät steckt, dann sollte das durch eine Kontrolle des Betreibers auffallen.
+
+## Konfiguration
+```
+actors = 
+{
+    Shelly_123 = 
+    { 
+        module = "Shelly", 
+        params = 
+        {
+            topic = "shellyplug-s-123456"
+        }
+    }
+}
+```
+
+Die ID des Aktors wäre hierbei `Shelly_123`.
+Das Topic, auf das der Shelly hört wäre `shellyplug-s-123456`.
+
+### Shelly Topics
+Shelly 1: `shelly1-1234567890AB`
+Shelly Plug S: `shellyplug-s-123ABC`
+Shelly Plug: `shellyplug-123ABC`

source/configuration/user_ger.md

@@ -1,4 +1,29 @@
 # Erstellen von Nutzern
+Um beim ersten Start des Servers Nutzer in die interne Datenbank einzuspeisen, wird eine user.toml Datei verwendet.
 
+**Achtung:** Beim Einladen der user.toml werden die Nutzer aus der Datei neu angelegt und die Passwörter zurück gesetzt.
 
-# Exportieren von Nutzern
+```
+[Admin1]
+roles = ["Admin"]
+passwd = "secret"
+noot = "noot!"
+```
+
+Für den Anfang kann ein Admin Nutzer angelget werden. Der sollte die Rolle eines Admins zu gewiesen werden, die in der `bffh.dhall` definiert wird.
+
+Das Passwort kann über den Client geändert werden. Auch sollte der Rolle die Berechtigung zum Anlegen von Nutzern zugewiesen bekommen.
+Information darüber findet ihr hier.
+
+Für das Einladen von Nutzer muss beim Start von BFFH der Paramter
+``--load user.toml`
+hinzugefügt werden. Der Server wird darauf hin die Nutzer einladen und sich beendend.
+Danach kann der Server ohne den Parameter gestartet werden.
+
+# Exportieren von Nutzern
+Um ein BackUp der Nutzerdaten zu bekommen, sollte einerseits die interen Datenbank gesichert werden.
+Es kann auch ein export der Nutzer erfolgen. Die Passwörter der Nutzer werden nach dem Einladen mit `Argon2` gehashed und werden auch als solcher exportiert.
+
+Für das Exportieren von Nutzer muss beim Start von BFFH der Paramter
+``--dumpuser user.toml`
+hinzugefügt werden. Der Server wird darauf hin die Nutzer exportieren und sich beendend.

source/fabfire/cards_ger.md

@@ -0,0 +1,4 @@
+# FabFire SmartCards
+Für das FabFire Protokoll werden NXP MIFARE DESFire Karten verwendet.
+Auf diesen Karten können mehrere Anwendungen gespeichert werden.
+Diese Anwendungen besitzten einen seperaten Anwendungsschlüssel und es können weitere Schlüssel zur Authentifizierung in der Anwendung hinterlegt werden.

source/fabfire/readers_ger.md

@@ -17,5 +17,4 @@ Um eine Prüfung des Servers zu ermöglichen, ob sich eine Karte noch auf dem Re
 Die Kommunikation zwischen dem Server und der Karte kann verschlüsst werden, ist aber in jedem Fall CMAC gesichert.
 Somit kann die Integrität der Nachrichten sichergestellt werden.
 
-Der Server kann auch den Reader auffordern, die Verbindung zur Karte neu aufzubauen. So kann der Reader als Deadman Switch verwendet werden.
-
+Der Server kann auch den Reader auffordern, die Verbindung zur Karte neu aufzubauen. So kann der Reader als Totmannschalter verwendet werden.

source/fabfire/sasl_ger.md

@@ -1,5 +1,4 @@
 # FabFire in SALS
 In SALS wird eine Kartenkommunikation mit ISO 7816 APDUs als FABFIRE-X Mechanism bezeichnet.
-Der Mechanismus stelle eine Binäre Kommunikation mit der Karte dar.
-Der Server sendet nach einer leeren Nachricht an den Server die APDU Commands an die Karte weiter und schickt die Response an den Server zurück.
-
+Der Mechanismus stelle eine binäre Kommunikation mit der Karte da.
+Der Reader bekommt in der Start Schritt einen APDU Command, welcher an die Karte weitergeleitet wird und Response der Karte wird an den Server zurück gesendet.