03.12.2019 // Roseguarden

Repositories (v2): https://gitlab.com/roseguarden
Demo: 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
  
  (Quelle: 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
  • 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
• 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
• 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
• 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
• 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

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)

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 (Bulgarien)

  • Gateway mit Relay 26€
    
  • RFID ID Reader 13€
    
  • Power over Ethernet Knoten 25€
    
  • Display mit Touch 15€
    
  • 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 (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
    
    
    

• ABUS Funk-Türschlossantrieb 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
    

• Domra Türöffner (Summer) ca. 20€
  

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/)

Historie von roseguarden

• Roseguarden entwickelt als Version 1 (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