projekte:schlosssystem_2026
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.
| Beide Seiten, vorherige ÜberarbeitungVorherige ÜberarbeitungNächste Überarbeitung | Vorherige Überarbeitung | ||
| projekte:schlosssystem_2026 [2026-05-08 22:47] – [MQTT] wene | projekte:schlosssystem_2026 [2026-09-18 22:13] (aktuell) – [MQTT] wene | ||
|---|---|---|---|
| Zeile 107: | Zeile 107: | ||
| * [[https:// | * [[https:// | ||
| * [[https:// | * [[https:// | ||
| + | |||
| + | |||
| + | |||
| + | ===== 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 " | ||
| + | |||
| + | 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. | ||
| + | |||
| + | < | ||
| + | ┌─────────────────────────┐ | ||
| + | │ Authentifizierungsmodul │ │ Schlossaktuator │ | ||
| + | └┬────────────────────────┘ | ||
| + | | ||
| + | | ||
| + | │ connect() | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | │ recv() | ||
| + | |||
| + | | ||
| + | send(state) | ||
| + | | ||
| + | │ recv() | ||
| + | │ Bereit, authentifizierungen entgegen zu nehmen | ||
| + | |||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | │ recv() | ||
| + | | ||
| + | </ | ||
| + | |||
| + | Die Kommando- und Statusnachrichten sind ASCII Strings, die mit einem "line feed" ('' | ||
| + | |||
| + | * Bereitschaftszustand des Schlossaktuators - im Ruum42 ob Licht brennt, kann aber auch anders definiert werden: '' | ||
| + | * Status des Schlosses: '' | ||
| + | * Kommando zum öffnen und schliessen: '' | ||
| Zeile 135: | Zeile 183: | ||
| # Den RasPi Timestamp anpassen für den Fall, dass es ohne Verbindung zum NTP Server startet | # Den RasPi Timestamp anpassen für den Fall, dass es ohne Verbindung zum NTP Server startet | ||
| sudo touch / | sudo touch / | ||
| + | |||
| + | # 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 | ||
| + | |||
| </ | </ | ||
| + | |||
| ==== MQTT ==== | ==== MQTT ==== | ||
| Zeile 152: | Zeile 206: | ||
| # Kommando zum Öffnen an's Schloss schicken: | # Kommando zum Öffnen an's Schloss schicken: | ||
| - | mosquitto_pub -h wene-raspi-lock -t "main_lock/command/ | + | mosquitto_pub -h wene-raspi-lock -t " |
| # Das Schloss schickt den Status " | # Das Schloss schickt den Status " | ||
| - | mosquitto_pub -h wene-raspi-lock -t "main_lock/status" | + | mosquitto_pub -h wene-raspi-lock -t " |
| # Das Flag ' | # Das Flag ' | ||
| </ | </ | ||
projekte/schlosssystem_2026.1778273275.txt.gz · Zuletzt geändert: von wene