Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

--- projekte:schlosssystem_2026 [2026-03-07 16:09] – [MQTT] wene
+++ projekte:schlosssystem_2026 [2026-09-18 22:13] (aktuell) – [MQTT] wene
@@ Zeile 49: / Zeile 49: @@
   * Als Ruum42 Vollmitglied möchte ich das Schloss auch ohne Smartföhn öffnen können. Idee ist ein ESP.
   * (Allenfalls) Als Besucher ohne persönliches Login/Passwort möchte ich über die [[https://f-droid.org/de/packages/com.example.trigger/|Trigger Anwendung]] mit einem "generischen" Benutzer die Klingel betätigen können. Die Einrichtung des Benutzers finde ich auf der Ruum42 Webseite. Im Ruum42 ist eine Klingel angebracht, die vom Raspberry-PI angesteuert wird.
+  * Als Ruum42 Vollmitglied möchte ich mehrere Tokens zur Authentifizierung in meinem Account hinterlegen und verwalten können. Damit kann ich beispielsweise den SSH Schlüssen der Trigger App auf dem Smartphone sowie den SSH Schlüssel meines Laptops hinterlegen und im Falle eines Verlustes auch wieder getrennt zurückziehen. Die Schlüssel würde ich gerne anhand eines Namens, den ich selbst vergeben kann, identifizieren können.
+  * Als Vorstandsmitglied möchte ich Dienstleistern wie z.B. Getränkelieferanten einen Einmal-Schlüssel per E-Mail senden können. Dabei sollte der Dienstleister keine spezielle Hard- oder Software benötigen. Ein gängiges Smartphone mit Browser muss genügen. Der Einmal-Schlüssen wird ungültig, sobald er einmal benutzt wurde. (resp. ein paar Minuten danach, damit nach versehentlicher Schliessung nochmals geöffnet werden kann.) Beispiele für einen Schlüssel wären ein Link, der nur im Schloss-Netz gültig ist, oder ein Zahlencode der in einem Captive-Portal eingegeben werden muss.
 === Schloss-Aktuatoren ===
@@ Zeile 60: / Zeile 62: @@
 === Module und Schnittstellen ===
-{{ :projekte:schlosssystem_module_und_schnittstellen_v2.png |}}
+{{:projekte:schlosssystem_module_und_schnittstellen_v3.drawio.png|}}
 Grafik erstellt mit [[https://www.drawio.com|drawio]].
@@ Zeile 106: / Zeile 107: @@
     * [[https://www.reichelt.de/de/de/shop/produkt/boversa_bov-fg-g_211405_set_210_x_140_x_63_mm_weiss-401456|BoVersa BOV-FG-G 211405, 210 x 140 x 63 mm]]
     * [[https://www.bopla.de/gehaeusetechnik/boversa/gehaeusedeckel-kunststoff-weiss/gehaeusedeckel-kunststoff-transparent-mit-silikondichtung/bov-2114-fg-9003-ot-g-silc|BoVersa BOV 2114 FG-9003, 210 x 140 x 24 mm]]
+===== Spezifikationen =====
+==== Protokoll zwischen Schlossaktuator und Authentifizierungsmodul ====
+Vorerst verwenden wir unix domain sockets. Dies ist die beste Lösung, solange sich beide Komponenten auf dem gleichen System befinden. Sobald die Anforderung aufkommt, Schlossaktuatoren über Netzwerk anbinden zu können, sollte die Umstellung auf TCP über TLS verhältnismässig einfach sein.
+Der Schlossaktuator ist in diesem System der "Server". Er öffnet den Socket und nimmt Verbindungen von mehreren Authentifizierungsmodulen an. Die Authentifizierungsmodule sind entsprechend "Clients" und können sich wiederum zu (optional) mehreren Schlossaktuatoren verbinden.
+Sobald die Verbindung aufgebaut ist, sendet der Schlossaktuator den aktuellen Zustand zum Authentifizierungsmodul. Danach hören beide Teilnehmer passiv auf den Socket und beide können bei einem entsprechenden Ereignis die Kommunikation anfangen. Wenn beispielsweise sich der Status des Schlossaktuators ändert, teilt dieser den neuen Status unmittelbar allen verbundenen Authentifizierungsmdule mit. Wenn wiederum ein Benutzer sich bei einem Authentifizierungsmodul erfolgreich authentifiziert hat, schickt das Authentifizierungsmodul das Kommando zum öffnen des Schlosses an den entsprechenden Schlossaktuator.
+<code>
+┌─────────────────────────┐                       ┌─────────────────┐
+│ Authentifizierungsmodul │                       │ Schlossaktuator │
+└┬────────────────────────┘                       └────────────────┬┘
+ │                                                  bind()         │
+ │                                                  listen()       │
+ │ connect()                                                       │
+ ├────────────────────────────────────────────────────────────────►│
+ │                                                  accept()       │
+ │                                                  send(state)    │
+ │◄────────────────────────────────────────────────────────────────┤
+ │ recv()                                                          │
+ │                  Aussenlicht wird eingeschaltet                 │
+                                                    send(state)
+ │◄────────────────────────────────────────────────────────────────┤
+ │ recv()                                                          │
+ │ Bereit, authentifizierungen entgegen zu nehmen                  │
+ │                Ein Benutzer löst ein Öffnen aus                 │
+   send(command)
+ ├────────────────────────────────────────────────────────────────►│
+ │                                                  recv()         │
+ │                                                  Schloss öffnen │
+ │                                                  send(state)    │
+ │◄────────────────────────────────────────────────────────────────┤
+ │ recv()                                                          │
+ │                                                                 │
+</code>
+Die Kommando- und Statusnachrichten sind ASCII Strings, die mit einem "line feed" (''\n'') enden.
+  * Bereitschaftszustand des Schlossaktuators - im Ruum42 ob Licht brennt, kann aber auch anders definiert werden: ''isReady:true'' / ''isReady:false''
+  * Status des Schlosses: ''isOpen:true'' / ''isOpen:false''
+  * Kommando zum öffnen und schliessen: ''command:open'' / ''command:close''
@@ Zeile 134: / Zeile 183: @@
 # Den RasPi Timestamp anpassen für den Fall, dass es ohne Verbindung zum NTP Server startet
 sudo touch /var/lib/systemd/timesync/clock
+# Existierendes Zertifikat erneuern
+openssl x509 -x509toreq -in server.crt -out server.csr -signkey server.key
+openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -out server.crt -days 30
 </code>
 ==== MQTT ====
@@ Zeile 151: / Zeile 206: @@
 # Kommando zum Öffnen an's Schloss schicken:
-mosquitto_pub -h wene-raspi-lock -t "main-door/lock" -m "open" -p 8883 --cafile path/to/ca.crt
+mosquitto_pub -h wene-raspi-lock -t "command/main_lock/userName/userSecret" -m "open" -p 8883 --cafile path/to/ca.crt
 # Das Schloss schickt den Status "opened" zurück:
-mosquitto_pub -h wene-raspi-lock -t "main-door/status" -r -m "opened" -p 8883 --cafile ca.crt
+mosquitto_pub -h wene-raspi-lock -t "status/main_lock" -r -m "opened" -p 8883 --cafile ca.crt
 # Das Flag '-r' steht für "retain" und bedeutet, dass dieser Wert auf dem Broker als Status gespeichert bleibt und neuen Clients bei Verbindung zugestellt wird.
 </code>
@@ Zeile 172: / Zeile 227: @@
 <file - tls.conf>
 listener 8883
-allow_anonymous true
 cafile /etc/mosquitto/ca_certificates/ca.crt
 certfile /etc/mosquitto/certs/server.crt
@@ Zeile 178: / Zeile 232: @@
 </file>
-Die Datei ''tls.conf'' enthält Pfade zu Zertifikaten, welche wir natürlich erst an der Stelle ablegen müssen, damit das funktioniert.
+<file - password.conf>
+password_file /etc/mosquitto/passwd
+allow_anonymous false
+</file>
+<file - acl.conf>
+acl_file /etc/mosquitto/acl
+</file>
+Die Datei ''tls.conf'' enthält Pfade zu Zertifikaten, welche wir natürlich erst an der Stelle ablegen müssen, damit das funktioniert. Wie sie erstellt werden, wird im Kapitel [[#TLS Self Signed Certificates]] erklärt. Nachdem die Dateien an den entsprechenden Pfaden liegen, sollte Mosquitto als Eigentümer festgelegt werden: ''sudo chown mosquitto:mosquitto -R /etc/mosquitto/certs'' und ''sudo chown mosquitto:mosquitto -R /etc/mosquitto/ca_certificates''.
+Die Datei ''password.conf'' enthält den Pfad zur Passwortdatei. Diese wird mit Hilfe des Tools ''mosquitto_passwd'' generiert.
+<code bash>
+# Passwortdatei anlegen mit dem ersten Benutzer namens "system" und dem Passwort "syspass"
+sudo mosquitto_passwd -c -b /etc/mosquitto/passwd system syspass
+# Den Eigentümer der Passwortdatei festlegen
+sudo chown mosquitto:mosquitto /etc/mosquitto/passwd
+# Weitere Einträge zur existierenden Datei hinzufügen
+sudo mosquitto_passwd -b /etc/mosquitto/passwd towel_key password
+# Es wird eine Warnung angezeigt, dass die Datei nicht root gehört. Diese kann
+# ignoriert werden, da der mosquitto Service nicht als root ausgeführt wird.
+# Um die Warnung zu vermeiden erst alle Passwörter eintragen, dann den Besitzer ändern.
+</code>
+Über die Datei ''/etc/mosquitto/acl'' wird definiert, welche MQTT Themen von wem gelesen und von wem geschrieben werden können. Somit können alle Schlüssel den gleichen MQTT Benutzer verwenden und ihr Geheimnis trotzdem als Thema veröffentlichen. Es kann von anderen Benutzern nicht gelesen werden solange sie dieses Thema nur schreiben, aber nicht lesen können.
+<file - acl>
+user system
+topic read main_lock/command/#
+topic write main_lock/status/#
+user towel_key
+topic write main_lock/command/#
+topic read main_lock/status/#
+</file>
 === Python Library Paho ===
@@ Zeile 187: / Zeile 278: @@
 ==== NTP ====
-Als NTP Server bietet sich ''chrony'' an. Der kann sehr einfach so konfiguriert werden, die wahre NTP Zeit weiter zu leiten solange es eine Verbindung zu NTP Servern gibt. Wenn diese Verbindung nicht existiert, kann eine angenommene Zeit verbreitet werden.
+Als NTP Server bietet sich [[https://chrony-project.org/|Chrony]] an. Der kann sehr einfach so konfiguriert werden, die wahre NTP Zeit weiter zu leiten solange es eine Verbindung zu NTP Servern gibt. Wenn diese Verbindung nicht existiert, kann eine angenommene Zeit verbreitet werden.
+Dies ist die Konfigurationsdatei in ''/etc/chrony'':
-/etc/chrony/chrony.conf: <file>
+<file - chrony.conf>
 # Welcome to the chrony configuration file. See chrony.conf(5) for more
 # information about usable directives.