# 03.12.2019 // Roseguarden Repositories (v2): [https://gitlab.com/roseguarden](https://gitlab.com/roseguarden) Demo: [https://roseguarden.fabba.space/dashboard](https://roseguarden.fabba.space/dashboard) ## Vorbetrachtungen - Ziel ist ein möglichst einfaches/übersichtliches System zu erstellen - Möglichst wenig externe Infrastrukturabhängigkeiten bzw. Voraussetzung - keine Broker - keine statisch vorausgesetzen Datenbanken - keine als notwendig vorausgesetzte / aufbauende Softwareinstallationen => diese machen das System unnötig kompliziert für Einsteiger (Abschreckung) - Möglichst gute Anpassbarkeit und Erweiterbarkeit (Opt in Gedanke) - Möglichst viele Schnittstellen als Module (Optionen schaffen) - Bibliothekenabhängigkeiten sind ok (alles was integriert) - Möglichst einfache Integration von externen Zugriff ermöglichen (Schnittstelle nach außen ist genauso wichtig wie gute Schnittstellen intern) - Standards vor Eigenentwicklung - möglichst wenig selber entwickeln (zu wenig Manpower) - möglichst beliebte Bibliotheken, Sprachen, und Werkzeuge verwenden (sollte maintained sein/bleiben) - Komplexität sollte gering gehalten werden - Möglichst einfache Bedienung für nicht Programmierer ist sehr wichtig (gutes Frontend) - Einfache Installation und Wartung für Nutzer/Admins ist ebenfalls sehr wichtig - Möglichst günstig und weit verbreitet Hardware einsetzen - kein Raspberry Pi (Erfahrung aus v1) da Probleme mit Einrichten / Automatisierung / kaputte Dateisysteme / Hardwareanbindung / Hoher Stromverbrauch / Kosten (durch Zusatzkomponenten, evt. Rasp Zero W ?!) - Raspberry Pi eher gern als Server - Mikrocontroller (ESP8266, ESP32, Arduino) zu bevorzugen - Gut aufbereitete Doku (Doku included) ## Projektinterne Werkzeuge Im Folgenden werden die aktuell verwendeten digitalen Werkzeuge aufgeführt sowie eine kurze Begründung für deren Entscheidung. ### Python Für die **Backend-Entwicklung** - Python als weit verbreitete Sprache - Popularität siehe Bild ![](https://pad.gwdg.de/uploads/d25e38a6-626e-43bf-a9a1-c03b10c40418.png) (Quelle: [https://entwickler.de/online/development/top-10-programmiersprachen-redmonk-tiobe-pypl-579886370.html](https://entwickler.de/online/development/top-10-programmiersprachen-redmonk-tiobe-pypl-579886370.html), gern mal zum direkt anschauen, die Zahlen bzw. Abstände der Sprachen sind sehr interessant, hier sind die 3 wichtigsten Rankings (Methoden) aufgelistet) - Viele Leute hatten bereits Kontakt (persönliche Erfahrung) - allgemein wird eine flache Lernkurve wahrgenommen (persönliche Erfahrung) - einfache Installation mit anaconda / pip - auf allen OS Verfügbar (Linux, Windows, Mac) - riesiges Portfolio an Bibliotheken (siehe Ziel: möglichst wenig selber programmieren) - requests - HTTPS Anbindung an REST-APIs und Co - python-ldap - LDAP Anbindung - fintech - Anbindung an SEPA, DATEV, - python-openhab - Anbindung an OpenHab - Odoo Client Library - Anbindung an Odoo - Hardwareansteuerung - RFID-Reader, Relays, etc - Flask - Website-Framework - Andere Programmiersprachen in Python-App sehr gut integrierbar - Vorteil von Python das Kombination mit anderen Sprachen sehr einfach möglich ist (sozusagen seamless), wenn gewünscht - z.B. Plugins anbieten die in anderen Sprachen geschrieben sind (kein Hauptziel, vielleicht später da auf ersten Blick kompliziert) - siehe [https://wiki.python.org/moin/IntegratingPythonWithOtherLanguages](https://wiki.python.org/moin/IntegratingPythonWithOtherLanguages) - Integration von Java-Code über Japp - Integration von C/C+±Code über Cython / Ctypes - Integration von C#-Code über IronPython - Integration von Rust-Code über PyO3 - Python lässt das dynamische laden von Modulen (Z.b. als Plugins sehr einfach umsetzen), ohne overhead (einfach Quellcode-Dateien in Ordner kopieren) **Nebenbemerkung Javascript für die Frontend-Entwicklung** - Für separate Frontendentwicklung gibt es neben plain HTML/CSS (meist generierte Seiten) faktisch keine nennenwerten Vertreter neben JavaScript/TrueScript (WebAssembly wird meist nur als Zusatz verwendet und daher hier erstmal außen vor) >> JavaScript - Typescript umstieg natürlich möglich/offen (Typensicherheit etc.) ### Flask Python-Framework für die **Backend-Entwicklung** - Siehe: [blog.miguelgrinberg.com](https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-part-i-hello-world) - Ziel: Vereinfachung der Entiwcklung, bestehende Bibliotheken nutzen - Anwendung wird übersichtlichr und einfacher zu verstehen - Einfacher/Schlanker als Alternative Django und dabei ähnliche Verbreitung - Viele Erweiterungen: - Migration von MySQL, MariaDB, PostgreSQl, MSSql oder SQLLite je nach Wunsch - Flask-SQLAlchemy - Datenbankinetgration - Flask-JWT - Sicherheitstoken - Flask-Mail - Integration von eMail-Versand - Flask-Upload - Datei-Upload handling - Flask-Rabbitmq - Integration von RabbitMQ - Flask-MQTT - Integration von MQTT-Nachrichten - Flask-ZMQ - Integration von ZeroMQ Sockets ### Vue Für die **Frontend-Entwicklung** - [https://vuejs.org](https://vuejs.org) - JavaScript-Bibliothek zur Datenverwaltung (DataBinding) und als Hilfestellug, defacto-Standard ein Framework zu nutzen - Die Standard-Player mit großer Community sind Angular (Google), React (Facebook) und Vue (Indie) - Gute Zusammenfassung siehe: [https://dzone.com/articles/react-vs-angular-vs-vuejs-a-complete-comparison-gu](https://dzone.com/articles/react-vs-angular-vs-vuejs-a-complete-comparison-gu) - Kleines Projekt mit kleinem Team <= “Vue is ideal for a small team and a small project. If your app seems to be large and has significant future expansion plan, pick React or Angular.” ### Vuetify Für die **Frontend-Entwicklung** - Ist eine Komponenten-Biblitohek auf Basis von Material Design für Vue - Enthält GUI-Eleemnte: Forumalare, Kalender, Tabellen … - Internationalisierung included - Anpassung von Farbe Style sehr einfach - Ser gute Doku mit vielen Beispielen - möglichst wenig selbst entwickeln - Siehe Beispiel für [Kalender Komponente](https://vuetifyjs.com/en/components/calendars) - Beschleunigt Entwicklung - Mobile und Browser-optimiert - ggf. keine separate Handy-App mehr notwendig (wenn ja, sehr einfach per Electron) ### HTTP/S Als Schnittstelle nach außen - Möglichst nur **eine** Schnittselle Maintainen für möglichst geringen Aufwand - Für Frontend (Website + Apps) ist HTTP/S die meist verbreitetste Technologie (je nach Frontend-Entwicklung zwingend notwendig, alternativ Websockets nutzen und direkt abkappseln, Entwicklungsaufwand?) - Keine zusätzliche Installation von Brokern notwendig (wie MQTT/RabbitMQ, da möglichst geringe Infrastrukturabhängigkeit / Komplexität / Wartung gewünscht) - Auch in Mikrocontrollern einfach umsetzbar (ESP8266, ESP32, Arduino) - ZMQ erfüllt dieses Kriterium nicht - MQTT erfüllt diese je nach Hardware - alternativ selbst entwickeln? - kennt jemand Bibliotheken für Arduino und ESP? - Problem der NAT (Netzwerkübertragung in eigener Infrastruktur) bzw. Firewalls (HTTP generell sehr einfach durchzukriegen), bidirektionale Schnittstellen schwerer, IP-finden zulassen, Sicherheitrelevanz? - Fast alle Web-Dienste bieten eine HTTPS-Schnittstelle (REST) an, dadurch sehr einfache Anbindung externer Tools (ohne strenge Kopplung) - Nextcloud - Calendar - Chats wie RocketChat - Trello/Openproject - OpenHab/HomeAssistant - Odoo - Durch Schaffung einer eigenen HTTPS Schnittstelle (z.B. REST) kann das System auch nach außen/extern ankoppelbar/integrierbar gemacht werden (Andere Dienste, Skripte) - Verschlüsselt / Sicherheit hoch - Verbreitung sehr hoch - Einfach zu verwenden
- Es können natürlich auch weitere Protokolle angebunden werden, wie bspw.: - MQTT - Websockets - ZMQ - RabbitMQ - meist als Flask-Extension verfügbar (siehe Punt Flask (Backend-Entwicklung) - Frage ist eher, welche ist der Erstwunsch bzw. welche als Hauptschnittstelle
### Eigenentwicklung von Hardware - Eigenentwicklung von Hardware für Endkunden ist in Deutschland teuer und bürokratisch - **CE Zertifizierung** - relativ einfach - geringe Kosten - Verantwortlichkeiten/Rechtliches teilweise unklar - **Sicherheitsbestimmung 230V** - mittel kompliziert - geringe Kosten - Verantwortlichkeiten/Rechtliches unklar - **VerpackungsG** - einfach - mittlere Kosten - Verantwortlichkeiten/Rechtliches klar - **ElektroSchrottVerordnung ElektroG** - kompliziert - hohe Kosten, einmalig + jährlich - Containerlotterie - Rechtliches unklar - **ROHS Konfirmität** - einfach - geringe Kosten - Rechtliches relativ klar - Komponenten lieber als Set zusammenstellen - Hilfe zur Selbsthilfe anbieten (Leiterplatten, Bausätze?!) - Allgemein liegt die Hardwareverantwortung eher in den jeweiligen Gruppen was auch meist so gewünscht ist - Alternative B2B-Verkauf (keine Consumern, nur z.B. Vereine) da es dann einfacher ist. Es ist trotzdem noch aufwändig. ## Systemdesign ### Koordinator - Zentraler Server mit Anbindung an verteilte Systeme - **Vairante A: Lokal** (z.B. Raspberry Pi Server) - Lokal im Space und kann ggf. nur dort erreicht werden - Ansprache über IP statt Domain möglich - Selbstgeneriertes Zertifikat für HTTPS notwendig - Zugriff benötigt DynDNS - **Varinate B: Gemieteter/eigener Server** - Domain angebunden - letsencrypt Zertifikate - kann von überall erreicht werden - Serversicherheit und Datenhoheit je nach Gruppe anders priorisiert (persönliche Wahrnemung) - Einsicht des Kontos über Website (Frontend) ggf. App - Integration externer Hardware über Backend möglich - Administration der User Nodes zentral über Website (Frontend) - Permissions als Gruppen verwaltet durch Server - Gruppenverwaltung (Zugriffe, Zugänge) angedacht, verwaltet durch Server ### Nodes - Verteilte Eingabe/Steuer-Geräte (Knoten/Nodes) - Beispiele: - RFID-Reader fürs Büro zum Verwalten von Karten - Terminal zum Aufladen der Karte mit Guthaben - Terminal zum Auslesen von Guthaben nach Eingabe einer Pin - Türschlossansteuerung ggf. mit Öffnungsdetection - Relais zum An/Freischalten von Geräten - Nodes verbunden per Lan oder Wifi an Server (lokal/extern) - Knoten laufen autonom und sind möglichst dumm (werden vom Server gesteuert) - Knoten laufen mit möglichst geringer Hardwareanforderung (ESP, kein Linux, 4MB Ram, Arduino je nach Typ) - Knotenkosten gering: - Relay und RFID-Knoten < 20€ (mit display < 50€) - Türschlossknoten > 50€ - Knotenhardware ggf. selbst entwickeln (siehe Hardware bzw. Bedenken oben) - Knoten ggf. mit Wifi-Mesh-Funktion (siehe ESP32-Mesh : [https://docs.espressif.com/projects/esp-idf/en/latest/api-guides/mesh.html](https://docs.espressif.com/projects/esp-idf/en/latest/api-guides/mesh.html)) ### Authentifikation - Authentifikation über RFID-Karten + optionaler Pin-Auth (ggf. über Smartphone mit Pin-Auth) - 13,56 MHz Mifare favorisiert - Desfire sollten auch gehen - Gewünscht nur UID auswerten, da andere Karten dann wiederverwendet werden können wie Studentenausweis - dann aber 2ter Faktor notwendig! - Smartphone NFS evtl. später (haben hier keine Erfahrung damit, nicht niederschwellig da vom Smartphone abhängig > Parallel anzubieten) - 125kHz evtl. später integrieren ### Beispiele des Datenflusses #### Freischalten neuer Karten im Büro - Heartbeat überprüft alle 10 Minuten ob noch eine Verbindung zum Server besteht (am besten mit Alarm bei Ausfall) - Wenn Karte erkannt wurde, Senden der Kartennummer etc. an Server (sofort) - Zuordnung im Frontend (Zuweisung nach Gruppen) #### Gerät freigeben - Heartbeat überprüft alle 10 Minuten ob noch eine Verbindung zum Server besteht (am besten mit Alarm bei Ausfall) - Wenn Karte erkannt wurde folgt sofortiges Senden der Authentifizierungsanfrage an Server (ggf. erweitert um Pinabfrage) - Server prüft und gibt direkt Rückmeldung (bspw. über ein LCD Display und/oder ein Audiosignal) - Knoten schaltet Gerät frei (Relais) #### Öffnen einer Tür (Reader und Türsteuerung an verschiedenen Orten / Knoten) - Heartbeat überprüft alle 10 Minuten ob noch eine Verbindung zum Server besteht (am besten mit Alarm bei Ausfall) - Wenn Karte erkannt wurde folgt sofortiges Senden der Authentifizierungsanfrage an Server (ggf. erweitert um Pinabfrage) - **Variante A:** Server sendet direkt an Steckdose (zWave etc.) den Freischaltbefehl - hat ggf. das Problem der Erreichbarkeit und Firewalls auf beiden seiten - **Variante B:** Server speichert anfrage und wartet auf Pollen der eigenen Hardware/Knoten => Geräteüberwachungs-Node (pollt z.B. alle 0.5s) - Ggf. langsamer, dafür nur ein zentraler “Master” #### Getränke kaufen - Terminal mit RFID Lesegerät neben der Getränkequelle - Wenn Karte erkannt und die PIN korrekt ist (bei 2FA) wird Guthaben vom Konto auf der Serverseite abgebucht ## roseguarden Backend - Backend in Python - Flask als Framework - Entwicklunsgumgebung VS Code (mit Anaconda), einfache Einrichtung (andere mögliche, sublime, vim etc) - Modulares System (Pluginsystem) - Problemstellungen abstrahiert und modularisiert nach “Workspaces” - Beispiele für Workspaces: UserAdministration. Spaces, Permissions etc. - Workspaces (Plugins) werden als einfacher Ordner mit Python-Files (nach einer Vorlage) einfach in das Projekt kopiert und werden dynamisch beim start geladen - Umsetzung als Klassen die geladen werden - Jeder Workspace (Plugin) kann Seiten (Pages), Daten (DataViews) und Aktionen (Actions) hinzufügen - Supervisord zum automatischen Update, Migration der Datenbank, Backup - Backend generiert keine Seiten sondern stellt Daten/Logik bereit (Frontend zur Darstellung unabhängig) ## roseguarden Frontend - Frontend mit Vue und Vuetify (Material GUI Komponenten) - Separat von Backend (kann separat Entwickelt, getestet werden) - Entwicklunsgumgebung VS Code (mit Anaconda), das gleiche wie Backend - einfache Installation dank npm - Einfache Struktur dank nuxt (einfach dateien kopieren) - Styling (Farben, Icons, etc.), sehr einfach möglich - Frontend beinhaltet keine Logik sondern bekommt Befehle und Daten durch Backend - Siehe Demo + Repo ## roseguarden Hardware - Möglichst günstig und weit verbreitet Hardware einsetzen - Wir nutzen [Olimex-Module](https://www.olimex.com) (Bulgarien) - [Gateway mit Relay](https://www.olimex.com/Products/IoT/ESP32/ESP32-EVB/open-source-hardware) 26€ ![](https://pad.gwdg.de/uploads/8af231e4-cc3a-4174-b798-6a373869974b.png) - [RFID ID Reader](https://www.olimex.com/Products/Modules/RFID/MOD-RFID1356MIFARE/) 13€ ![](https://pad.gwdg.de/uploads/1a84ebb3-88f6-4814-84d8-502feac55cdc.png) - [Power over Ethernet Knoten](https://www.olimex.com/Products/IoT/ESP32/ESP32-POE-ISO/open-source-hardware) 25€ ![](https://pad.gwdg.de/uploads/c328cca9-9a40-4811-a3b0-42cff95db4bd.png) - [Display mit Touch](https://www.olimex.com/Products/Modules/LCD/MOD-LCD2-8RTP/open-source-hardware) 15€ ![](https://pad.gwdg.de/uploads/b2d5dcb5-ba3c-48b3-9c07-f969acce1e5f.png) - jeweils auch mit externer Wifi-Antenne möglich - ESP32 immer auch mit Akku möglich - Andere Module Anschließbar - Basis ist die ESP32 Mikrocontroller-Familie - Eigene Hardware (Leiterplatte entwickelt, für Eigenbedarf) - Integration anderer Hardware möglich **Weitere Hardware** - [Bildschirm mit Touch](https://nextion.tech/basic-series-introduction/) (Nextion) ab 20€ - Aktuell wird dieser Touchscreen von uns verwendet - Grund dafür ist, dass die Entwicklung eines Frontends dank der mitgelieferten Software sehr einfach mit einer GUI erfolgen kann --> kürzere Entwicklungszeit ![](https://pad.gwdg.de/uploads/88b20f78-353c-4f6f-aba5-fb2826d9cc46.png) ![](https://pad.gwdg.de/uploads/5f93be8e-e553-4ce5-a14f-8c393259c0c2.jpg) ![](https://pad.gwdg.de/uploads/c239e684-54a5-4f64-a2da-78c6f4806770.jpg) - [ABUS Funk-Türschlossantrieb HomeTec Pro CFA3000](https://www.abus.com/ger/Sicherheit-Zuhause/Tuersicherheit/HomeTec-Pro/HomeTec-Pro-CFA3000) @100€ - Da es in unseren Räumen schon mehrfach zu Einbrüchen kam, ist der Wunsch nach abschlossenen Türen aufgekommen - Das Makerspace aus Oldenburg hat mir (Kevin) den Tipp gegeben dieses Gerät zu verwenden. - Der Schlossantrieb hat seitlich zwei elektrische Kontakte mit denen man den Antrieb steuern kann - Weiterer Vorteil ist hier auch, dass es im Notfall immer auch manuell betrieben werden kann. Selbst wenn der Strom ausfällt ![](https://pad.gwdg.de/uploads/d9be0256-3f92-4417-a780-39cf5bfce635.png) - Domra Türöffner (Summer) ca. 20€ ![](https://pad.gwdg.de/uploads/2c25df8c-f266-4169-a146-ddc8aa8503d0.png) **Interessante Hardware für später** - zWave Hardware - HomeKit Hardware - … ## roseguarden Firmware für die eigenentwickelte Hardware - C++ für ESP32 - Entwicklungsumgebung Eclipse mit Esspresif-IDF (VS Code denkbar, bisher keine Arduino IDE) - eigene VM vorhanden (kann gerne geteilt werden) - Bibliotheken von Espresif (JSON-Parser, Wifi, Bluetooth, etc.) - FreeRTOS als Mikrobetriebssystem - Verwendung bestehender Bibliotheken - Modularer Ansatz (Kapselung in Klassen) - … ## Berücksichtigte/Angedachte UseCases (Features) - Zugriff und Rechte als Gruppen - Benutzerverwaltung ggf. Vereinsmitglieder - Zugangskontrolle Türöffner - Gerätefreischaltung angedacht - Nachrichtensystem (inklusive Alerts für Admins) - Buchungssystem? - Buchhaltung (DATEV)? - Geld aufladen? - Mitgliederbeiträge verwalten (Fintech, SEPA) - … - tbd ## Offene Punkte - Lizenz Software (Wunsch GPLv3) - Lizenz Hardware (Open Hardware Lizenz) - Datenschutz / DSGVO? - Rechtlich saubere Struktur notwendig? Verein? etc. - Bündeln der Kapas, nur wie? - Wie werden Entscheidungen getroffen - Gutmütiger Diktator/ Managergremium - Basisdemokratische Abstimmungen vs Abstimmung in Gremien - Wie alle auf einen Wissensstand bringen - Systemisches Konsensieren ([http://www.sk-prinzip.eu/das-sk-prinzip/](http://www.sk-prinzip.eu/das-sk-prinzip/)) ## Historie von roseguarden - Roseguarden entwickelt als Version 1 ([https://github.com/mdrobisch/roseguarden](https://github.com/mdrobisch/roseguarden)) - Backend: Python + Flask - Frontend: AngularJS + Bootstrap - Hardware: Raspberry Pi + Relays + RFID-Reader - Produktivsystem seit 2014 in Dresden - Mit verschiedensten Anwendern in Kontakt (Spaces, Fablabs, Vereine, Firmen z.B. Lager, Event-Veranstalter) - Vor 4 Jahren 1. Versuch Systeme zu vereinheitlichen und Leute zu finden, die mitentwickeln (Vernetzungstreffen des Verbund Offener Werkstätten e.V. 2015 in Dresden) - Einreichung im Prototypefund (als Gruppe 3 Personen, und einzeln) - Feedback/Fazit: Kombi aus Hardware und Software zu kompliziert und nicht gut vereinheitlichbar, - woanders Förderbar: Anstiftung, BMBF direkt?! - Seit Jan. 2019 Planung um Umsetzung einer Version 2 in einer Gruppe von 3 Leuten