Meeting Notes / Pads
Sicherungskopien aller uns bekannten, geteilten Pads (z.B. CodiMD, HackMD, HedgeDoc) und Protokolle. Warum? Weil Daten im Netz auch mal verschwinden und weil wir an einem zentralen Ort alles besser durchsuchen können! Viele, aber nicht alle dieser Notizen wurden in die laufende Dokumentation eingearbeitet. Dieser Bereich versteht sich als Stöberarchiv.
Solche Pads sind ungeheuer praktisch, da sie die kollaborative Arbeit in Echtzeit ermöglich. Jedoch sind sind nur eine flüchtige, lineare Darstellung von Inhalten, die über die Dauer keinen Zusammenhang ermöglichen - ähnlich, wie Chatverläufe. Es ist äußerst schwer, sie zu pflegen und alle im Blick zu behalten.
Aktuelle News gibt es unter Blog / Historie
- 13.12.2024 // Koordinationscall Jonny + Mario + Max
- 06.11.2024 // FabAccess Community Call
- 28.10.2024 // Meeting-Protokoll Koordinationsteam FabAccess
- 23.10.2024 // FabAccess PCB v2 (FabReader)
- 10.10.2024 // FabAccess Developer Team Call 10.10.2024
- 29.08.2024 // FabAccess by DSEE
- 20.08.2024 // Strategiecall am 20.08.2024
- 10.07.2024 // Laufende Dokumentation im Projekt FabAccess
- 27.12.2023 // FabAccess FAQ
- 16.03.2023 // Öffentliche Aktivitäten von FabAccess - Stand 16.03.2023
- 04.03.2023 // FabAccess Notizen
- 03.02.2023 // NFC Lib - DESFire
- 07.12.2022 // Chat & Notizen FabAccess-CommunityCall
- 24.04.2022 / Roadmap
- 24.01.2022 // Mitschrift HTW
- 26.12.2021 // Name for the Abstraction Layer of the Server and the Protokoll in Capn Proto
- 14.12.2021 // Install FabAccess
- 22.11.2021 // Prioritäten
- 30.09.2021 // Config Docs
- 26.09.2021 // CI Docs
- 25.09.2021 // Drehstrom Schalter
- 20.03.2022 // Design Decisions NFC Reader
- 22.09.2021 // FabAccess Workshop
- 20.09.2021 // Workshop Beschaffungsliste
- 11.09.2021 // Drehstrom Schalter und Strommessung
- 30.08.2021 // Informationsangebot
- 15.07.2021 - Meta-Pad Zugangskontrollsysteme f. Offene Werkstätten
- 30.06.2021 // Interfacer Deliverables
- 29.04.2021 // Netzwerkabend Offene Werkstätten 04
- 06.04.2021 // Produkte für FabAccess
- 31.03.2021 // Abschlussbericht
- 19.02.2021 // Demoweek Webseitentext - Korrektur
- 12.02.2021 // DemoWeek: Videoskript
- 12.02.2021 // Demoweek: Webseitentext
- 02.02.2021 // FabAccess Struktur
- 26.01.2021 // Projektskizze FabAccess IGP
- 26.01.2021 // Borepin Doc
- 22.01.2021 // Antwort Repair-Cafe
- 21.01.2021 // API Meeting
- 15.01.2021 // Maschinenlist - D,A,CH
- 09.12.2020 // Punkte Chaostreff Potsdam
- 06.12.2020 // Transcript Test Meeting
- 01.12.2020 // Zusammenfassung - Freies Meeting
- 24.11.2020 // Webseiten Text
- 18.11.2020 // Stellenausschreibung - SHK
- 16.11.2020 // Themen für eine SHK Stelle
- 19.10.2020 // How to Prototype Fund
- 16.10.2020 // Contribute - Borepin
- 15.10.2020 // Team-Meeting 15.10.2020
- 13.10.2020 // DESFire Protokoll
- 13.10.2020 // Mitschnitt - OTA Proof-of-Concepts
- 05.10.2020 // QR-Code/NTAG Identifizierung
- 05.10.2020 // Audit Log
- 05.10.2020 // Kartenverwaltung
- 01.10.2020 // Kooperationsvertrag
- 28.09.2020 // Prototypefund Monday Update - 28.07.2020
- 21.09.2020 // Prototypefund Monday Update - 21.09.2020
- 21.09.2020 // Tooling für das FabAccess Team
- 07.09.2020 // Monitoring
- 07.09.2020 // Nutzungs- / Nutzerverwaltung
- 05.09.2020 // Gespräch mit Joris 05.09.2020
- 05.09.2020 // Features zur Diskussion
- 04.09.2020 // Offene Fragen
- 04.09.2020 // Föderation
- 04.09.2020 // Maschinenkontrolle
- 04.09.2020 // Föderartions Konzept
- 11.08.2020 // August-Call Nr. 1 Fab-Access
- 21.07.2020 // Themensammlung Juli-Call FabAccess
- 24.06.2020 // Call zu Werkstatt-Zugangssystemen 2020-06-24
- 06.03.2020 // Probleme die wir im Backend noch lösen müssen
- 06.03.2020 // Diskussion in der Telegram-Gruppe des VoW am 25.02.
- 18.02.2020 // Hackathon, 07.02.20
- 18.02.2020 // JitSi Call 18.02.
- 04.01.2020 // Materialsammlung 29.12.2019 @36C3
- 13.12.2019 // Protokoll Jit.si-Konferenz 09.12.19
- 09.12.2019 // Grundlegendes
- 09.12.2019 // Vorbereitung Jit.si-Konferenz am 09.12.19
- 08.12.2019 // OAS 4 All
- 03.12.2019 // Roseguarden
- 01.12.2019 // Mumble-Sitzung 26.11.19
- 20.11.2019 // Open Access System_Dokument zum Verbundstreffen
13.12.2024 // Koordinationscall Jonny + Mario + Max
Ort + Zeit
- https://jitsi.stadtfabrikanten.org/fabaccess
- 17:00 bis 18:45
Mit dabei
- Jonny
- Mario
- Max
Agenda
Prototype Fund bis Anfang Januar 2025 - wer, was, wie, warum?
- Frist 01.-02.01.2025
- https://new.prototypefund.de/#bewerbung
- Skizze: 2 leute bewerben; falls man weiter kommt, dann in antrag mehr Leute einfügen
- wir bewerben uns als Privatperson, nicht als Orga, nicht als Verein und müssen eine GbR gründen
- nach Rücksprache mit Max und Jonny kommt das für 2025 eher weniger in Frage. Es haben sich bisher und in Kurzfristigkeit noch keine Leute für das Projekt gefunden - zumindest nicht, um gemeinsam neue Fördermitel zu berantragen. Zusammen haben wir deshalb besprochen, dass unabhängig von einem Förderantrag trotzdem das Schreiben eines Konzepts a.k.a. aktueller Roadmap für das FabAccess-Projekte sinnvoll ist und zu gegebener Zeit die Roadmap als Ausgangsmaterial für weitere Bewerbungen genutzt werden kann!
Roadmap-Ideensammlung
- als erstes:
- Server: Bugs fixen, dependency-update und Bugfix-Release 0.4.3 rausgeben, um neue entwickler nicht sofort zu verschrecken
- bffh mit aktuellen Rust-Versionen kompilierbar machen
- Client: Bugs fixen + Build-Pipeline reparieren (Mac, Windows, Linux)
- neue Features und Bugs siehe GitLab Issues:
- https://gitlab.com/fabinfra/fabaccess/bffh/-/issues
- https://gitlab.com/fabinfra/fabaccess/borepin/-/issues
- Max: Zugangssystem nicht nur für offene Werkstätten, sondern allgemein für Ausleihboxen, soziokulturelle Räume, Vereine -> wie realistisch ist das?
- Einschätzung Mario: es braucht mind. einen erfahrenen Admin für jede Organisation, um FabAccess sinnvoll aufzusetzen - selbst, wenn man es mit Docker oder apt package installieren kann, denn es hat viel mit Netzwerk-, MQTT- und Sicherheitskonfiguration zu tun
- Mario: FabAccess-Hardware Verleihsetups in physisch machen, um das ganze zu streuen. Demo-Setup von Mario steht zur Verfügung. Es bedarf mehr Hardware für mehr Demo-Setups. Dann könnten per DHL-Paket 2-3 Kisten in Deutschland umherwandern
- https://gitlab.com/fabinfra/fabaccess/bffh/-/issues
- Localization -> bessere Zugänglichkeit / europ. Vernetzung
- SSO advanced - neben OIDC noch weitere SSO-Möglichkeiten einbauen
- SAML / Shibboleth (wird gern an Unis verwendet)
- Einweisungen mappen: es gibt aktell kein Feature, um nachzuvollziehen, warum ein Nutzer überhaupt eine Berechtigung hat (auf welcher Basis, z.B. Schulung)
- allgemeines Rule-System mit Triggern/Einschränkungen für Spaces, Maschinen, Benutzer
- Notification-System per Mail
- den Benutzern/Admins Reports/Statistiken/Logs senden
- Erinnerungen senden, z.B. Passwort-Reset anfragen
- Push Benachrichtigungen in der App: z.B. erinnern, wenn eine Maschine zu lange läuft und der Benutzer den Space verlassen will, ohne diese zurückgegeben zu haben
- Datenbank ist unflexibel und Zweck der users.toml fragwürdig: SQL-Basis gewünscht (z.B. MariaDB / Postgres / SQLite)
- erlaubt auch das Einbinden in Grafana, sowie die bessere Verfügbarmachung für LDAP
- Türen / Schließfächer öffnen (statt USE + GIVEBACK einen Einmal-Trigger)
- Ausleihen und Zurückgeben als Funktion fehlt
- Reservierfunkion fehlt
- Föderation als Funktion fehlt
- Maschinen können geblockt oder deaktiviert werden, aber es gibt z.B. kein Wartungsprotokoll dazu, wenn mit diesen Maschinen etwas gemacht worden ist
- bffhd Debian Paket bauen (Mario)
Mailbox
Leider immer noch kein Mailbox Zugang für Webmaster -> damit kein Management für Google Sitemaps, Sicherheitsmeldungen, Login-Mails oder Kontaktanfragen möglich -> stellt ein großes Problem dar! > Jonny legt ein neues Postfach an und die MX-Records bei den Domains werden entsprechend angepasst. Es betrifft u.a. fab-access.org, fab-access.info, fab-infra.de
Events
- CCC Hamburg 27.-30.12.2024
- mit dabei: Mario, Jonny, Max, ... ?
- einen Raum für spontanes Assembly, wo wir uns einrichten können, organisiert Jonny innerhalb der Chaosgruppe
- angedacht: FOSDEM Brüssel 01.+02.02.2025
- mit dabei: evtl. Mario + Axel Just
- Chemnitzer Linux-Tage (CLT) 2025 (Vereinsstand Stadtfabrikanten e.V. und/oder Vortrag zu FabAccess)
- Community Call Mitte Januar 2025 geplant. Datum + Zeit müssen noch gefunden werden
Sonstiges
- neu entstandene Tools zum Test:
- https://vote.fab-access.org (Astuto Upvote Tool; noch nicht 100% klar, ob es förderlich oder too much ist)
- https://hardware.fab-access.org - Asset Manager
06.11.2024 // FabAccess Community Call
19:00 Uhr bis 20:30 Uhr
mit dabei
- Mario / Stadtfabrikanten
- André / Sternenlabor e.V.
- anjusch (sie/ihr) | VOW
- Bodo (WerkBox3)
- Johannes, (Schafferei - Offene Werkstatt Göppingen e.V.)
- Julian ZAM
- Roy (MS Leipzig)
- thejonny = Jonathan Krebs (ZAM)
- Tim & Michael (Makerspace Gütersloh)
- Tobias (Attraktor e.V.)
- OWBA (Offene Werkstatt Bamberg)
- Klaus Lütkebohle
- Joris (MakerSpace Bocholt)
- p.t.flea (Offene Werkstatt Bamberg)
Themen
Mario stellt die Sammlung vor, die er bisher angelegt hat. Ziel: Wissen gemeinsam teilen, besonders bei "FabAccess Installation"
Trägerschaft des Hostings evtl. beim VOW? (Das betrifft z.B. Bookstack, Stickergenerator, Demoserver, Download-Bereich --> die Doku soll offline downloadbar sein)
Anschlussfinanzierung für FabAccess möglich? Das könnten auch einzelne Werkstätten organisieren und da könnten dann auch wieder Honorarkosten für Entwicklung bei rausspringen.
Umfrage: Wer mag in Plauen beim Sternenlabor mal einen Besuch abstatten (haben FabAccess in der Elektrowerkstatt schon m Einsatz)?
https://github.com/manyfold3d/manyfold
Tobias vom Attraktor e.V. kümmert sich um Vorstellung FabAccess auf dem CCC --> Fragt in den Gruppen, ob noch weitere Personen aus der FabAccess Community zum CCC in Hamburg kommen
Mario: FabAccess Client installiert mit Waydroid (Android Emulator auf Linux)
Das Bauen der App ist nicht so super easy. Probiert auf Linux und Windows. Wer kann helfen, den aktuellen Client erfolgreich zu kompilieren und das zu dokumentieren? Das ist überdies hilfreich, auch wenn es ggf. irgendwann mal einen Web Client gibt
28.10.2024 // Meeting-Protokoll Koordinationsteam FabAccess
Wo?
https://bbb.cyber4edu.org/rooms/max-7sh-m1t-w95
Wann?
15:00 - 16:15 Uhr
Wer?
- Anjusch
- Mario
- Jonathan
Agenda / Themen
- Gitlab
- Zugang für GitLab anlegen -> Account thejonny (siehe https://gitlab.com/groups/fabinfra/-/group_members)
- Anjusch Zugang reaktivieren (https://gitlab.com/Anjuschmidt)
- Rollenverteilungs-Kanban anlegen
- Wie, wo ? -> könnte Anjusch übernehmen
- evtl. in Gitlab?
- Arbeitsstand Software
- Johnny arbeitet an Rust-SASL, baut SSO mit OpenID Connect weiter; erste Pull Requests
- Arbeitsstand Doku
- Dokumentationsplattform BookStack lebt. Ist noch nicht sauber aufgeräumt, aber Struktur + Inhalte nimmt gute Form an. Bereits Feedback eingeholt z.B. von Tasso, Joris, Luca und weiteren FabAccess-Enthusiasten
- Vorstellung im Community Call
- Kontakt Joseph -> Domains/Hosting bzgl. Umschaltung DNS notwendig
- BookStack-Zugänge an Jonathan und Anjusch vergeben
- weitere ToDos
- gegenchecken, ob die jetzigen Inhalte so in Ordnung sind
- Issue Tracker fü BookSTack auf GitLab?
- Sonstige Infos
- Mario war zu Besuch MakerSpace Leipzig -> Roy + Wolfram haben Config Generator Tool gezeigt; würden dieses evtl. auch in Erlangen vorstellen!
- Ungeklärtes / Fragen
- Einstampfen obsoleter Git-Projekte (archivieren + README-Update)
- wie funktioniert das Versionierungsschema für FabAccess API/BFFH/Borepin?
- Kommende Termine
- Community Call 06.11.
- Besuch Sternenlabor Plauen?
- JHV Erlangen - ShowCase
- Equip-Liste / Programm-Details erstellen
- aktuell im Austausch mit Jochen und Hanna vom ZAM
- ??? CCC Leipzig 2024 ???
23.10.2024 // FabAccess PCB v2 (FabReader)
Link zur v1: https://gitlab.com/fabinfra/fabhardware/fabreader
Link zur v2: https://gitlab.com/fabinfra/fabhardware/FabReader2 (Repo ist private - nur für Entwickler sichtbar)
Meeting Notes
Wann? 23.10.2023 ab 17 Uhr
Wo? https://meet.jit.si/makerspace-gt
dabei
- Michael - Makerspace Gütersloh (+3 Couch-People)
- Luca - Hackwerk e.V. Aalen
- Elektronikdude :-)
- Sarah - Makerspace Gütersloh
- Nils - Hackwerk e.V. Aalen
- Mario - Stadtfabrikanten e.V. Chemnitz
- Tobias - Attraktor e.V. Hamburg
- Axel - Betreiberverein ZAM e.V.
- Joris - Makerspace Bocholt e.V.
Was soll FabReader grundlegend können?
- Türen öffnen
- Maschinen einschalten
- DESFire Karten supporten
- Status der Maschine anzeigen (z.B. via OLED)
- NICHT Karten provisionieren (macht man eher separat am Rechner)
Gewünschte Features
- Buzzer
- Jumper setzen oder Pins umplatzieren, weil sonst andauerndes Buzzen
- POE
- Splitter verwenden -> Deutlich billiger als selber bauen
- Neues ETH Modul, welches die CPU entlastet
- aktuelles Modul performance-technisch nicht ideal (Package-/Frame-Verluste)
- neues Modul ist kompakter
- Gehäuse angepasst für Module mit standard Stiftleisten
- Keine nachträgliche kürzung nötig
- Befestigung
- Magnete im Gehäuse zur einfachen Befestigung an Maschinen aus Metall
- Verschraubungen vorsehen
- sinnvolle Mounting holes der Platine selbst im Gehäuse
- Langloch zum einhängen
- (Saugnäpfe?)
- USB-C
- war Micro-USB
- Optional Nummernpad für Relaisboard (4x4 Matrix)
- Ziel: ein zentraler Reader für verschiedene Freigaben
- Typ: ganz normales Folien-Numpad, Alternativ:
- https://www.digitalo.de/products/260033/APEM-AC3535-Folientastatur-selbstklebend-mit-Beschriftungsstreifen-Tastenfeld-Matrix-4-x-4-1St..html
- oder
- https://www.distrelec.de/de/tastatur-eao-eco-12150-06/p/13567415
- oder
- https://www.voelkner.de/products/3849664/TRU-COMPONENTS-Drucktastenfeld-Tastenfeld-Matrix-3-x-4-1St..html
- Modelldaten
- kommen per Blender durch Nils als Open Source :-]
- “howto modify” für Nicht-Blender-Leute mit PrusaSlicer o.ä.
- Display: OLED
- e-Ink Idee beim v1 wurde verworfen
- dringend gesucht: Jemand, der für die Hardware eine passende Firmbau baut (Mockup kann Luca machen, aber keine Zeit für Firmware-Volldevelopment) -> im nächsten Community Call am 06.11. rumfragen, wer hier helfen kann (+Recycling vom vorhandenen Code von Joris und/oder Hackwerk)
- RFID Modul ggf. von RC522 zu PN32 tauschen
- optionale Optokoppler-Ausgänge für frei programmierbare Features
Abgelehnte Features
- Außenwettertauglichkeit
- schwierig, weil alles abgedichtet werden muss - auch Tastaturen, USB-C und Display; erhöht die Komplexität vermutlich zu sehr, um es zu implementieren; potentiellem Vandalismus oder Manipulation ausgesetzt
- Alternative: Montage unter einem Dach -> nicht spritzwassergeschützt, aber halbwegs wetterfest
- interessante Idee: kann FabReader durch ein Fenster durch agieren?
- Joris: Thema war bereits Idee bei Reader v1. Vorschlag: Signale per SPI Interface ins innenliegende Gebäude ziehen
- Yubikey/FIDO Support an USB-C Buchse
- Vermutlich eher aktuell nicht kompatibel mit ESP32, außerdem nicht in FabAccess Core implementiert
Wer macht mit?
- Luca / Hackwerk e.V. ->
- Hardware / Platinen-Design (Löten in Aalen mit eigenem Lötofen) + evtl. Mockup für Firmware
- Flashing der Firmware
- Platinen-Order bei JLC
- Nils -> Gehäuse-Design via Blender
- Ziel: Produktion von 50 Stück FabReadern (sind bereits budgetiert via DSEE Förderung)
- wer macht Firmware? Was ändert sich zu v1?
- Ethernet Chip
- Pin-Belegungen
- 3D-Drucken der Gehäuse: soll jeder Space selber machen
- Dokumentation: Mario / Chemnitz
Sonstige Notes
-
Feedback FabReader v1 - gut und schlecht
- Luca: Hardware eher so hmmm^^
- Nils hat ein neues Gehäuse gemacht, damit’s stabiler und cooler ist
- Luca: würden mal ein paar Testiterationen für eine PCB v2 ordern und testen (geplant)
- Luca: nutzen eigene Firmware für FabReader
- v1 wurde jetzt ca. 2 Jahre nicht mehr so richtig weiterentwickelt
- Gründe für den Reader überhaupt: Leute, die weniger mit Smartphones unterwegs sind, abholen (DESFire Karten)
- RC522 RFID Module: Qualität bei v1 dieser Module hat extrem gestreut -> keine wiederholbare Qualit lt. Joris
- der Reader kam nie so wirklich zum Einsatz :-(
-
Zielkosten für das ganze Gerät ca. 20-30 € (FabReader v1 war mal für ca. 13 € kalkuliert)
- Grundkosten: Platine, ESP32 und ein paar Bauteile + Filament
-
v2 Reader - how to support
- finale Liste der Features aufstellen + konkrete Ausformulierung, damit das Teil möglichst universell ist und für viele offene Werkstätten gut geeignet ist
- Firmware-Überarbeitung des “sehr beta Status” als proof-of-concept in eine Prod-Variante überführen
- Bestellung aller Komponenten muss bis Ende des Jahres abgewickelt werden, weil DSEE-Förderung -> es gibt noch ein Restkontigent von 21 Readern, die auf nicht-geförderte Werkstätten geteilt werden können
10.10.2024 // FabAccess Developer Team Call 10.10.2024
Ort: https://bbb.cyber4edu.org/rooms/max-7sh-m1t-w95/join
Zeit: 14:00 bis 15:10
Anwesend:
- Maximilian Voigt (VOW)
- Anjusch Schmidt (VOW)
- Jonathan Krebs (Betreiberverein ZAM e.V.)
- Mario Voigt (Stadtfabrikanten e.V.)
Agenda:
- Allgemeine Vorstellung von Anjusch, Max, Jonathan, Mario
- wer macht(e) bisher was und warum?
- Ziele für FabAccess dieses Jahr (Vorstellung von Max): Bis Ende des Jahres läuft in 7 OWs FabAccess, bis Ende des Jahres gibt’s eine Doku und FAQ. Im Frühjahr sollten die Entwicklungs-Projekte von Jonny abgeschlossen sein (APP)
- Offene Fragen: Wer testet? Wer entwickelt mit? Wie arbeiten wir als Community zusammen?
Rollenverteilung
-
Max: Verantwortlich für Finanzen und Anträge
-
Jonny: Softwareentwicklung (Single Sign On sollte bis nächste Woche stehen)
-
Mario: Dokumentation und Wissen zusammentragen aus der Community, kann die Tools auswählen, die für ihn am besten funktionieren. Überblick über Zugänge.
-
Anjusch: Schnittstelle VOW, Unterstützung bei Community-Calls und Kommunikation
-
An Joseph können inhaltliche Fragen gestellt werden
-
Dokumentation / Web /Hosting
- Homepage ist seit 08.10.2024 kaputt: weil Odoo-Lizenz nicht verlängert bzw. gerade im Umzug
- Domains liegen bei Joseph und sind erstmal weiterbezahlt. Bei Auslauf der Domains meldet er sich bei uns
- Joseph kann erstmal Domain Redirects / DNS Settings liefern
- Projekt soll erstmal unabhängig (dezentral) vom VOW als Community-organsiertes Projekt weiterlaufen
- soll neu gestaltet werden, damit die Inhalte besser und aktueller aufbereitet werden können. Es fehlen Bilder, Videos, Links und vieles, was FabAccess bzw. FabInfra für Nutzer plastisch nachvollziehbar macht
- z.B. mit dem bewährten Wiki-Tool Bockstack aufsetzen (https://demo.bookstackapp.com)
- es gibt keine interne Dokumentation. Diese sollte aufgebaut werden, damit Standards entstehen, mit der die gesamte Gemeinschaft arbeiten kann (z.B. IDE-Setups, Abläufe, geteilte Logins (-> Zugriff auf eine funktionierende Dateiablage, die nicht public für Dritte ist))
- Ziele Doku / Landing Page
- Einbinden einer schönen, sinnvollen Startseite
- Was ist FabInfra / FabAccess
- Übersicht Team - Vorname, Nachname, ggf. weitere Infos wie Avatar, Tel, Mail, Matrix-Chat, div. Links
- Übersicht Community
- Werkstätten, die FabAccess schon nutzen (Name, VOW-Profil, Link, ggf. Werkstatt-Ansprechpartner)
- Einzelpersonen, die auf git viele Commits machen
- Testimonials: Harware-Software-Firmware Beispiele der Werkstätten
- wie kann man mitmachen / unterstützen? Und wo?
- Link-Listen
- Software-Projekte (Addons, Tools)
- Hardware-Projekte (Modifikationen an Maschinen; eigenständige Reader, Schalter, Schlösser, etc.)
- FAQs
- History - über die Entstehung (zeitlicher abriss, beteiligte Leitpersonen und Vereine / Verbände)
- Förderhinweise - wer hat wann mit welchem Umfang was gefördert?
- Kontakt / Impressum
- uvm.
-
klären gemeinsamer Arbeitswerkzeuge
- Video-Konferenzserver (z.B. Big Blue Button, Jitsi)
- Tickets /Aufgaben intern -> ggf. erstmal über ein Pad oder Cloud / Dateiablage (z.B. für KeePass)
- Tickets public (Gitlab Issues + Labels)
- Roadmap und offene Probleme transparent für die Community machen - offen darlegen, was nach all den Jahren nun wirklich geht und was es immer noch nicht gibt - auch auf Fragen, zu denen es noch garkeine Antworten gibt
-
Zugänge
- Max hat Logins von Joseph bekommen. Bitte weiterleiten an an uns
- Mario bitte zum Moderator oder Admin der Element-Gruppen hochstufen
-
Projekt-Meilensteine (siehe auch Projektausschreibung Max)
- SSO via OpenID integrieren (will Jonathan bis ca. Mitte Oktober einbauen)
- LDAP integrieren
- Web Application (kann erstmal später kommen. ggf. auch erst nächstes JAhr)
- großes Ziel: die restlichen 7 Werkstätten sollen bis Ende des Jahres möglichst FabAccess irgendwie sinnvoll zum Laufen gebracht haben
-
Sonstige
- Sticker drucken lassen (multi-purpose: zur Werbung und ggf. zum Bestickern in der Werkstatt (Blanko-Labels))
- gibts hier noch Budget? -> nein, das ist alle. Aber Joseph hat viele Sticker bei sich übrig
- können in allen Werkstätten und spätestens zur JHV verteilt werden
- Joseph bzw. Tasso noch viel Hardware und Zubehör bei sich zuhause -> anfragen, ob wir es zur JHV leihen könnten (nach vorheriger Sichtung, was Sinn macht)
- Sticker drucken lassen (multi-purpose: zur Werbung und ggf. zum Bestickern in der Werkstatt (Blanko-Labels))
-
Nächste Termine
-
Koordinationstreffen mit Anjusch, Max, Jonny, Mario (28.10.) 15 Uhr
- Max ist theoretisch im Urlaub; joined eventuell
-
Rundmail für Community Call mit 1-2 Wochen Vorlauf (online)
-
Community Call Ende Oktober (online) - gemeinsames Einladen Mario + Anjusch über VOW-Verteiler offiziell
- Idee: Anjusch moderiert, Mario schreibt Protokoll bzw. stellt Fragen und sammelt Infos zusammen
- Verkünden, wie es weitergeht
- auf die JHV aufmerksam machen und dass ein Showcasing geplant ist (jeder kann was mitbringen und zeigen)
- Verkünden von Werkstattbesuchen bis Ende des Jahres
-
individuelle Werkstattbesuche vor Ort (Mario)
- gibts hier ggf. noch Reisebudget? -> nein. das ist aufgebraucht
- Ziel:
- Kontakte ausbauen (Leute + Tel + Mail) und in die Element-Gruppen zerren
- Hilfe vor Ort leisten
- FabAccess-Implementierungen vor Ort begutachten, fotografieren, Doku-Schnipsel ergattern, Infos entlocken (FAQs, Docs, Impressionen)
- weitere Bedarfe oder Probleme klären
- erste Ziele für Mario:
- MakerSpace Leipzig (Roy)
- Sternenlabor Plauen (André, Peter, Ralf)
- ZAM Erlangen - bietet sich während der JHV an!
- ggf. weitere aktive Orte oder Musterwerkstätten, je nach Zeit (weil größere Distanz von Chemnitz)
- 35 Services Berlin
FabLab Cottbus- da geht gerade nix mit FabAccess :-(- Attraktor Hamburg
- Gängeviertel Hamburg
- Offene Werkstatt Bamberg
- WerkBox3 München
- MakerSpace Bocholt (Joris)
- MakerSpace Gütersloh
-
JHV / Vulca Erlangen
- FabAccess Showcase am Samstagnachmittag, nach der JHV
- “bring your Hardware” (Showcasing)
- jeder kann seine FabAccess-relevanten Projekte mitbringen, aufbauen, vorstellen - alle Interessierten können gucken und Fragen stellen (eine Mini-Messe)
- Austausch von Hardware für andere Werkstätten
- evtl. kann jemand 3D-Druck Teile für diverse Anwendungsfälle vordrucken und an Werkstätten verteilen, z.B. Kabelplomben
- coole Community Fotos machen (was für den VOW Blog)
- gemeinsame Ideen / Wish-List / Roadmap weiterentwickeln (ggf. im Raum mehrere Whiteboards/Brownpapers verteilen - in jede Ecke ein anderes Thema)
- “bring your Hardware” (Showcasing)
- 23.11.2024 FabAccess-Kurzbericht in der JHV von Mario
- FabAccess Showcase am Samstagnachmittag, nach der JHV
-
29.08.2024 // FabAccess by DSEE
Call am 27.08. mit Jonathan und Andre
- Browserbasierte App
- macht lele
- SSO
- macht jonny
- LDAP gibt’s noch nicht
- macht jonny
- Türen gehen mit Server 0.4.3
Call am 27.08. mit Joseph
- Eigenes Engagement
- erstmal keines, masterarbeit steht an
- Zugänge - welche braucht es?
- Max wird Owner
- alles liegt auf gitlab
- readthedocs.org hostet die dokumentation
- Doku: https://gitlab.com/fabinfra/fabaccess/docs/-/tree/0.9?ref_type=heads
- https://gitlab.com/fabinfra/fabaccess/docs/-/tree/0.9?ref_type=heads
- https://fab-access.readthedocs.io/en/0.9/
- neuer Code für Fabreader: https://gitlab.com/fabinfra/fabhardware/fabreader/-/tree/rebuild
- Hardware könnte neu gebaut werden, is grad frickelig
- wenn jemand ein app-update machen will soll er sich bei joseph melden
- Aufräumen
- github wird gespiegelt
- readthedocs
- gitlab
- dev accounts für google, microsoft und apple liegen noch bei der firma
- Übergabe
- bei joseph melden
- Tür-Einschätzung
- 0.4.3 hat Türfunktion implementiert, stürzt aber nach ner Zeit ab wegen Bufferoverflow, man kann diesen Server nicht updaten, man muss ihn neu aufsetzen und Nutzerdatenbank neu einladen
- Problem: Bug nicht reproduzierbar
- Aufgabe: Serversion testen und Bug finden, kann ggf. auch mit regelmäßigen reboots behoben werden
- 0.4.3 hat Türfunktion implementiert, stürzt aber nach ner Zeit ab wegen Bufferoverflow, man kann diesen Server nicht updaten, man muss ihn neu aufsetzen und Nutzerdatenbank neu einladen
- Rechnung von Joseph?
Ablauf Call am 12. und 13.12.
- Ankommen, mini Vorstellungsrunde (10 Minuten)
- Name Person, Ort und Name der Werkstatt, erwartungen an den Call
- Was erwartet die Runde in diesem Call?
- Einführung in FabAccess (Was geht, was geht nicht?)
- Wie wird FabAccess aufgesetzt?
- Austausch über die groben Bedarfe der teilnehmenden Werkstätten (anhand der ausgefüllten Listen)
- Klärung offener Fragen, die während der Arbeit mit den Liste oder vorher aufgekommen sind
- Ausblick auf die Projektlaufzeit:
- Über die Winterpause: testweises Aufsetzen von FabAcces, dazu erhalten die 11 ausgewählten OW Funksteckdosen, die anderen können sich welche bestellen
- Ende Januar individuelle Calls, Ziel: Klärung aufgekommener Unklarheit bzg. des Aufsetzens von FabAccess, Bedarfe an Softwareschnittstellen und Hardware sowie nächste Schritte in der lokalen Umsetzung
- Danach: selbstständige Umsetzung, Fragen im Matrix und jederzeit, ggf. und bei Bedarf besucht das FabAccess-Team die Werkstätten.
- Bitte: Learnings und offene Fragen hier dokumentieren! https://cloud.offene-werkstaetten.org/s/GwRDK6mq3giZXCC (PW: fabaccess-doku)
Notizen Call mit Joseph, 27.11.2023 nm,bv
- Auswahl der Werkstätten
- Fabmanager kompatibel machen?
- Nur ausleihen / nutzen, wenn über Fabmanager registriert? Theoretisch machbar
- Fabmanager kompatibel machen?
- Zeitplan
- Auftaktcall
- Weitere Termine
- Hardwareanschaffungen
- https://www.berrybase.de/nous-a1t-smarte-steckdose-tasmota-firmware-wlan
- https://www.reichelt.de/de/de/schaltbare-wlan-steckdose-tasmota-nous-a1t-p347718.html?r=1
- https://www.amazon.de/Tasmota-Steckdose-NOUS-A1T-stromverbrauch/dp/B0054PSI46/ref=sr_1_2?__mk_de_DE=ÅMÅŽÕÑ&crid=L4LOG1HCBVT7&keywords=nous%2Ba1t&qid=1701091791&sprefix=nous%2Ba1%2Caps%2C128&sr=8-2&th=1
- Nächste Schritte
- Formulare rumschicken, als Vorbereitung für den Kickoff
- Maschinenbestand feststellen (welche Maschinen sollen angeschlossen werden, was ist gewünscht?)
- Welche Berechtigungsgruppen sind geplant?
- Allgemeine Wünsche an Fabacces zu z.B. Plugins
- Terminumfrage
-
- bis 14.12., freier Zeitraum, 13 Uhr Start
-
- Bis Januar Testaufbau von Fabaccess
- Ende Januar / Anfang Februar: Offene Sprechstunden, Hardwarewünsche, Pluginwünsche, Probleme besprechen, die aufgekommen sind
- Danach Berechtigungskonzept und Material / Hardwareanforderungen planen
- Umsetzen ggf. auch durch Besuch von FabAcess
- Formulare rumschicken, als Vorbereitung für den Kickoff
Notizen Call mit Joseph am 20.9.2023
Der DSEE-Antrag ist durch. Im Kern geht es um das Aufsetzen von FabAccess in 10 Offenen Werkstätten. Dafür erhalten die Werkstätten Hardware im Wert von 1k sowie 1k für die Bezahlung einer Person vor Ort und Unterstützung durch das FabAccess-Team bei der Umsetzung.
Fragen
- Welche Kapazitäten hat FabAccess für die Umsetzung des Projektes?
- Was kann FabAccess für 30k Entwicklungsbudget + 10k Materialbudget leisten?
- Plugins für neue Geräte schreiben?
- Einführungsworkshop für die Offenen Werkstätten: technisches Aufsetzen, Berechtigungen (Konzept und Implementierung), Sicherheitsaspekte empfehlen (auch beim WLAN)
- Verleihoption aufsetzen (Bedarfe abfragen)?
- Welche Informationen benötigen wir von den zehn Offenen Werkstätten bereits bei der Auswahl?
- Was sollten die 10 Werkstätten leisten, damit dort FabAccess umgesetzt werden kann?
- es braucht ein funktionierendes Konzept, wie Berechtigungen vergeben werden. FabAccess kann bei der Entwicklung des Konzeptes unterstützen: Wie teilen wir unsere Maschinen in Berechtigungen ein? (3D-Drucker ist nicht gleich 3D-Drucker)
- es braucht eine Dokumentation des Berechtigungskonzepts
- Umsetzen: technische Einrichtung (dabei kann FabAccess bei Bedarf helfen), Maschinen eintragen, Berechtigungen vergeben, Labels ankleben
- Einführen: den Nutzenden erklären, wie das System funktioniert
- Administration: hat die Verantwortung für das System
Projektrahmen
Projektstart
01.11.2023 - 31.12.2024
Projektdauer
1 Jahr
Projektinhalt
1000€ pro Werkstatt an Hardware
1000€ pro Werkstatt zum Entwickeln
30000€ zum Entwickeln
Umsetzung
Föderation
Wäre mit 10 Werkstätten wäre ein Prototyper Aufbau realistisch
Weitere Föderationsplanung für lokale Bereiche, wie Kleingärtenvereine.
Welche Werkstätten?
- es braucht einen aktiven offenen Community-Teil (mehr als 50 Personen)
- gute WLAN-Anbind (mehr APs)
- technisches Verständnis: Netzwerkinfrastruktur, Verständnis zum Verwalten von Servern (z.B. DOCKER kennen)
- Umesetzung / einführung so 3 - 6 tage arbeit
- Akteure im Umfeld integrieren wollen (wen gibt es? Partner sollten genannt werden)
Ablauf
- Ausschreibung und Auswahl von 10 OW (gerne auch mehr als 10, dann aber keine Geldmittel, die müssten mitgebracht werden)
- Kickoff-Workshop und Einführung in Fabacces
- Abfrage von Objekten, die Berechtigungen erhalten sollen (Umfrage)
- Berechtigungskonzept entwickeln (Hausaufgabe für OW, Rückfragen können gestellt werden)
- Fehlende Plugins-Entwickeln (wenn Daten vorliegen)
- Hardware verteilen, erste Maschinen aufsetzen
Ideen
- FAQ durch Formular anlegen: Alle sollen Probleme und ihre Lösungen schon im Prozess teilen
- Berechtigungskonzeopte für andere als Vorlage veröffentlichen
- Kostenaufstellung für eine Werkstatt anlegen (was kostet das Aufsetzen von FabAccess an Hardware?)
Nächste Schritte / To-Dos
- Wie kommt das Geld zu Fabacces (Vergabe)?
- Wie kommen wir an die Hardware: Sammelbestellung?
- Welche Kapazitäten hat wer vom VOW-Team?
- Auftakt-Call VOW und Fabaccess organisieren
- Vorher: Ausschreibungskonzept entwickeln und rumschicken
- Ausschreibung zur JHV ankündigen
Leistungsbeschreibungen
Im Rahmen des Projektes “FabAccess” ist geplant die gleichnamige Software- und Hardware-Lösung in zehn Offenen Werkstätten (FabLabs, Maker- und Hackerspaces) einzurichten. Die Technologie steht als Open Source zur Verfügung. Im Rahmen des Projektes sollen die zehn genannten Orte dabei unterstützt werden, das System bei sich zu installieren. Die Orte werden im Rahmen einer Ausschreibung ausgewählt. Für die Umsetzung werden folgende Dienstleistungen benötigt:
Beratung und Betreuung (Paket A)
Beratung
Vorgesehen ist mindestens ein Workshop, bei dem die ausgewählten Werkstätten Grundlagen vermittelt bekommen, wie sie FabAccess technisch aufsetzen und verwenden können. Dabei sollen folgende Dinge vermittelt werden:
- Vermittlung von Grundlagen:
Wie ist FabAcces aufgebaut? - Bedarfsplanung:
Was muss bei der technischen Implementierung beachtet werden? - Berechtigungsplanung:
Wer soll unter welchen Bedingungen für was Zugang erhalten? - Best Practice
- FabAccess in der Praxis: Aufsetzten eines Beispielservers
Betreuung
Nach der Vermittliung von Grundlagen sollen die zehn Offenen Werkstätten dabei unterstützt werden, FabAccess lokal aufzusetzen aufzusetzten. Folgende Leistungen sind dafür zu erbringen:
- Unterstützung bei der Maschinenplanung
- Unterstützung bei der Erfassung der benötigten Berechtigungen
- Unterstützung bei dem Aufsetzten eines Servers
- Technische Anpassungen an gewünschte Strukturen
Softwareentwicklung (Paket B)
Weiterentwicklung des bestehenden Systems
Für die zehn Offenen Werkstätten werden ggf. neue Plugins benötigt, um bisher nicht unterstützte Aktoren und Sensoren ansteuern zu können. Weiterhin soll der bestehende FabAccess-Stacks zur Verbesserung der Verwendbarkeit und Bedienung weiterentwickelt werden, dabei liegt der Fokus auf folgenden Bereichen:
- Implementierung einer Desktop-Version
- Implementierung einer Web Version
- Verbesserung der Verwaltung von Resourcen (Bilder, Parameter)
- Stabilitätsverbesserung für den Client auf mobilen Platformen
- Entwicklung einer grundlegenden Föderationstruktur zum Teilen von Berechtigungen
- Integration von bestehender Hardware als FabAccess-Komponenten durch die Entwicklung von Software-Plugins
Entwicklung eines offenen Ausleihsystems
Neben der Weiterentwicklung ist die Entwicklung einer Ausleihstation für Resourcen (Werkzeuge, Maschinen etc.) geplant, die mit FabAcces kompatibel ist und auch von anderen Akteuren, als Werkstätten genutzt werden können soll. Folgende Dinge müssen dafür entwickelt werden:
- Konzeptionelle Planung eines offenen Ausleihsystems
- Anpassung des Clients um eine Ausleih-Funktion
- Entwicklung einer Konfigurations-Funktion, um die Ausleihumgebung an den institutionellen Rahmen anzupassen (optional)
- Integration einer NFC-Funktion für die Zuordnung von ausleihbaren Gegenständen
- Integration einer QR-Code-Funktion für die Zuordnung von ausleihbaren Gegenständen
Dokumentation der Entwicklungen
Alle Entwicklungen werden als Open Source dokumentiert und veröffentlicht. Dabei ist Folgendes zu erbringen:
- Zusammenfassung von Learnings
- Veröffentlichung von Berechtigungskonzepten
- Bereitstellung von Best Practices
- Bereitstellung von zwei Beispielkonfigurationen (einfach und komplex)
- Veröffentlichungen der Datenstrukturen, um interoperable System zu ermöglichen
- QR-Code
- DESFire
- Resourcenidentfier
Hardwarebeschaffung
Optionen zur Hardware
- Was muss genau beschafft werden? Auch eigenhändig entwickelte Hardware nennen
20.08.2024 // Strategiecall am 20.08.2024
Anwesend:Falko(35services), Anjuschm (VOW),Bodo(Werkbox3), Ferdi (ZU Erlangen), Jonathan (ZAM Erlangen), Kevin (ZAM), Mario (Stadtfabrikanten), Michael (Makerspace Güterloh), Roy (MS Leipzig), Jonathan (ZU Illmenau), Joris (Makerspace Bocholt), Mario (Stadtfabrikanen Chemnitz), Michael (Gütersloh), Oleg (OWBA), Roy (MS Leipzig), André (Sternenlabor), Ferdi, Peter (Sternenlabor), Tasso (sfm)
Angeda
-
Kurze Vorstellungsrunde: Name, Werkstatt, FabAccess eingerichtet ja/nein
-
Zam Erlangen: test fabaccess installation, ansonsten eigene
-
35services: test installaton
-
ZU Illmenau: keine fabaccess am laufen
-
Makerspace Bocholt: seit 3 Jahren dabei
-
Stadtfabrikanen Chemnitz: nichts produktiv
-
Gütersloh: provisorisch vor Weihnachten am Laufen
-
Leipzig: nicht produktiv
-
Werkbox3: Server laeuft, Noch nicht aktiv im Einsatz
-
-
Darstellung des aktuellen Standes
-
Max (VOW) berichtet
-
Firma wird aufgelöst aufgrund von Krankheit
-
Daher stehen Mittel zur Verfügung
-
Ziel: Anzahl der Entwickler diversifizieren und wichtige Entwicklungsbedarfe mit vorhandenen Kompetenzen angehen. FabAccess darf nicht sterben, sondern soll umso stärker und resilienter werden.
-
Lösung: Aufbau eines kleinen Teams, das auftragsbasiert arbeitet. Dafür braucht es:
-
Ein, zwei Personen, die die Kommunikation übernehmen und dokumentieren. Sie organisieren auch regelmäßige Calls (z.B. einmal im Monat) und machen bestehendes Wissen zugänglich
Drei Akteure:
- Person/Gruppe, die Entwicklung macht
- Person/Gruppe, die Dokumentation macht
- Hardware: FabReader. Wer kann sich vorstellen, das für die
Wer kann wo beitrag zu leisten? -
Softwareentwickler: sie bauen für alle wichtige Software
OlegJonathan (ZAM Erlangen)
Ich wäre bei Software, insbesondere die Prioritäten vom ZAM:
- 1. Login via OIDC / SAML
- 2. Rollen aus LDAP (damit es via NFC und SSO geht, alternativ OIDC/SAML)
- 3. Web-Client (und -Server) - gerne macht das auch haptsächlich jemand anders :D - mehr feedback notwendig:
- separates ui in einer web-platform?
- xamarin / maui irgendwie ins web portieren?
- gtk web renderer?André vom Sternenlabor, kann alles Programmieren, hat aber sehr wenig Zeit. Z.B. Entwicklung einer Web-App oder hybrider App unterstützen
Julian: Es gibt im ZAM neben Jonathan noch eine weitere Person, die hier unterstützen kann. Max hat schon mit der Person gesprochen. Im ZAM wurde schon Hardware entwickelt.
Und ich kann vermutlich noch Unterstützung aus der UX Ecke organisieren, dass eine künftiger Web-Client auch Nutzungsfreundlich seien wird. -
Dokumentation
Falko: Joris nutzt es und da läuft es produktiv. Diese Erfahrungen nutzen und das hier auch einfließen lassen, beim Thema Doku.Mario Voigt: Betreut Websiten und Dokumentationen: Kann sich vorstellen, Homepage auf den aktuellen Stand bringen, FabAccess auf verschiedenen Betriebssystemen zum Laufen bringen, Installationshinweise, auf Systemeigenheiten eingehen. Würde auch vor Ort in OWs bei Installationen helfen. Accounts einstampfen (Github...), aufräumen, Durchblick reinbringen.
Bodo werkbox3: Zusammen mit Mario Interviews in den Werkstätten: Was gibt's schon? Die Lösungen zusammentragen + DokuRoy MS Leipzig: Kann hier dabei sein aus Anwendersicht
-
Hardwareentwickler: sie bauen die Fabreader etc
André vom Sternenlabor, wenn die Doku passt und es nicht zu viel Aufwand bedeutet. Hat sehr wenig Zeit
Joris: Hat FabReader entwickelt, kann hier weiter unterstützen.
-
-
FabAccess ist Open Source, wir haben Zugriff auf alles, bzw. das wird Max mit Joseph demnächst genauer besprechen. Falko: Zugang zu Apple Store + PlayStore
-
-
Liste von Entwicklungsbedarfen
Was ist wichtig und wie möchten wir priorisieren?
-
Browserbasierte App
scheint für viele ein Mehrwert zu sein -
Single Sign-on
scheint auch wichtig zu sein -
Türen leichter öffnen (hoffentlich niemand will eine Tür mitnehmen), nicht ausleihen
da sollten wir auch ran
Tasso: Joseph hat in Hamburg im Abschluss von FabCity ein Tool für Schubladen gezeigt. Das kann evtl. auch für Türen verwendet bzw. angepasst werden.
Dazu gibt's einige Diskussionsbeiträge (siehe Aufzeichnung, ca. Minute 50) -
LDAP-Schnittstelle vereinfachen
Bedarf ist für Max unklar. Hier vielleicht nochmal Austausch nötig: Was sind hier genau die Herausforderungen?
Tasso: Zwischen SingleSignOn und LDAP Schnittstelle (keycloak?) nutzen.
Warum brauchen wir LDAP? --> FabAccess wird Modular konzeptioniert und nicht an eine Werkstatt angepasst. Es ist wichtig, das beizubehalten. -
Was fehlt?
-
Support für fehlende Objekte
PlugIns
-
Passwörter außerhalb des Klartext
Für Erhöhung der Sicherheit —> Klartext ist nur eine Möglichkeit beim Import - in FabAccess und beim Export wird Argon2-hash verwendet, das dem Stand der Technik entspricht. -
Ist eine Ausleihfunktion ein Bedarf?
-
Joris primary/secondary Modus. Kann das Script zur Verfügung stellen, ist aber nicht Prio 1.
-
Wolfram: Community Plattform/Dokumentation: Geht das? Haben wir da die Berechtigungen?
Max: Ja das wird und muss gehen. Joseph hat da sehr viel Offenheit signalisiert.
Tasso: Alles ist auf gitlab OpenSource, Personen können dort beigefügt werden. Website hängt auch in gitlab drin.
Zudem gibt's ReadTheDocs als Anwender-Doku. Da weiß er nicht, wie der Stand ist. Auch das müsste in git sein, bzw. kommt aus git raus oder kann in ReadTheDocs von Menschen mit Accounts bearbeitet werden. Daran darf‘s nicht scheitern! -
Wolfram: Anzeigenamen. Neben der internen ID eine weitere? Tasso: Matrikelnummer der Studierenden hat funktioniert. Tasso schaut, wie er hier unterstützne kann.
-
-
-
Was hat Priorität? Wer kann sich was davon vorstellen zu übernehmen?
-
Julian: Doku sollte unbedingt aufgeräumt werden, damit neue Entwickler*innen gut einsteigen können. Es gibt gerade 100 Repros...
Falko: Git zum Laufen bringen. Vielleicht können wir uns darauf einigen. Wie Tasso meinte: Viel kaputt gehen kann da nicht. Da können wir dann Erfahrungen sammeln, wie das als Community-Projekt am Besten läuft - und es gibt ja Beispiele, von denen man lernen kann. -
Fazit von Max: Browser-basierte App scheint wichtig zu sein für viele. Single Sign On in LDAP und das mit den Türen.
-
Tasso: ios und android ist eigenes Arbeitspaket das zu übergeben und fortzuführen. Falko könnte sich das vielleicht vorstellen. Kommt drauf an, wie das aufgebaut ist. Max nimmt das mit.
-
Max wird mit den Personen, die sich für Softwareentwicklung gemeldet haben und auch mit denen, die sich für die Doku gemeldet haben.
-
-
Ausblick: Angebote einholen, nächster Call mit Joseph mit entstandenem Team und Übergabe. Die Gelder müssen bis November ausgegeben sein. Das DSEE-Projekt läuft bis Ende des Jahres.
-
Max kann bei Fundraising unterstützen.
-
Max: Etwa in einem Monat finden wir uns nochmal zusammen.
-
10.07.2024 // Laufende Dokumentation im Projekt FabAccess
Hier können alle Learnings und offenen Fragen festgehalten werden. Jede Frage ist wichtig und kann notiert werden. Denkt an ein FAQ, was im Nachhinein entstehen soll.
FAQ - Welche Fragen müssen beantwortet werden, um FabAccess lokal aufzusetzen?
Hier könnt ihr alle Fragen aufschreiben, die bei euch aufkommen:
- Für was ist FabAccess gedacht?
- Antwort: ..
- Für was ist FabAccess nicht gedacht?
- Antwort: ..
- Was kostet das Aufsetzen von FabAccess ca.?
- Antwort: ..
- ...
Interessante Links, die ihr mit anderen Teilen wollt
- Die FabAccess-Website: https://www.fab-access.info/
Andere Notizen, die ihr für wichtig haltet
Hier könnt ihr alles andere niederschreiben, was ihr für andere wichtig findet oder gelernt habt. Wenn ihr mögt, dann schreibt einen eindeutigen Namen hinter eure Notiz, damit wir im Zweifel nachfragen können, falls etwas unklar ist.
- ...
- ...
➡️➡️➡️➡️ Dokumentation kopiert: https://gitlab.com/fabinfra/fabaccess/docs/-/merge_requests/8 https://gitlab.com/fabinfra/fabaccess/actors/tasmota/-/merge_requests/2 ⬅️⬅️⬅️⬅️
FabAccess Tasmota Actor konfigurieren
Actor verfügbar machen
git clone https://gitlab.com/fabinfra/fabaccess/actors/tasmota.git adapters/tasmota
chmod +x adapters/tasmota/main.py
Actor in bffh.dhall konfigurieren
actors =
{
tasmota_F0A4FB =
{
module = "Process",
params =
{
cmd = "/usr/local/lib/bffh/adapters/tasmota/main.py",
args = "--host mqtt --tasmota F0A4FB"
}
}
},
Nous A1T / Tasmota konfigurieren
https://tasmota.github.io/docs/Commands/
PowerOnState auf 0 setzen, um eine Art Wiederanlaufschutz zu haben
PowerOnState Control power state when the device is powered up. More information 0 / OFF = keep power(s) OFF after power up 1 / ON = turn power(s) ON after power up 2 / TOGGLE = toggle power(s) from last saved state 3 = switch power(s) to their last saved state (default) 4 = turn power(s) ON and disable further power control 5 = after a PulseTime period turn power(s) ON (acts as inverted PulseTime mode)
Ggf. FriendlyName auf etwas lesbares ändern
!! Fuktioniert das noch mit dem Tasmota Actor? !!
FriendlyName 1 = Reset friendly name to firmware default = set friendly name (32 char limit)
Tasmota aktualiseren
Upgrade 1 = download firmware from OtaUrl and restart 2 = (ESP32 only) download safeboot firmware based on OtaUrl and restart into safeboot = download firmware from OtaUrl if is higher than device version
Werbserver ausschalten und konfiguration nur über MQTT machen
!! Ist dann noch ein separates Netzwerk erforderlich? !!
Webserver 0 = stop web server 1 = start web server in user mode 2 = start web server in admin mode
Farbschema anpassen
https://tasmota.github.io/docs/Commands/#webcolor
WebColor {"WebColor":["#727272","#fafafa","#fafafa","#3f484e","#fafafa","#25d0aa","#3f484e","#ca291d","#1dca29","#000000","#25d0aa","#1a9378","#ca291d","#8a1b14","#25d0aa","#1a9378","#ffffff","#25d0aa","#3b474d"]}
WiFi einrichten
SSId = 1..2 = set AP Wi-Fi SSID and restart 1 = reset AP Wi-Fi SSID to firmware default (STA_SSID1 or STA_SSID2) and restart SSID are limited to 32 characters. Do not use special characters or white spaces in the SSID
Password = 1..2 = set AP Wi-Fi password and restart 1 = reset AP Wi-Fi password to firmware default (STA_PASS1 or STA_PASS2) and restart Passwords are limited to 64 characters. Do not use special characters or white spaces in the password. Note that Password and Password1 are equivalent commands.
MQTT einrichten
MqttHost 0 = clear MQTT host field and allow mDNS to find MQTT host 1 = reset MQTT host to firmware default (MQTT_HOST) and restart = set MQTT host and restart (do NOT use .local)
MqttUser 0 = clear MQTT user name 1 = reset MQTT user name to firmware default (MQTT_USER) and restart = set MQTT user name and restart
MqttPassword 0 = clear MQTT password 1 = reset MQTT password to firmware default (MQTT_PASS) and restart = set MQTT password and restart (min 5 chars)
MqttPort 1 = reset MQTT port to firmware default (MQTT_PORT) and restart = set MQTT port between 2 and 32766 and restart
➡️➡️➡️➡️ Ende von: https://gitlab.com/fabinfra/fabaccess/docs/-/merge_requests/8 und https://gitlab.com/fabinfra/fabaccess/actors/tasmota/-/merge_requests/2 ⬅️⬅️⬅️⬅️
MQTT mit TLS
mosquitto mit traefik einrichten
ggf. noch mit crowdsec absichern
https://goneuland.de/traefik-v2-3-reverse-proxy-mit-crowdsec-im-stack-einrichten/
ESP8266 unterstützen kein TLS mit Tasmota und muss selbst gebaut werden
https://tasmota.github.io/docs/TLS/#compiling-tls-for-esp8266 !! Durch FabInfra bereitstellen, damit neue Nous per OTA geflashes werden können? !!
platform.ini
; uncomment the following to enable TLS with 4096 RSA certificates
-DUSE_4K_RSA
platformio_tasmota_env.ini
lib_extra_dirs =
${common.lib_extra_dirs}
lib/lib_ssl
tasmota/user_config_override.h
#ifndef _USER_CONFIG_OVERRIDE_H_
#define _USER_CONFIG_OVERRIDE_H_
#ifndef USE_MQTT_TLS
#define USE_MQTT_TLS // Use TLS for MQTT connection (+34.5k code, +7.0k mem and +4.8k additional during connection handshake)
#define MQTT_TLS_ENABLED true // [SetOption103] Enable TLS mode (requires TLS version)
#define USE_MQTT_TLS_CA_CERT // Force full CA validation instead of fingerprints, slower, but simpler to use. (+2.2k code, +1.9k mem during connection handshake)
// This includes the LetsEncrypt CA in tasmota_ca.ino for verifying server certificates
// #define USE_MQTT_TLS_FORCE_EC_CIPHER // Force Elliptic Curve cipher (higher security) required by some servers (automatically enabled with USE_MQTT_AWS_IOT) (+11.4k code, +0.4k mem)
#endif
#endif // _USER_CONFIG_OVERRIDE_H_
Backup / Restore einrichten
Hardware empfehlung
Automatisches Deployment via Ansible?
Hilfsmittel
Links
https://gitlab.com/fabinfra/fabaccess/dockercomposehttps://fab-access.readthedocs.io/en/v0.3/installation/server_docker.html
MQTT Explorer
27.12.2023 // FabAccess FAQ
FabAccess Tasmota Actor konfigurieren
Actor verfügbar machen
git clone https://gitlab.com/fabinfra/fabaccess/actors/tasmota.git adapters/tasmota
chmod +x adapters/tasmota/main.py
Actor in bffh.dhall konfigurieren
actors =
{
tasmota_F0A4FB =
{
module = "Process",
params =
{
cmd = "/usr/local/lib/bffh/adapters/tasmota/main.py",
args = "--host mqtt --tasmota F0A4FB"
}
}
},
Noua A1T / Tasmota konfigurieren
https://tasmota.github.io/docs/Commands/
PowerOnState auf 0 setzen, um eine Art Wiederanlaufschutz zu haben
PowerOnState Control power state when the device is powered up. More information
0 / OFF = keep power(s) OFF after power up
1 / ON = turn power(s) ON after power up
2 / TOGGLE = toggle power(s) from last saved state
3 = switch power(s) to their last saved state (default)
4 = turn power(s) ON and disable further power control
5 = after a PulseTime period turn power(s) ON (acts as inverted PulseTime mode)
Ggf. FriendlyName auf etwas lesbares ändern
!! Fuktioniert das noch mit dem Tasmota Actor? !!
FriendlyName<x> 1 = Reset friendly name to firmware default
<value> = set friendly name (32 char limit)
Tasmota aktualiseren
Upgrade 1 = download firmware from OtaUrl and restart
2 = (ESP32 only) download safeboot firmware based on OtaUrl and restart into safeboot
<value> = download firmware from OtaUrl if <value> is higher than device version
Werbserver ausschalten und konfiguration nur über MQTT machen
!! Ist dann noch ein separates Netzwerk erforderlich? !!
Webserver 0 = stop web server
1 = start web server in user mode
2 = start web server in admin mode
WiFi einrichten
SSId<x> <x> = 1…2
<value> = set AP<x> Wi-Fi SSID and restart
1 = reset AP<x> Wi-Fi SSID to firmware default (STA_SSID1 or STA_SSID2) and restart
SSID are limited to 32 characters. Do not use special characters or white spaces in the SSID
Password<x> <x> = 1…2
<value> = set AP<x> Wi-Fi password and restart
1 = reset AP<x> Wi-Fi password to firmware default (STA_PASS1 or STA_PASS2) and restart
Passwords are limited to 64 characters. Do not use special characters or white spaces in the password.
Note that Password and Password1 are equivalent commands.
MQTT einrichten
MqttHost 0 = clear MQTT host field and allow mDNS to find MQTT host
1 = reset MQTT host to firmware default (MQTT_HOST) and restart
<value> = set MQTT host and restart (do NOT use .local)
MqttUser 0 = clear MQTT user name
1 = reset MQTT user name to firmware default (MQTT_USER) and restart
<value> = set MQTT user name and restart
MqttPassword 0 = clear MQTT password
1 = reset MQTT password to firmware default (MQTT_PASS) and restart
<value> = set MQTT password and restart (min 5 chars)
MqttPort 1 = reset MQTT port to firmware default (MQTT_PORT) and restart
<value> = set MQTT port between 2 and 32766 and restart
MQTT mit TLS
mosquitto mit traefik einrichten
ggf. noch mit crowdsec absichern
https://goneuland.de/traefik-v2-3-reverse-proxy-mit-crowdsec-im-stack-einrichten/
ESP8266 unterstützen kein TLS mit Tasmota und muss selbst gebaut werden
https://tasmota.github.io/docs/TLS/#compiling-tls-for-esp8266
!! Durch FabInfra bereitstellen, damit neue Nous per OTA geflashes werden können? !!
platform.ini
; uncomment the following to enable TLS with 4096 RSA certificates
-DUSE_4K_RSA
platformio_tasmota_env.ini
lib_extra_dirs =
${common.lib_extra_dirs}
lib/lib_ssl
tasmota/user_config_override.h
#ifndef _USER_CONFIG_OVERRIDE_H_
#define _USER_CONFIG_OVERRIDE_H_
#ifndef USE_MQTT_TLS
#define USE_MQTT_TLS // Use TLS for MQTT connection (+34.5k code, +7.0k mem and +4.8k additional during connection handshake)
#define MQTT_TLS_ENABLED true // [SetOption103] Enable TLS mode (requires TLS version)
#define USE_MQTT_TLS_CA_CERT // Force full CA validation instead of fingerprints, slower, but simpler to use. (+2.2k code, +1.9k mem during connection handshake)
// This includes the LetsEncrypt CA in tasmota_ca.ino for verifying server certificates
// #define USE_MQTT_TLS_FORCE_EC_CIPHER // Force Elliptic Curve cipher (higher security) required by some servers (automatically enabled with USE_MQTT_AWS_IOT) (+11.4k code, +0.4k mem)
#endif
#endif // _USER_CONFIG_OVERRIDE_H_
Backup / Restore einrichten
Hardware empfehlung
Automatisches Deployment via Ansible?
Hilfsmittel
Links
https://gitlab.com/fabinfra/fabaccess/dockercompose
https://fab-access.readthedocs.io/en/v0.3/installation/server_docker.html
MQTT Explorer
16.03.2023 // Öffentliche Aktivitäten von FabAccess - Stand 16.03.2023
- “Joris-Release” - für Joris Bijkerk - https://repaircafe-bocholt.de/
- Meet & Chat VOW
- Talk auf der Gulasch Programmiernacht (GPN) - https://www.offene-werkstaetten.org/post/api-release-v0-3 - (21.05.2022)
- Vorstellung bei Fab:UNIverse 2022 - https://pretalx.innovisionlab.de/fab-universe-2022/talk/AH78P7/ - 26.08.2022
- CommunityCall “for beginners” - https://pad.gwdg.de/mByN6YTYRo6Zs-qKQtuRAA?view# (30.11.2022)
- CommunityCall “deep dive” (14.12.2022)
- Vorstellung beim Jahrestreffen des VOW (Eigenbaukombinat) - https://www.offene-werkstaetten.org/post/eigenbaulaune (27.08.2022)
- LightningTalk auf der FOSDEM - https://fosdem.org/2023/schedule/event/fabaccess/ (05.02.2023)
- Showcase und Talk bei TheFutureOfMaking - https://www.interfacerproject.eu/news/tfom23-conference-expo/ (03.03.2023)
- Ideenentwicklung zur Knowledge-Toolchain beim OpenToolchainHackathon - https://www.opentoolchain.org/hackathon/ (06.03.2023)
- Workshop beim Statustreffen der StartupLab@FH - https://www.eventbrite.de/e/statustreffen-startuplabsfh-tickets-511578082817 (15.03.2023)
Installationen
Aktiv
- Labor für Fertigungsverfahren der Mechatronik, BHT Berlin
- Repaircafe Bocholt - https://repaircafe-bocholt.de/
Test-Installationen (nícht abschließend)
- c.lab, München (Alpha-Test erfolgt, aktuell Update auf 0.4 geplant) - https://creative-lab-hm.de/
- ZAM Erlangen (Alpha-Test erfolgt, Update auf 0.4 geplant) -
Avisiert
- Machbar Potsdam
- FabCity Hamburg (tbd.)
- Tech-Starter, BHT Berlin - https://projekt.bht-berlin.de/qio2021-2024/techstarter/
- Strascheg Center for Entrepreneurship, MÜnchen - https://www.sce.de/index.html
- Rollwerk Berlin - https://www.offene-werkstaetten.org/werkstatt/rollwerk
04.03.2023 // FabAccess Notizen
Community Call 04.03.2023
- SSO/LDAP wurde angefangen in die API einzubauen, klingt aber noch nach work in
progress - Claims auf Ressource können künftig überschrieben werden durch andere Nutzer, wenn
Ressource in einem bestimmten Zustand (z.B. fertigen 3D-Drucker übernehmen, der nicht
freigegeben wurde) - "Ablaufzeit" über "Script dranhängen an API"
- Verleihzustand vs. Gerätezustand soll dargestellt werden
- Gerätezustand über Initiator z.B. von MQTT in FabAccess übertragen; z.B. Stromverbauch
für x min < y, dann freigeben - Komplexe Abhängigkeiten z.B. in Homeassistant abbilden und Ergebnis-Signale an
FabAccess übertragen - Ablaufende Berechtigung über API möglich, Implementierung in Kern WIP
- OAuth soll implementiert werden, wird aber nicht alle Mechaniken erlauben
- Login mit gescanntem QR Code als Alternative zu Benutzername/Passwort
- Hackwerk Aalen baut eigenen FabReader (Gehäuse), Zusammenbau der existierenden Designs hat nicht geklappt
03.02.2023 // NFC Lib - DESFire
Müssen wir uns mal anschauen, da die das können, was wir wollen
ISO 7816
Die ISO 7816 spezifiziert in mehreren Teilen die Normen für kontaktbehaftete Chipkarten. Für die DESFire Bibliotheke ist der Teil 4 relevant, da dort die Kommunikation mit der Chipkarte definiert wird.
ISO 7816 Parts
ISO 7816 Part 4
APDU Command
(wird an PICC gesendet)
CLA | INS | P1 | P2 | Lc | Data | Le |
---|---|---|---|---|---|---|
1 byte | 1 byte | 1 byte | 1 byte | 1* byte | max. 253* bytes | 0-3 bytes |
siehe Wikipedia |
APDU Response
(kommt als Antwort vom PICC)
Data | SW1-SW2 |
---|---|
max. 253** bytes | 2 bytes |
CLA=Instruction Class
gibt an, ob es sich nachfolgend um standardisierte Befehle oder um proprietäre Befehle handelt. Normalerweise 0x90.
INS=Instruction Code
jeweiliger Befehl der ausgeführt werden soll.
P1/P2 = Instruction parameter for command
spezifische Parameter für den Befehl, z.B. ein Offset in der Datie in der geschrieben werden soll.
Lc = commando Length
nennt die Anzahl der Bytes die in [Data] übergeben werden. Kann 1 Byte (max 255) oder 3 (max 65 535, erstes Byte muss 0 sein) Bytes verwendet werden.
Data = command data
Daten die im Zuge des Befehls übertragen werden sollen / als Antwort vom PICC zurückgegeben werden.
Le = response Lenght
Anzahl der Bytes die als Antwort erwartet werden. Dabei stellt 0x00 ein "Platzhalter" für "eine undefinierte Länge bis zu 255 Bytes" da.
SW1-SW2 = Response Trailer
gibt den Anwort-Status wieder, z.B. (Hex): 90 00 für "Command successfully executed (OK)" 91 00 für "OK" siehe Response codes
"*" / "**" wir verwenden maximal 255 bytes, da ansonsten die Datenübertragung mittels MQTT sehr lang werden könnte.
Beispiel
select Application 0xC0FFEE siehe OTA Beispiel
Parameter | Wert | Kommentar |
---|---|---|
CLA | 0x90 | Standard Befehlssatz |
INS | 0x5A | select Application |
P1/P2 | 0x00/0x00 | keine zusätzliche Parameter |
Lc | 0x03 | 3 Bytes |
Data | 0xEE, 0xFF, 0xC0 | umgekehrte Reihenfolge(?) |
Le | 0x00 | 0x00 = maximal 255 bytes |
Befehl: "\x90\x5A\x00\x00\x03\xEE\xFF\xC0\x00" bzw. 905A000003EEFFC000
Antwort "\x91\x00" bzw 9100
Parameter | Wert | Kommentar |
---|---|---|
Data | - | Befehlt erwartet keine Daten (Le=0) |
SW1/SW2 | 0x91, 0x00 | "OK" |
Befehle
Wrapping von DESFire Native Commands in ISO 7816-4 APDU Frames. ClA(Class) = 0x90 (Bei allen Commands für die Karte) INS(Instrucation) = Command Code des jeweiligen Befehls
Glossar
AID = Application ID
Jede Application auf der DESFire Karte hat einen eigenen Identifier. Ein AID ist 3 Byte groß.
PICC = Proximity Integrated Circuit Card
Die Chipkarte selber
IV = Initialisierungsvektor
Ist ein Begriff aus der Kryptographie und bezeichnet einen Block von Zufallsdaten, der in bestimmten Modi einiger Blockchiffren verwendet wird, wie dem Cipher Block Chaining Mode.
CBC = Cipher Block Chaining
Ist eine Betriebsart, in der Blockchiffren betrieben werden können. Vor dem Verschlüsseln eines Klartextblocks wird dieser zunächst mit dem im vorhergehenden Schritt erzeugten Geheimtextblock per XOR (exklusives Oder) verknüpft.
Datenstruktur Low Level
PCB | [CID] | [NAD] | [INF] | EDC/CRC |
---|---|---|---|---|
0x0A | 0x00 | n.v. | APDU data | specific |
1 byte | 1 byte | 1 byte | max. 253 bytes | 2 bytes |
PCB = Protocol Control Byte (low level, prologue field)
Ist Teil der "Umkapselung" eines APDU Kommandos in der Kommunikation mit dem PICC. Im Normalfall 0x0A (Information Block, no chaining, CID follows, no NAD, BlockNr = 0).
CID = Card ID (low level, prologue field)
Ist Teil der "Umkapselung" eines APDU Kommandos in der Kommunikation mit dem PICC. Ist der Identifizierer des aktuelle PICCs. Ist nur relevant, wenn mehrere PICCs vom Leser gleichzeitig erkannt wurden und nacheinander selektiert wurden. Bei der Kommunikation mit nur einer Karte immer 0x00.
NAD = Node Address
Identifizierer für Absender und Empfänger. Wird nicht verwendet.
EDC / CDC = Error Detection Code / Cyclic Redundancy Check (low level, epilogue field)
Ist Teil der Umkapselung von jeder Nachricht an einem PICC. Wird forlaufend berechnet. Wird häufig von der Hardware selbst berechnet, muss jedoch manuell vom Programm angehangen werden.
INF = Information Field
ist der Teil der Nachricht mit der Infromation mit der Karte ausgetauscht werden kann. Hier können einfache Kommandos oder APDUs verwendet werden
APDU definition
Get Application IDs
APDU Case: 2
Command Code | P1 | P2 | Data |
---|---|---|---|
0x6A |
The “Get AID List” command return the Application Identifiers of all active applications on a PICC.
0x000000 is PICC Application ID, is always returned.
TODO: 4 or 3 Bytes AID size TODO: MSB or LSB first
Select Application by AID
APDU Case: 3
Command Code | P1 | P2 | Data |
---|---|---|---|
0x5A | AID (3 Byte, MSB first) |
The “Select Application” command allows to select one specific application for further access. If this parameter is 0x000000, the PICC level is selected and any further operations are related to this level. If an application with the specified AID is found in the application directory of the PICC, the subsequent commands interact with this application.
AuthenticateISO
Get Challenge APDU Case: 4
Command Code | P1 | P2 | Data |
---|---|---|---|
0x1A | key_id (1 Byte) |
Send Challenge APDU Case: 4
Command Code | P1 | P2 | Data |
---|---|---|---|
0x5A | challenge (MSB first) |
Authentication Process
Beispiel zum Beispiel
Zur Crypto Es wird CBC verwendet.
Zum Entschlüsslen von rndB wird der IV auf 0 gesetzt.
The IV of the session key is reset to zero only ONCE when the key is created after authentication. The IV of the authentication key is reset only ONCE when authentication starts.
Bei allen anderen Verschlüsselungen oder Entschlüsselungen wird der letzte verschlüsselte Block als IV verwendet.
Response Codes
[TODO: Copy from eftlab.com]
Over the Air
Ablauf Kommunikation
Authentication
// Reader
1. Authenticate against lokal BFFH
2. Start Proxy Session
3. Meldet die Präsenz einer Karte
// Client
1. Start Proxy Session
// Lokale BFFH
MifareDESFire mifareDESFire = new MifareDESFire(card);
mifareDESFire.SelectApplication(FabAccessAID);
// FabAccessIdentFileID ist unverschlüsselt
byte[] filedata = mifareDESFire.ReadData(FabAccessIdentFileID, 0x00000000, 0x00000000);
System.Text.ASCIIEncoding enc = new System.Text.ASCIIEncoding();
string userdomain = enc.GetString(filedata);
Console.WriteLine(userdomain);
// Domain BFFH
// Der Eigentümer der Karte
mifareDESFire.SelectApplication(FabAccessAID);
mifareDESFire.Authenticate(0x01, APP_Key_1);
// jetzt wissen wir, das die Karte Authentisch ist
byte[] filedata = mifareDESFire.ReadData(FabAccessIdentFileID, 0x00000000, 0x00000000);
System.Text.ASCIIEncoding enc = new System.Text.ASCIIEncoding();
string userdomain = enc.GetString(filedata);
// jetzt wissen wir, dass die Domain auch wirklich auf die Karte ist
// jetzt müßte man noch einmal die UID der Karte abfragen, um sicher zu stellen, dass der User auch der ist, für den er sich ursprünglich ausgegeben hat.
connected_successfully = true;
card.Disconnect();
Troubleshooting
Error 0x910B
Reinstall NFC Driver on Windows
Quellen
NXP / Mifare
Allgemein
Mifare Application Directory Missing Native Commands
MIFARE DESFire spezifisch
Produktübersicht
EV1 Factsheet EV2 Factsheet EV3 Factsheet
Datasheets
EV1 Datasheet EV2 Datasheet EV3 Datasheet Light Datasheet
Features
Over the Air EV3 Features EV3 Quick Start
andere Links
Generic Access Control Model System Level Security PHILLIPS Presentation PHILLIPS DESFireSAM Authentification Spec ISO/IEC 14443 Type 4 Tag ISO/IEC 14443 Communication Error Code - 0x6A81
ISO
externe DESFire Spezifikationen oder Dokumentationen
DESFire OTA - Proof of Concept Ridrix DESFire Commands MIFARE DESFire Short Spec DESFire KeySettings Response Codes DESFire Authentification DESFire Command Set AES Authentication PHILLIPS DESFire Specification
ISO Specifications
andere NFC Bibliotheken (mit DESFire)
JavaCardOS Easypay Android Java App RFID Door Lock RFDoorLock DESFire Server libfreefare DesFire for Python libopenkey mfrc522 LibLogicalAccess
Müssen wir uns mal anschauen, da die das können, was wir wollen
andere Links
DESFire Auth 2K3DES Authentication Question Kommunikationsbeispiele DESFire CRC Question
unsere Mitschnitte der Kommunkation verschiendener Bibliotheken
07.12.2022 // Chat & Notizen FabAccess-CommunityCall
Notizen
Agenda:
- Intro
- Check In
- Technisches
- FabAccess: Wie kam es dazu?
- Was ist FabAccess? + Demo
- Fragen
- Konkrete nächste Schritte
-Check Out
Wie es kam dass es kam so dass es ist wie es ist:
2018: VOW & Fab:UNIverse (noch) einzeln unterwegs.
2019: https://pad.gwdg.de/DsyvzN4TQyyB5M94ZCBihQ#
2020: https://media.ccc.de/v/rc3-326175-fabaccess
2021: https://prototypefund.de/project/fabaccess/
2022: https://wiki.fabcity.hamburg/software-department/fab-city-os
Test-Server:
test.fab-access.org
Login:
Admin1
Admin2
ManagerA1
ManagerA2
ManagerB1
ManagerB2
ManagerC1
ManagerC2
ManagerABC1
ManagerABC2
MakerA1
MakerA2
MakerB1
MakerB2
MakerC1
MakerC2
MakerACB1
MakerACB2
MakerACB3
GuestA1
GuestA2
GuestB1
GuestB2
GuestC1
GuestC2
GuestACB1
GuestACB2
MakerQRA
MakerQRB
MakerQRC
Passwort: secret
Fragen:
**Was genau bedeutet ausschalten? **
- Über WLAN ausschalten oder Standby
- Shelly-Schalter
- 2023: Ausschaltesystem für Laser: FabAccess direkt über Schnittstelle ausschalten, damit er runterkühlen kann.
- Im Moment werden die Maschinen über zuleitung oder Zwischenstecker hart vom Strom abgetrennt. Für einige Maschinen muss da eine andere Lösung her.
- eine Anbindung zu einem Bluethooth-Türschloss gibt es auch schon (Joris)
Was für ein Schloss habt ihr dafür für das Türschloss genommen?
Equiva, Dazu gibt es einen Controller auf Basis von KeyBLE
Für Nuuki soll etwas entwickelt werden.
Wo ist der Unteschied zwischen einer Maschine in Benutzung und einerm geblocketen Schließfach?
Wie ist die Interaktion von User und FabAccess?
Jeder Nutzer kann sich die App runterladen, bekommt eigene Zugangsdaten und können sich selber anmelden, bzw. Maschinen anschalten. Auf den Maschinen stehen QR-Codes, die von den Handys gescannt werden können. Es wird noch an einem NFC-Prozess gearbeitet.
Das System ist modular: Es gibt eine App. Zweiter Weg: Es gibt einen Kartenleser (open source hardware), einfach nachzubauen. Die Nutzer*innen bekommen Chip-Karten, die auf den Kartenleser aufgelegt werden, dann geht die Maschine an. Es gibt auch die Variante, dass die Karte nur kurz drangehalten wird, die Maschine angeht, die Karte nochmal drangehalten wird, die Maschine aus geht.
Erfolgt der Zugriff von der App auf den Server lokal via WLAN oder muss der Server öffentlich erreichbar sein? dh. es geht auch nur mit lokalem WLAN?
Antwort: Ja
Gibt’s auch eine Weboberfläche? Bzw ist das geplant?
Antwort: Nein noch nicht. Derzeit gibt es im Kernteam von FabAccess keine Ressourcen dafür. Wenn das wer machen würde, würden wir untersüttzen. Man bräuchte aber auch einen Webserver, weil wir kein API, das selber mapt auf (?)
Was heißt NFC?
Kontaktlose Datenübertragung, z.B. wenn man die EC-Karte zum Bezahlen nur dranhält. Die Karten kommunizieren mit den Lesegeräten ende zu ende verschlüsselt.
**Rückfrage zum Terminal: Das Terminal würde dann auch nutzbar sein Maschinen an- und auzuschalten und nicht nur dazu, Dinge auszuleihen? **
Antwort: Ja genau.
Wie verhindert man, dass es möglich ist, dass der nächste der kommt, Maschinen mit meiner Karte anschalten kann?
Antwort: Ist noch in Arbeit
Wie wollt ihr mit Mehrfachanmeldungen umgehen? Wenn wer die Berechtigung für drei Maschinen hat?
Antwort: Bisher ist es möglich udn auch gewünscht, dass mehr als eine Maschine genutzt werden kann. Die Totmannschaltung ist noch in der Entwicklung: Wenn die Maschine nicht mehr genutzt wird, schaltet sich die Maschine ab.
Wie administriert ihr, bzw. die anderen Labs die schon im Probebetrieb sind heute die User?
Also User Anlegen und Berechtigungen editieren. Entweder über eine Textdatei oder über die Referenz-App auf dem Handy.
Antwort: das kann man mittlerweile direkt über die App mit der Adminrolle
Nachtrag: Wie teuer ist das Aufsetzen eines FabAccess Systems
Server - alternativen:
- alter Linuxrechner - meistens geschenkt
- Raspberry Pi - 70€
- kleiner Server ( z.B. Intel NUC, evtl. mit Proxmox) 200-400€
Schalter - alternativen (pro Maschine)
- Relais-Board mit ESP-01 Modul - ab 3,50€
- Shelly 1 - 12-16€
- Shelly 1PM (mit Strommessung) - 15-20€
- 3-Phasen Schalter - Ralais-Board oder Shelly 1 + 3-Phasenschütz ca. 17€
Client (d.h. Gerät mit der Maschinen freigeschaltet werden)
- App “Fabaccess” - kostenlos
- FabReader Bausatz - ca. 20€
- Computer mit Windows und FabAccess-Client
Chat
[18:01] Anjusch: @jens @markus Könnt ihr uns schon hören?
[18:01] Anjusch: Falls es nicht funktioniert, geht nochmal aus dem Raum raus und wählt euch nochmal ein. Das hilft oft.
[18:01] Markus (Helldogz): leider nicht, bin mir nicht sicher wo das Problem ist
[18:02] Anjusch: Eventuell mit einem anderen Browser probieren?
[18:02] Marcel: hast du es mal mit ausschalten und einschalten versucht 🤣
[18:03] Jens, Konglomerat e.V.: ich habe noch kein Ton…
[18:03] Marcel: vielleicht einen anderen Browser versuchen?
[18:06] Nils (FabLab Karlsruhe): Wäre nett, wenn ihr nicht aufzeichnet.
[18:06] Mulzer, Tasso: Entspannt, gespannt und gut gelaunt. ;)
[18:06] Leopold Zyka (OpenLandLAB): Wir sind gerade Fab Region Südbrgenland geworden
[18:07] Joris: hier in Bocholt alles gut, ebenfalls entspannt, da diese Woche endlich mal was ruhiger
[18:07] Leopold Zyka (OpenLandLAB): Bitte aufzeichnen!
[18:07] Stefan (Hobbyhimmel Stuttg: Es geht gut, bin noch bei der Arbeit und höre gespannt zu!
[18:07] sn0wdiver: Entspannt , und neugierig
[18:07] Marcel: Ich freu mich dass das Thema nun doch etwas Fahrt aufnimmt ;) bin gespannt wie ich helfen kann
[18:08] sn0wdiver: sitze in Wuppertal
[18:08] Sebastian S. (werkbox-VS): Südbaden
[18:08] Nils (FabLab Karlsruhe): Wir planen in Karlsruhe seit längerem ein Access System und finden es klasse, dass ihr jetzt ein offenes System für viele Fablabs entwickelt.
[18:08] Marcel: ouha joris ich glaube dein Laptop hat das falsche mikro, denn es gab viel Hall
[18:09] Leopold Zyka (OpenLandLAB): Schade ich muss in ein anderes Meeting
[18:09] Stefan (Hobbyhimmel Stuttg: Wir der Hobbyhimmel sind gespannt was es neues gibt… denn wir haben Bedarf dafür.
[18:09] Joris: weiß nur nicht wie ich das auf Anhieb ändere. Wähle mich zur Not gleich einfach noch mal ein
[18:12] Michel Heftrich: Acces System eine große Hilfe?
[18:17] Mulzer, Tasso: https://pad.gwdg.de/DsyvzN4TQyyB5M94ZCBihQ#
[18:18] dequbed: https://xkcd.com/927/
[18:18] Mulzer, Tasso: https://media.ccc.de/v/rc3-326175-fabaccess
[18:20] Mulzer, Tasso: https://prototypefund.de/project/fabaccess/
[18:30] Joseph (FabAccess): https://hobbyhimmel.de/so-gehts/einweisungen/
https://www.werkbox-vs.de/faq-haeufig-gestellte-fragen/#hfaq-post-1652
https://fablab-karlsruhe.de/2016/03/21/bohrmaschinen/#
[18:31] Nils (FabLab Karlsruhe): Kannst du vielleicht noch einen kleinen Überblick geben, was aktuell schon gut nutzbar ist bzw. schon in einem Lab genutzt wird.
[18:35] Anjusch: https://www.offene-werkstaetten.org/post/cowiki-yeah
[18:42] Joris: zum Protokollieren der Nutzer haben wir in Bocholt ein Python skript geschrieben.
[18:43] Nils (FabLab Karlsruhe): Die automatische Abschaltfunktion ist eine klasse Idee 👍
[18:45] Joris: … eine Anbindung zu einem Bluethooth-Türschloss haben wir auch schon geschrieben
[18:46] sn0wdiver: Was für ein Schloss habt ihr dafür genommen?
[18:48] Joris: schaue nach
[18:48] Joris: Equiva
[18:49] Joris: Dazu gibt es einen Controller auf Basis von KeyBLE
[18:50] Marcel: wo ist der Unteschied zwischen einer Maschine in Benutzung und einerm geblocketen Schließfach?
[18:50] Joris: https://github.com/oyooyo/keyble
[18:55] Nils (FabLab Karlsruhe): Erfolgt der Zugriff von der App auf den Server lokal via WLAN oder muss der Server öffentlich erreichbar sein?
[18:56] Dirk: Und noch eine Rückfrage: gibt’s auch eine Weboberfläche? Bzw ist das geplant?
[18:57] Nils (FabLab Karlsruhe): dh. es geht auch nur mit lokalem WLAN?
[18:57] dequbed: Nils: Ja
[18:58] Joris: ja, bei uns haben wir Freifunk, und fangen die IP mit der sich die Handys verbinden für den Server ab.
MQTT läuft dann über unser geschlossenem (W)LAN
[19:01] Nils (FabLab Karlsruhe): Gibt es die Möglichkeit ein Terminal aufzusetzen, an dem ich mich z.B. per RFID authentifiziere und dann die maschinen wie in der app sehe? Sprich Display und RFID Reader zentral an einer Stelle, statt einem Reader pro Gerät.
[19:03] dequbed: NFC ist das was genutzt wird wenn man seine EC-Karte auf den Reader draufhällt anstatt einsteckt
[19:03] Nils (FabLab Karlsruhe): Und vorbildlich ist auch, dass ihr nicht nur die UID verwendet. :-)
[19:05] Falk: Wie Administriert ihr, bzw. die anderen Labs die schon im Probebetrieb sind heute die User?
Also User Anlegen und Berechtigungen editieren.
[19:07] Joris: Falk: das kann man mitlerweile direkt über die App mit der Adminrolle
[19:08] Nils (FabLab Karlsruhe): Könnt ihr vielleicht mal kurz die Userverwaltung zeigen, würde mich auch interessieren, was da aktuell schon alles implementiert wurde.
[19:08] markus_EBK: Vielen Dank an euch und bis zum nächsten mal.
[19:08] Anjusch: Schüss Markus
[19:11] dequbed: Also es wird immer (pro-Maschine) konfigurierbar sein.
[19:11] Nils (FabLab Karlsruhe): Das mit der Karte auf dem Reader scheint mir aber sehr riskant, denn wenn die Verbindung zur Karte abbricht, obwohl sie noch da ist und dann die Maschine ausgeht, wäre das sehr unglücklich.
[19:13] Nils (FabLab Karlsruhe): @Stefan: Das sind auch unsere Wünsche :-)
[19:13] Sebastian S. (werkbox-VS): Oder wenn die Karte wegen Vibrationen einfach runterfällt…
[19:13] Herzlich Willkommen zum Webkonferenzraum: FabInfra der BHT!In unseren Videotutorials finden Sie Tipps und Hinweise zur Nutzung von BigBlueButton.Verwenden Sie bitte ein Headset, um Störungen durch Nebengeräusche zu vermeiden.Um dieser Konferenz per Telefon beizutreten, wählen Sie die Telefon-Nummer:+49 30 208470609 und geben 27736 als Konferenz-PIN ein. Für die anonyme Einwahl bitte #31# vorwählen.Hinweis: Anrufer sind ggf. stummgeschaltet. Drücken Sie 0 um zu sprechen bzw. sich stummzuschalten.
[19:13] Um jemanden zur Konferenz einzuladen, schicken Sie ihm diesen Link: https://conference.beuth-hochschule.de/b/mul-h26-gct
[19:14] Marcel: https://www.shelly.cloud/shelly-pro-smart-home-automation-solution/#Pro-3
[19:16] Joris: wir haben das gleich im Sicherungsschrank eingebaut
[19:21] Dirk: Ich hätte noch eine Frage in eine andere Richtung: das letzte mal als ich die Dokumentation angeschaut habe, habe ich kein “für ein einfaches Setup brauchst du genau diese Hardware und diese Software Komponenten” gefunden sondern eher nur “das gibt es alles”. Gibt es da inzwischen eine art Tutorial?
[19:24] Falk: in den Shared Notes habt ihr Zugangsdaten zu einem Testsystem, wie ist denn dafür das jeweilige Passwort?
[19:24] Joseph (FabAccess): secret
[19:25] Sebastian S. (werkbox-VS): Was für ein Budget sollte man ansetzen, wenn man dazu ein Projekt aufsetzen möchte? Also natürlich Abhängig von Anzahl Maschinen/Schließfächern etc. die man steuern möchte…
[19:26] Nils (FabLab Karlsruhe): Gibt es ein FabLab, wo wir uns das mal live vor Ort anschauen können?
[19:27] Joris: Nils: in Makerspace Bocholt
[19:27] Stefan (Hobbyhimmel Stuttg: Muss leider los. Vielen Dank! Bei Fragen bitte melden Stefan@hobbyhimmel.de
[19:28] Nils (FabLab Karlsruhe): Bocholt wäre machbar :-) Würde mich über Kontaktdaten freuen.
[19:28] Dirk: Habt ihr ein kozept um zu verhindern, dass der Shelly einfach “ausgebaut” wird? Also stecker direkt in die Steckdose?
[19:28] Sebastian S. (werkbox-VS): Danke. Könnt ihr das nochmal in die Notizen packen? Dann kann man das mit Zeitversatz auch noch kalkulieren… ;-)
[19:28] dequbed: Dirk: Kleber! :D
[19:29] sn0wdiver: ich komm in Bocholt mal vorbei, von Wuppertal ist es ja nicht so weit
[19:29] Joseph (FabAccess): gitlab.com/fabinfra
[19:29] dequbed: https://gitlab.com/fabinfra/
[19:30] Anjusch: https://matrix.to/#/!pIikowJsyqburBAIac:vow.chat?via=vow.chat&via=matrix.org
[19:31] sn0wdiver: ich bau mir das mal auf und hab dann in 14 Tagen viele Fragen ;)
[19:31] Nils (FabLab Karlsruhe): bei fragen/problemen zum linux client compilieren: bietet sich da der nächste Call an oder per Matrix bei euch melden?
[19:31] Marcel: das zulip chat hat sich damit erledigt?
[19:32] Joseph (FabAccess): ja
[19:32] Joseph (FabAccess): @Marcel schreibe ich auch da nochmal rein
[19:32] Mulzer, Tasso: https://www.offene-werkstaetten.org/post/fabaccess-community-calls
[19:32] Jens2 Konglomerat e.V.: Danke auch !!!
[19:33] sn0wdiver: Danke für eure Engagement
[19:33] Nils (FabLab Karlsruhe): Vielen Dank für den informativen Abend und die viele Arbeit, die ihr euch macht.
[19:33] Mulzer, Tasso: info@fab-access.org
[19:33] Joseph (FabAccess): info@fab-access.org
24.04.2022 / Roadmap
Roadmap
API Version v0.3 - April 2022
Content of API:
- Ausleihen von Maschinen (Use, Check, Block, Disable)
- Übertragen von Maschinen - ???
- Verwalten von Nutzern (Add, Remove) - 15.05.2022
- Ändern von Nutzerrollen - 15.05.2022
- Hinzufügen von FabFire Karten zu Nutzern - ???
AuditLog
TODO:
QR-Code für Maschinen NFC für Maschinen GTK und MacOS UWP im Store
Mehr Infos zu 3. und 4.: Anbinden von externen IDPs Persistenz von Nutzerdaten nach Server neustart BackUp von Nutzerdaten
API Version v0.4 - August 2022
Content of API:
- Komplexe Status
- Live Notes an Ressourcen die nur für ≥Manager sichtbar sind. (Blame)
Hello!
since two of our guys couldn't join the meetings I'll recap the main points from the two meetings last week:
We scheduled tentative weekly 30-minute meetings every Tuesday at 15:50 CEST for further establishing details of the integration of FabAccess in the INTERFACER project, starting out with somewhat longer meetings and getting shorter as required. The main topics that were identified to require further discussion are the requirements that FabAccess poses to the existing IAM software solution, especially special topics like card management, to refine the requirements for the FabAccess milestones in the current roadmap, and conduct research on the design and implementation of the FabAccess token and other integrations with the FabChain.
Regarding the Milestones, an initial draft:
Milestones
Since out reference client tracks our server software closely features generally require code on both sides and aren't itemized separately.
- Release 0.3 — "Spigots of Berlin" by 2022-04-24
- Features implemented
- Audit log
- internal user auth & roles
- NXP DESFire based authentication system
- 5-state machine model
- Actor / Initiator system
- Configuration of some machine metadata
- Basic UI for machine state interactions
- Features implemented
- Release 0.4 — "Digging up Stuttgart" by 2022-08-31
- Features implemented:
- OIDC Service Provider
- User roles sourced from external sources (e.g. LDAP)
- Framework allowing additional machine models to be implemented
- Dynamic UI capable of displaying complex states required by some machine models
- Client support for OIDC auth
- Features implemented:
- Comprehensive documentation of Beta Diflouroborane and Borepin. by 2022-09-30
- Primary Focus Setup and Pre-Production enviroments
- Final (INTERFACER) Release — by 2022-12-31
- Features implemented:
- Templating allowing for custom corporate designs
- Publishing OpenHardware CardSystem
- Python/Lua Scripting API
- Features implemented:
- Comprehensive documentation of Release Diflouroborane and Borepin. by 2022-12-31
- Primary Focus End-Users and Common Production Setups
- Follow-up support, up to 2023-03-31
- incl. assisting INTERFACER testing/integration setups
API information
API schema language is https://capnproto.org/ language reference can be found at https://capnproto.org/language.html
A Python API test script can be found at https://gitlab.com/fabinfra/fabaccess/pyfabapi
In the following a very short explanation of the contents of each schema file:
connection.capnp
Initial starting point for API interactions with an instance of the interface Bootstrap
being send to each client on connection establishment.
authenticationsystem.capnp
SASL-based authentication returning an instance of struct Session
from connection.capnp
on successful authentication, giving access to some or all Subsystems based on user roles.
machinesystem.capnp
Lookup system for machines based on URN or configured names.
permissionsystem.capnp
Administrative access to internal roles.
usersystem.capnp
Lookup & admin access to internal representation of users.
machine.capnp
Machine object methods allowing state updates following the current 5-state model and administrative access for privileged operators.
user.capnp
Access to user information and administrative methods for privileged operator.
space.capnp && general.capnp && role.capnp
Auxiliary types used in other files.
Test env
We have a test environment with a preconfigured server. https://gitlab.com/fabinfra/fabaccess/testenv
All available test users are listed in the README.md file. For a simple start the "Admin1" user is the most useful.
The password for all users is "secret".
The test server is currently running at "test.fab-access.org:59661"
Please write if you need clarifications on any subject matter.
Greetings, dequbed & Joseph
Naming Things
0.?
https://de.wikipedia.org/wiki/Historisches_Archiv_der_Stadt_K%C3%B6ln#Einsturz_des_Geb%C3%A4udes_im_M%C3%A4rz_2009
Ideen:
- Rubbles of Cologne
- Shattering in Cologne
- Eroding down Cologne
- Collapsing down Cologne
- Collapsing in Cologne
0.??
Elbphilharmonie
Ideen:
- Reverberating Hamburg
0.???
https://de.wikipedia.org/wiki/GAIA-X
Notes
- 0.2: "Joris-Version"
- 0.3: Erster Status, der überhaupt valide veröffentlicht werden kann (TLS). Tür öffnen noch schwierig. (bis spätestens April 2022)
- 0.4: Abstraktionseben geschaffen, komplexer Status einer Maschine setzen können. Z.B. zusammenhängende Maschinen (Kühlungen / Lüftung / ..). Tür ist einfach nutzbar eingebaut. (bis spätestens August 2022)
- 1.0: Stabile API für Maschinenstatus, erweiterbar - vorhandenes geht beim Erweitern nicht kaputt.
- Menschenlesbare Dokumentation der API - nicht zwingend in Cap'nProto, auf jeden Fall aber in den abgeleiteten Anwender-Schnittstellen (Python/...).
- Visionäre Versionen
- 1.x: Raumbuchung ermöglichen, ...
- ... bis 2.0 wird nichts mehr "kaputt gehen" - d.h. Versionskompatibilität.
Recap mail aka. CYA cryptobros edition
Hello all,
since two of our guys couldn't join the meeting I'll recap the main points from the meeting earlier today:
Updating the information we had so far Adam is the technical manager for the work-package of FabAccess in INTERFACER, making him our primary contact person for technical issues instead of Henry. As Henry and I have discussed in January we'll want to have a test setup before a more precise priority list for the requirements is made.
We scheduled a follow-up meeting on 2022-04-19 at 15:50 CEST, and decided tentatively to make the 15:50 slot every tuesday a weekly meeting for further establishing details of the integration of FabAccess in the INTERFACER project, starting out with somewhat longer meetings as required.
The main topics that were identified to require further discussion are the requirements that FabAccess poses to the FabCityOS IAM system, especially special topics like card management, and to refine the requirements for the FabAccess milestones in the current roadmap.
Please tell me if you spot any mistakes.
Greeting, dequbed
24.01.2022 // Mitschrift HTW
Jana, Cristopher, Martin Ideas in Action Martin zukünftiger Leiter des Makerspaces Paul SHK - Raumbuchungssystem Wojtek Prof. - Raumbuchungssystem - IT Zuständig Erich Rother KI-Werkstatt - Einrichten eines Raumbuchungssytem/Resourcenbuchungssystem
Kooperation des Systems mit dem Raumbuchungssystem Projekt Ideas, bei dem interaktive und kreative Labore enstehen sollen, wo Studierden aktiv werden sollen.
KI-Werkstatt, Interaktive Geräte zu KI Themen
Raumbuchungssystem für Kurse über VMs bis zu einer Säge -> Menschenverwaltet
Intergration in LSF (Hochschulsystem)
26.12.2021 // Name for the Abstraction Layer of the Server and the Protokoll in Capn Proto
Bedingung: Es muss aussprechbar sein und sprachlich übermittelbar
Idee: irgendwas mit Kleber
14.12.2021 // Install FabAccess
Install FabAccess
Minimal Hardware Requirements
Server
tl;dr No Hardware Requirements known so far. No all Platforms are supported with Docker Images.
- a CPU would be nice but we can technically run on a mainframe too.
- At least 2MHz though. We need a speedy boi
- Some memory. The stick you found in your attic is fiiine
- 30MB should be enough. But if you want to really sure, make that 40MB
- A network card. Any one is fine if it speaks Ethernet even better but your old bus card is dandy too
or if building a custom PC just so you can run FabAccess is too much effort; a Raspberry Pi is fine, although RasPi 2 and up are recommended. Any one really (exept: Raspberry Pi 1 or Raspberry Pi Zero).
Client
Android SDK Version: 21 iOS Version: 13 Windows 10: 1709 - Build:16299
Internal Release
Internal Release is only for our Space to develop FabAccess and distribute the Server and the Client easier to our users. We keep everything Open Source, but we not want to fear your users with to many bugs.
Beta Release
To not overcomplicate our CI/CD and developent process this acctual "Beta" is more an "Alpha" for intreseted testers.
Install the Server
Option 1. rustup && cargo install
Steps:
- Install rustup.rs. Distribution packages for rustc are generally way too old
-
$ rustup install stable
- Get yourself a directory to clone BFFH into
- If you put this dir on a SSD you can speed up build times by 5-10 times.
-
git clone --recursive --branch stable
- ... stable ... TODO...
- You can also check out the
development
branch but keep in mind that until Beta it has no stability guarantee. It may work. It may make you a sandwich. But it may also set your hat on fire and fill your shoes with orange juice. You have been warned.
-
cargo install --path .
- if you add
--debug
you get a debug build. It gives you much more logging output but it's slower to run and is almost spammy
- if you add
- Make yourself a coffee. Or tea. Or open $beverage of your choice. You earned it! (And you'll be looking at "Compiling
" for a while.) - If you get
error: failed to run custom build command for 'gsasl-sys v0.2.3'
or something like that with the stderr output reading "[…]Unable to find libclang[…]":-
export LIBCLANG_PATH=/usr/lib
Or whereverlibclang.so
is installed on your computer. It's usually/usr/lib/libclang.so
or/usr/lib/llvm/12/lib/libclang.so
or similar. If you can't find it, consult your package manager
-
- If you get any other error open an issue
- If you get
Option 1.1 Install on Ubuntu for "Dummies"
- see further below, as t his is a bit of a lengthy process...
Option 2. Docker
Docker Image can not run on armv6 (Raspberry Pi 1 or Raspberry Pi Zero)
Steps:
- Install Docker On Raspberry Pi: https://phoenixnap.com/kb/docker-on-raspberry-pi
- Install Docker-Compose On Raspberry Pi: https://dev.to/elalemanyo/how-to-install-docker-and-docker-compose-on-raspberry-pi-1mo
- Get Docker-Compose Files
git clone https://gitlab.com/fabinfra/fabaccess/dockercompose.git
The Dockerfile is in the root directory of the main repo docker-compose.yml is available in a seperate git repo - Edit config files in
config
folder to taste - Start Server with
docker-compose up -d
To make it eaysier to apply youre changes in your config and keep the dockercompose uptodate, you should "fork" this respository.
Get Server Logs
docker-compose logs
Install the Client
Currently only Windows(UWP), Android and iOS are directly supported.
Option 1. Platform App Store
Android: https://play.google.com/store/apps/details?id=org.fab_infra.fabaccess iOS: https://testflight.apple.com/join/KfeUaHT4 Windows:https://www.microsoft.com/de-de/p/fabaccess/9p69mwzjf2mv
Option 2. Build locally
Follow build instructions on: https://gitlab.com/fabinfra/fabaccess/borepin
... and now for something completely different...
Option 1.1 Install on Ubuntu for "Dummies"
This description is how to compile and set up Diflouroborane on Ubuntu 20.04.3 LTS clean install. Other releases or distros might work as well. The process is quite lengthy but at the end you will have a FabAccess running to you needs. ... as I said: for complete dummies, if someone finds a better solution, please post suggestions on: https://fabaccess.zulipchat.com/#narrow/stream/255963-General/topic/Demo
Steps
-
Get your system up-to-date
sudo apt-get update && sudo apt-get upgrade
-
Get rustup
sudo apt install curl
curl --proto 'https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
restart the console -
Get capnproto, gsasl and git
sudo apt-get install gsasl
sudo apt-get install capnproto
sudo apt install git
-
Create a target directory for BFFH there might be better places compared to where I created it, but it works...
mkdir BFFH
cd BFFH
-
Clone the Diflouroborane repository
git clone https://gitlab.com/fabinfra/fabaccess/bffh
-
For compiling some dependencies were missing on Ubuntu
git submodule update —init
sudo apt install libgsasl7-dev
sudo apt install cmake
sudo apt install libclang-dev
sudo apt install libssl-dev
sudo apt install cargo
-
Open the subdirectory and start compiling
cd bffh
cargo build --release
if the compiler prompts somthing like "error: linker 'cc' not found":sudo apt install build-essential
cargo build --release
-
Copy the configuration files (best done with the GUI filemanager of Ubuntu) copy files from "bffh/examples" paste them into "bffh/target/release/examples"
-
Install mosquitto MQTT broker Diflouroborane uses mosquitto MQTT broker to communicate with the Shellies.
sudo apt-add-repository ppa:mosquitto-dev/mosquitto-ppa
sudo apt-get update
sudo apt-get install mosquitto
sudo apt-get install mosquitto-clients
sudo apt clean
find out which linux release is installed (for Ubuntu -> google)uname -a
sudo wget http://repo.mosquitto.org/debian/mosquitto-bullseye.list
change "bullseye" according to your distro: bullseye, buster, stretch, jessie, ... -
Configuring mosquitto broker for some reason, starting with version 2.x mosquitto does not allow external communication via the broker per default. This needs to be changed via a config file:
-
Stop mosquitto
sudo service mosquitto stop
-
Change into the "etc/mosquitto/" directory (lots of
cd ..
thencd etc
,cd mosquitto
) -
Create a configuration file:
sudo touch file test.conf
-
Edit the configuration fil:
sudo nano -w test.conf
add:listener 1883
allow_anonymous true
Save (Strg-O) and close (Strg-X) -
Start mosquitto
mosquitto -v -c /etc/mosquitto/test.conf
-
Find the IP adress of your computer - new console
ip a
-
Configure your Shelly as long as your Shelly has not been given the credentials for a WLAN, it will create an access point (AP) for configuration. This AP will appear in your list of WLAN. Connect to this Shelly-AP and connect to
192.168.33.1
in your browser. A configuration page should appear. If your Shelly is already connected to your WLAN, you must find the assigned IP-Adress (e.g. by looking into your router). Enter this IP Adress in your browser and you will get the configuration page. -
MQTT Client setup goto "Internet & Security" -> "Advanced - Developer Settings" enable "MQTT" enter the IP-Adress from Step 16 in the field "IP-Adress" As we did not define MQTT credentials in mosquitto yet, no creadentials need to be filled in. To find the "ID" of your Shelly activate "Use custom MQTT prefix" (but do not change it!). This should be somthing like:
shelly1-123456789ABC
for a Shelly 1shelly1pm-123456
for a Shelly 1PM note this ID for later - save - re-check the settings! -
WLAN Client setup goto "Internet & Security" -> "WIFI MODE - CLIENT" Set WLAN Credentials
-
Configure Diflouroborane Open the file "bffh.dhall" in the GUI Editor (just by double-clicking it) Change
Shelly_123
to your Shelly name, e.g.shelly1-123456789ABC
(case sensitive!, dash sensitive!) in "Link up machines to actors" and in "actors". Change the third IP-adress under "listens" to the IP-adress of your computer. - save -
start Diflouroburane change to the directory in the console where you checked for the ip-address
cd BFFH/bffh/target/release
load settings to Diflouroborane:./diflouroborane -c examples/bffh.dhall --load examples
start Diflouroborane:./diflouroborane -c examples/bffh.dhall
Important
every time you change the bffh.dhal you need to reload the settings (otherwise the App will not connect to the server on restart):
./diflouroborane -c examples/bffh.dhall --load examples
and restart start Diflouroborane:
./diflouroborane -c examples/bffh.dhall
Download the borepin APP as described previously
- start the App
- press: "Connect to new Server"
- press: Enter the IP of your computer in the "Host"-Field
- Enter your Username and Password.
To connect to the demo instance
- start the App
- press: "Connect to new Server"
- press: "Demo Host Address"
- User: "Testuser"
- Passw: "secret"
Have fun and give feedback!
22.11.2021 // Prioritäten
- Persistenz beim Neustart
- QR-Codes
- Aktiver User sichtbar
- Wiki-Link
- Block / Disable
- ToCheck
- SwipeDown um zu aktualisieren
30.09.2021 // Config Docs
BFFH uses DHALL for Config-File structure BFFH uses RBAC for access control
General BFFH Config
General BFFH Config is in bffh.dhall
file.
listens
Contains the Addresses BFFH is listen for Connection for the API
Default Port for BFFH is 59661
Example:
listens =
[
{ address = "127.0.0.1", port = Some 59661 }
]
mqtt_url
Contains the Address for the MQTT Server BFFH connects to Example:
mqtt_url = "tcp://localhost:1883"
db_path
Contains the Path for the internal Database BFFH uses.
BFFH will create two files: <db_path>
and <db_path>-lock
.
Make sure that BFFH has write access in the relevant directory
Example:
db_path = "/tmp/bffh"
Permissions
BFFH uses a Path-style string as permission format, separated by ".".
So for example this.is.a.permission
consists of the parts this
, is
, a
and permission
.
When requireing permissions, such as in machines you always need to give an exact permission, so for example test.write
.
When granting permissions, such as in roles you can either give an exact permission or you can use the two wildcards *
and +
.
These wildcards behave similar to regex or bash wildcards:
-
*
grants all permissions in that subtree. So,perms.read.*
will match for any of:-
perms.read
-
perms.read.machineA
-
perms.read.machineB
-
perms.read.machineC.manage
-
-
+
grants all permissions below that one. So,perms.read.+
will match for any of:-
perms.read.machineA
-
perms.read.machineB
-
perms.read.machineC.manage
-
but not
perms.read
-
Wildcards are probably most useful if you group you machines around them, e.g. your 3D-printers and your one bandsaw require:
- Write permissions
-
machines.printers.write.prusa.sl1
-
machines.printers.write.prusa.i3
-
machines.printers.write.anycubic
-
machines.bandsaws.write.bandsaw1
-
- Manage permissions
-
machines.printers.manage.prusa.sl1
-
machines.printers.manage.prusa.i3
-
machines.printers.manage.anycubic
-
machines.bandsaws.manage.bandsaw1
-
- Admin permissions
-
machines.printers
- For all printers
-
machines.bandsaws
- For all bandsaws
-
And you then give roles permissions like so:
- Use any 3D printer:
-
machines.printers.write.+
-
- Only allow use of the "cheap" printers
-
machines.printers.write.anycubic.*
-
machines.printers.write.prusa.i3
-
- Allow managing of printers:
-
machines.printers.+
-
- Allow administrating printers:
-
machines.printers.*
-
This way if you buy a different anycubic and split the permissions to e.g.
-
machines.printers.write.anycubic.i3
-
machines.printers.write.anycubic.megax
It still works out.
Machine Config
Machine Config is in machine.dhall
file.
machines
Contains list of machines
Machines have different perission levels to interact with:
- disclose: User can see the machine in machine list
- read: User can read information about the machine and there state
- write: User can use the machine
- manage: User can interact with the machine as Manager (Check, ForceFree, ForceTransfer)
Example:
machines =
{
Testmachine =
{
name = "Testmachine",
description = Some "A test machine",
disclose = "lab.test.read",
read = "lab.test.read",
write = "lab.test.write",
manage = "lab.test.admin"
}
}
Roles Config
Roles Config is in roles.dhall
file.
roles
Contains list of roles
Roles have a list of permission and can be inherited. Permission can be wildcard in permission list.
Example:
roles =
{
testrole =
{
permissions = [ "lab.test.*" ]
},
somerole =
{
parents = ["testparent"],
permissions = [ "lab.some.admin" ]
},
testparent =
{
permissions =
[
"lab.some.write",
"lab.some.read",
"lab.some.disclose"
]
}
}
Actors Config
Actors Config is in actors.dhall
file.
actors
Contains list of actors Actors are defined by a module and one or more paramters
Currenty supported actors:
Shelly
Parameters:
id
= ID of the Shelly
Process
Parameters:
cmd
= Path of executable
args
= Arguments for executable
Example:
actors =
{
Shelly_1234 = { module = "Shelly", params =
{
id = "12345"
}},
Bash = { module = "Process", params =
{
cmd = "./examples/actor.sh",
args = "your ad could be here"
}}
}
actor_connections
Connects the actor with a machine A machine can have multiple actors Example:
actor_connections =
[
{ _1 = "Testmachine", _2 = "Shelly_1234" },
{ _1 = "Another", _2 = "Bash" },
{ _1 = "Yetmore", _2 = "Bash2" }
]
26.09.2021 // CI Docs
Build Servers
Public Servers
3 Public Build Servers
- Windows
- MacOS
- Linux
Can run on any branch Only contains build tools Never contains credentials
Running on V-Servers on a public Root-Server
Internal Servers
3 Internal Build Servers
- Windows
- MacOS
- Linux
Used for Signing and Deployment Signing Key are local on the Internal Build Servers Only run on CD Branches Protected Enviroments Manual Rollouts
CD Docs
Borepin and BFFH are deployed in 3 stages
- Internal
- Beta
- Production
Internal(innov) Stage
Tag Borepin: alpha Tag BFFH: alphav0.1.0-
Borepin deploys to "FabAccess Testing - Intern and Beta" BFFH deploys to docker-tag "internal"
Versionnumber is JobID
Internal is only for "InnovisionLab"
Foo builds
Tag BFFH: v0\.[0-9]+\.[0-9]+
- Keine Stabilitätsgarantie
- Minor version Client<->Server muss ident sein
- Config kann inkompatibel sein
letzte alpha: v0.N.M
Bar builds
Tag BFFH: v0.X.Y
X > N
- Begrenzte Stabilitätsgarantie
- API is nie wieder broken bis zur v0.X+2.0
- Automatische updates sollten nichts kaputt machen
- Wenn schon nicht 1a kompatibel dann wenigstens konvertieren
- ...
- ...
Test builds
Tag BFFH: v0.X.Y+1-<git tag>
Stable release
Tag BFFH: v1.0.0
- Was auf uns dependet geht nicht kaputt
Beta Stage
Branche Borepin: beta Branche BFFH: beta
Borepin deploys to "FabAccess - Beta" BFFH deploys to docker-tag "beta"
Versionnumber is JobID
Beta is for external Testers
Production Stage
Branche Borepin: main Branche BFFH: main
Borepin deploys to "FabAccess - Production" BFFH deploys to docker-tag "latest"
Versionnumber is Git-Tag
Production is for all Users
25.09.2021 // Drehstrom Schalter
Leistungsbeschreibung
max. 16A 3 Phasen
Einkaufsliste
1x ABB ESB 24-40 1x Shelly 1 1x OBO BETTERMANN 2007734 2x Kabelverschraubung M20 - Bsp.: LAPP 53111420 1x PHOENIX CONTACT ST 2,5 BL 3x PHOENIX CONTACT ST 2,5 GR 1x PHOENIX CONTACT ST 2,5 PE 1x PHOENIX CONTACT ST D2,5 1x PHOENIX CONTACT FBS 2-5
1x IDEC YW1L-MF2E10QM3S 1x IDEC YW1P-1BUQM3G 1x IDEC YW1K-2AE10
??x Aderendhülse isoliert 2,5mm2 ??x Aderendhülse isoliert doppelt 2,5mm2 0.5m TITANEX H07RN-F 5G2,5mm2 - Zum Klemmenanschließen
Leitungslänge an Bedarf anpassen: 2m TITANEX H07RN-F 5G2,5mm2
optional für Stecker-Kupplung: 1x MENNEKES 13510 1x MENNEKES 14510
Werkzeuge
Schraubendreher - Schlitz 0,6mm x 3,5mm Schraubendreher - Schlitz 5mm Schraubendreher - PH1 Abmantelungswerkzeug Abisolierwerkzeug Crimpzange - Aderendhülsen Stufenbohrer 20-22mm
Kosten
ca. 80 €
20.03.2022 // Design Decisions NFC Reader
Design Decisions NFC Reader
Bauteile:
- NFC
- ESP-32
- USB-C
- Buzzer
- 2 Buttons
- Intrusion Detection
- IPX6
Version Battery:
- 18650 Zelle
- E-Paper Display
Version PoE:
- PoE
- Ethernet
- OLED Display
NFC IC:
IC | LPCD Current | Verfügbarkeit | Preis | MOQ |
---|---|---|---|---|
MFRC522 | x | 150 (Mouser) | 5,85 € | 1 |
TRF7963A | x | 381 (Mouser) | 4,53 € | 1 |
TRF7970A | x | 5.888 (Mouser) | 4,95 € | 1 |
ST25R3911B | 3.6 - 8 uA | 0 | 5.910 € - 4.098 € | 1 |
CLRC663 | ||||
PN5190 | Text | Text |
22.09.2021 // FabAccess Workshop
Basic Information
PI
Password: password
WLAN
SSID: fabaccess_workshop Password: ?fabinfra!
Shelly
IP: 192.168.33.1
PI Preparing
# update pi
sudo apt update && sudo apt upgrade
# install docker
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker pi
sudo pip3 install docker-compose
reboot
Install BFFH
# clone example repo
git clone https://gitlab.com/fabinfra/fabaccess/dockercompose.git ~/fabaccess_dockercompose
Start BFFH
cd ~/fabaccess_dockercompose
docker-compose up
BFFH Config Dateien
nano config/bffh.dhall
nano config/roles.toml
nano config/user.toml
Shelly Config
MQTT Client
Internet & Security -> Advanced - Developer Settings
Enable MQTT
IP Address = Pi IP
Set MQTT Credentials
Wlan Client
Internet & Security -> WIFI MODE - CLIENT
Set WLAN Credentials
20.09.2021 // Workshop Beschaffungsliste
5 fach Schukosteckdosen
11.09.2021 // Drehstrom Schalter und Strommessung
Leistungsbeschreibung
max. 16A
Einkaufsliste
1x ABB ESB 24-40 1x Shelly 3EM 1x OBO BETTERMANN 2007734 2x Kabelverschraubung M20 - Bsp.: LAPP 53111420 1x PHOENIX CONTACT ST 2,5 BL 3x PHOENIX CONTACT ST 2,5 GR 1x PHOENIX CONTACT ST 2,5 PE 1x PHOENIX CONTACT ST D2,5 1x PHOENIX CONTACT FBS 2-5 1x RS PRO 188-1141 1x RS PRO 188-1170 1x RS PRO 188-1193 1x RS PRO 763-7949
??x Aderendhülse isoliert 2,5mm2 ??x Aderendhülse isoliert doppelt 2,5mm2 0.5m TITANEX H07RN-F 5G2,5mm2 - Zum Klemmenanschließen
Leitungslänge an Bedarf anpassen: 2m TITANEX H07RN-F 5G2,5mm2
optional für Stecker-Kupplung: 1x MENNEKES 13510 1x MENNEKES 14510
Werkzeuge
Schraubendreher - Schlitz 0,6mm x 3,5mm Schraubendreher - Schlitz 5mm Schraubendreher - PH1 Abmantelungswerkzeug Abisolierwerkzeug Crimpzange - Aderendhülsen Stufenbohrer 20-22mm
Kosten
ca. 160 €
30.08.2021 // Informationsangebot
Folgenden Leistungen erwarten wir:
- Weiterentwicklung des API (Application Programming Interface) für die UI (User Interface)-Anbindung und Ergänzung durch die Bereitstellung von notwendigen Informationen für Assistenzsysteme - 50h (z.B. für Statusmonitoring an steuerbaren Maschinen)
- Veröffentlichung einer Open Hardware SmartCard-Authentifizierung für die prototypische Nutzerauthentifizierung an Maschinen - 80h
- Realisierung von Audit-Logs als Format für strukturierte Maschinennutzungsdaten - 20h
- Veröffentlichung eines grundlegenden und niedrigschwelligen UI für eine nutzerfreundliche Anwendung - 140h
- Initialisierung eines Scripting-API (auf Basis von Python oder Lua), wodurch das System einfach an unterschiedliche Kontexte angepasst werden kann - 10h
- Etablierung der Förderations-Schnittstelle, um die FabAccess-Nutzer an das Fab City OS anzubinden - 50h
- Entwicklung einer Branding und Templating UI, um individuelles Branding der Software in unterschiedlichen Produktionsstätten zu ermöglichen - 10h
- Integration weiterer Maschinen-Metadaten für erweiterte Umgebungen und Nutzungskontexte (z.B. Einbindung mobiler Geräte) - 30h
- Anpassungen für ein erweitertes Monitoring von Maschinenparametern - 10h
- Ownership, Optimierung und Stabilitätsentwicklung für die nachhaltige Nutzung und Weiterentwicklung - 20h
- Testen des Systems mit ausgewählten Partnern - 80h
15.07.2021 - Meta-Pad Zugangskontrollsysteme f. Offene Werkstätten
Meta-Pad Zugangskontrollsysteme f. Offene Werkstätten
Hier entsteht ein Zugangssystem, das, basierend auf den verschiedenen Ansätzen und gemachten Erfahrungen verschiedener Offener Werkstätten, eine möglichst breite Nutzbarkeit ermöglichen soll und Open Source ist. Ziel ist die Entwicklung möglichst objektbasierter und generischer Schnittstellen, die die diversen Bedürfnisse der Werkstätten abdecken und bestehende Systeme integrieren.
Parallel werden bereits bestehende Systeme gesammelt und ein Überblick über diese Systeme erstellt, um die daraus gewonnenen Erkenntnisse sinnvoll in das entstehende System einfließen zu lassen.
Timeline - Entwurf
- Leute einsammeln bis 23.11. (wer danach kommt, kommt halt danach - muss damit leben, dass die anderen schon los gelaufen sind)
- Core-Entwickler entscheiden sich bis zur ersten Mumble-Session ob sie einer sein wollen
- erste Mumble-Session: https://dudle.inf.tu-dresden.de/-nkSQJu6-Q/
- Beim ersten Mumble-Treffen:
- Vorstellen
- 36C3-Umfrage
- Grundlagenfragen zu Infrastruktur klaeren
- Wie viel von derzeitigen Systemen uebernehmen / wie viel backwards-Kompatibilität können / wollen wir
- Was sind MUSS / SOLL / KANN Randbedingungen bzw. explizit verwendete Standards?
- Versionierung / Sprache / Aufbau / …
- Was soll bis März angepeilt werden, was wird evtl. später integriert, wo grenzen wir ab?
- Termine für stetige, regelmäßige Treffen (Mumble)
- Termin & Ort für Hackathon(s)
- Was passiert bis zum Congress
- Treffen auf dem 36C3 - wer ist da und Assembly / Space festlegen
- Hack-Wochenende Ende Januar (nach 22.01.) mit VoW (primär Core-Entwickler)
- Zum 01.02.2020 erste Version vom Modul-API/-System einsatzbereit
- Ab da können sinnvoll Module fuer FabLabs/Makerspaces gebaut werden
- Erster Fokus auf die meistverbreiteten Anwendungsfaelle (Mensakarte + evtl. Pin, ESP8266, etc => Rausfinden!)
- Erste Module als Test
- Hack-Wochenende (nach 22.02.) mit VoW (incl. Modul-Entwickler)
- Deadline für V1.0 am 01.03. (falls finale Deadline am 31.03., sonst früher).
- Ab hier gelten dann bestimmte (noch festzulegende) Garantien fuer Stabilitaet
Anforderungsliste / Ziele / Funktionen
Das (ideale) System soll…
- Nutzer (nur) mit Einweisung & Zugangsberechtigung unkompliziert die Arbeit an Maschinen ermöglichen. Maschinen stromlos schalten, so lange sie nicht von jemand mit entsprechenden Voraussetzungen bedient werden.
- Manche Geräte qualifizierter Überwachen und aktivieren / deaktivieren / verwalten.
- Qualifikation der Nutzer in der Relation “Nutzer - Maschine” abbilden und bei der Zugangskontrolle berücksichtigen.
- z.B. in 5 Stufen: [-1] explizit gesperrt [0] darf zusehen [1] darf unter Aufsicht und Anleitung arbeiten [2] darf selbständig arbeiten [3] kann einrichten und einstellen [4] kann warten / instandsetzen [5] kann schulen & einweisen
- Auf abgelaufene Einweisungen hinweisen & einfordern.
- Dabei helfen, Öffnungszeiten durchzusetzen.
- z.B. 30 min. vor Feierabend im Display herunterzählen und bestimmte Maschinen zum Feierabend hart abstellen.
- Nicht alle Maschinen!! - 3D-Drucker z.B. laufen auch nachts.
- Türen öffnen? - (Diskussionspunkt)
- Einfach installierbar sein und keine besonderen Anforderungen an Hardware / Netzwerkumgebung stellen. (RaspberryPi in der Ecke sollte im Notfall als zentrale Hardware reichen)
- Aus Grynden der Stabilität und Datensicherheit ist natürlich ein “ordentlicher” und gut eingerichteter Server besser & ab einer gewissen Größe / Professionalität des Labs ratsam. Die Doku muss das abdecken.
Das System muss modular aufgebaut und flexibel (einfach!) einricht- anpass- und erweiterbar sein, um auf lokal verschiedene Anforderungen eingehen zu können.
Bereits laufende Aktivitäten
an Hochschulen
Fab Lab Siegen (David Amend)
- fablab-siegen.de
- Github: https://github.com/FabLabSiegen/FabLabAccessControl
- “Key-Features”
- Switch plugwise plugs on and off via RFID chips
- Access control via ESP8266 and RFID-reader
- Device management of plugwise devices, RFID chips and ESP8266 via webinterface
- Usermanagement via webinterface
- Communication between ESPs and backend via MQTT
BHT Berlin
qrhello (niedrigschwelliges, einfach zu “überlistendes” QR-Code-System)
- Nutzerschnittstelle: QR-Etiketten mit (lokaler) URL
- Komponenten:
- Flask / Python / UWSGI / Apache-Server
- (noch) SQLite-DB für Einträge
- Schnittstelle zu PostgreSQL-Datenbank von Leihs (ZHDK) Leihs
- Verlinkt zu einem Labor-Wiki (Media-Wiki) mit Infos und Bedienungsanleitungen.
Keine Einrichtung von einzelnen Maschinen notwendig - Etikett ausdrucken, draufkleben - that’s it.
Die Nummerierung und Bezeichnung der Maschinen wird (falls dort hinterlegt) aus Leihs übernommen.
Aktuell keine Logik für Zugangskontrolle und / oder Maschinenschaltung integriert.
card2go (RFID-gesichertes System mit Datenbank-Backend)
- noch private (https://github.com/HazeCore/Card2Go/)
- in GO geschrieben.
- Middleware-Server ohne grafischem Front-/Backend … bildet “Geschäftslogik” und Zugangskontrolle mit den o.a. 5 Berechtigungsstufen im FabLab ab.
- Etliche Edge-Cases im FabLab-Betrieb abgebildet.
- Maschinenabnahme durch Lab-Betreuer nach Nutzung
- Unkomplizierte Übergabe einer Maschine machbar
- Signalisieren / Ausschalten zum Feierabend
- laufenlassen bestimmter Maschinen (z.B. 3D-Drucker)
- Etliche Fehler bei Verbindungsverlusten zu Server / DB abgefangen.
- Zwangs-Einschalten / -Ausschalten mit Master-RFID-Karten
- E-Check v. Maschinen hinterlegbar
- Manche Maschinen (z.B. Tische / Werkbänke) brauchen keine Einweisung / keinen E-Check
- Display-Steuerung (0,96" OLED-Display hard-coded)
- …
Diflouroborane (Konzeptprototyp fuer ein von Anfang an fuer weiten Einsatz gebautes System)
Kurzbeschreibung in Fliesstext Stichpunkten:
- Zentrales RabbitMQ spricht MQTT, STOMP und AMQP, erstere zwei auch ueber WebSockets (z.b. fuer Webapplikation hilfreich)
- N-Step Authentication um flexibel genug zu sein um jeden Typ Authentifizierung zu implementieren.
- Diflouroborane (kurz BF₂H) ist eine relativ monolitische Applikation die die eigentliche Logik bzw. die im FabLab-Betrieb auftretenden “Geschäftsprozesse” implementiert.
- Auch wenn es ein Monolith ist wird BF₂H darauf ausgelegt modular und anpassbar genug zu sein um mit allen denkbaren Steuersystemen interagieren zu koennen und agnostisch gegenueber Authentifizierungs- bzw. Authorisierungssytemen zu sein.
Auditlogs
ist ein getrenntes System was ueber AMQP ueber Verwendung informiert wird- Anwendungsfall sind speziell Labore die Verwendung/Material/o.ae. abrechnen muessen/wollen oder die wegen Vorschriften oder Versicherung genauere Buchfuehrung ueber Anwesenheit/Verwendung haben muessen.
- Ein Web-/Graphisches-UI ist im Moment nicht Teil des Konzepts weil dequbed wenig Erfahrung damit hat. Vorschlaege sind gerne gesehen!
Das System ist ein frueher Prototyp und noch stark in Flux, deswegen sei fuer genauere Architektonische Details so wie den Code derzeit auf GitHub verwiesen.
RFID-Terminal
Kleiner Prototyp als Kombination verschiedener Gieß-Materialien und -Verfahren (Epoxid, PU, Acryl).
Display eingebettet, RFID-Spule eingebettet, Formteil für RFID-Karten & Fobs als negativ-Gießteil.
Verbesserungsfähiger Demonstrator / Mock-Up bei Tasso --> wer’s weiterentwickeln will, kann vorbei kommen und übernehmen.
ESP-Schütz
Für Drehstrom-Maschinen (Drehbank / Fräsen / …)
Kleine Ergänzungs-Platine, auf oder neben Schütz montierbar.
Bekommt Kommandos über WLAN und MQTT (z.B. aus OpenHab)
Schaltet die Schütz-Spule über ein SolidStateRelay (z.B. Panasonic AQH2213).
Das Schütz wiederum schaltet die Stromzufuhr zur Maschine.
Wichtig: Wiederanlaufschutz direkt an der Maschine vorsehen! - nicht “einfach so mal schnell” ein Schütz reinklemmen. Andernfalls kann schnell mal eine Drehbank “remote” eingeschaltet werden, an die sich jemand gerade “nur mal angelehnt” hatte --> wär blöd!
Auch nichts für “Niedervolt”-Anwender! - aktuell als Eingriff in die Zuleitung zur Maschine realisiert und damit hart am Regelungsbereich der Maschinenrichtilinie. Als Lösung evtl. als “Zwischen-Schaltgerät”, in jedem Fall aber Netzspannung und nur was für “VDE-Kundige” bzw. mit einiger Aufmerksamkeit anzugehen.
Mock-up existiert bei Tasso an der Drehbank --> wer’s weiterentwickeln will, kann vorbei kommen und übernehmen.
Düsseldorf (Fabian Meyer)
- https://fabaccess.bian-meyer.de/
Zugangssystem zum Schalten von Steckdosen entstanden an der Hochschule Ruhr-West. Momentan in Weiterentwicklung mit dem Verbund offener Werkstätten
-
Eigenschaften
-
Authentifizieren des Benutzer und Buchen/Schalten einer Maschine über Android/(iOS) App mit RFID Karte an NFC fähigem Tablet
-
odoo (ehemals openERP OpenSoruce ERP-System) als Nutzerdatenbank und zur Buchführung für die Benutzung von Geräten
- Nach Beendigung der Buchung wird eine Rechnung in odoo erstellt
- Buchung einer Maschine nur möglich, wenn Sicherheitseinweisung stattgefunden hat
-
Abstraktion der Schaltbaren Hardware (Steckdosen) durch openHAB
- durch openHAB einheitliche Schnittstelle zum schalten von Geräten unterschiedlicher Hersteller/Protokolle
- Getestet mit zWave Steckdosen
- durch openHAB einheitliche Schnittstelle zum schalten von Geräten unterschiedlicher Hersteller/Protokolle
-
-
Bestandteile
- odoo
- openHAB
- App: Stellt schaltbare Geräte an einem konfigurierten Ort visuell dar und erlaubt dem Nutzer sich per RFID Tag am Gerät zu authentifizieren und Geräte zu buchen/schalten (Und die Buchung nach erneuter Authentifizierung wieder zu Beenden)
- GitHub: https://github.com/faaaaabi/fablab-access-app
- Sprache/Frameworks: ReactNative, JavaScript, Redux, …
- Status: Prototyp, Authentifizierungsfunktion und Buchen von Geräten funktional.
- API-Gateway: Bietet REST-API (Websocket für Realtime-Kommunikation ist vorbereitet) für die App an und enthält Businesslogik welche die Funktionalität über odoo und openHAB abbildet. Zugrifssgeräte authentifizieren sich über API Key und erhalten JWT-Token, welches bei allen witeren Request mitgeschickt wird. Bei der der Authentifizierung einse Benutzers am Zugriffsgerät wird ein Intermediate-Token erzeugt, welches nur 20 Sekunden gültig ist und nur für das Buchen eines Gerätes. Dies soll Replay-Attacken verhindern. Für die Datenhaltung wird momentan MongoDB verwendet. Das fühlt sich für die Entwicklung ganz gut an, da kein striktes Schema für die Entitäten vorhanden (Diese quasi noch entsteht). Architekturell lässt sich für Datenhaltung aber auch relativ schmerzfrei ein ander DBMS einsetzen
- Architektur: https://github.com/faaaaabi/fablab-api-gateway#architecture
- GitHub: https://github.com/faaaaabi/fablab-api-gateway
- Sprache/Frameworks: Node.js, TypeScript, Express, MongoDB Passport (Authentifizierung), …
- Status: Prototyp, kein Installationsscript oder docker-compose file vorhanden, kein Webinterface vorhanden. Grundfunktionalität wie - Authentifizierung der Zugriffsgeräte (in diesem Konzept die App) und User, das Buchen von Geräten Und damit verbunden das Schalten von an openHAB angebunden z-Wave Steckdosen, das Erzeugen von Rechnungen - funktional. Für das Anlegen von anderen Resourcen (Maschinen, Zugriffsgeräte, Orte) fehlen noch REST-Endpoints, das läuft bisher manuell in der Datenbank. Die Berechtigungsverwaltung ist bisher sehr rudimentär und dekt nur einen binären Wert ab, ob eine globale Sicherheitseinweisung stattgefunden hat. Vorhandene Teile der REST-API sind dokumentiert
- Admin-Interface:
- GitHub: https://github.com/faaaaabi/fabaccess-admin-interface
- Sprache/Frameworks: React, TypeScript, Redux, …
- Im Internetz: https://fabaccess.bian-meyer.de/
- Status: Clickdummy. Bildet ein flexibleres Berechtigungssystem ab.
-
Key Features:
- Kein Hardware-Selbstbau notwendig
- Benutzersteuerung und Authentifizierung wird über Android/iOS abgebildet. App flexibel anpassbar, kein Hardwareumbau notwendig.
- Durch openHAB flexibel in der Wahl eingesetzter (Schalt)-Hardware
- Netzspannung schalten mit zertifizierten Geräten von der Stange
- Kombination mit odoo
- Kein Hardware-Selbstbau notwendig
-
Derzeit in Entwicklung
- Webinterface zur Administration. Clickdummy: https://fabaccess.bian-meyer.de/
-
Demnächst in Entwicklung
- Abbildung eines einfachen Berechtigungssystems
- Benutzer a hat Berechtigungen b,c,d – Maschine e benötigt Berechtigung b und c
- Anbindung von Selbstbau-Hardware (Türschlösser etc.)
- Entwicklung einer App, welche der Nutzer auf seinem eigenen Smartphone installiert. Diese soll das Buchen von Geräten ermöglichen, indem ein angebrachter QR-Code gescannt wird
- Abbildung eines einfachen Berechtigungssystems
Kunsthochschule Halle
- Fa. Rutte (https://rutte.de/)
ETH Zürich
acos: https://sph.ethz.ch/acos_project/
- Poster: https://sph.ethz.ch/wp-content/uploads/2017/09/Handout_final.pdf
- Authentifizierung an (zentralem) Terminal mit RFID Token
- Buchung von Maschinen und Verbrauchsmaterialien am Terminal
- Schaltung Strom/Öffnen von Schlössern über ESP 8266 und Relay/Türschlosse
- Letzte Aktualisierung der Infopage im Oktober 2018
- Software auf dem Terminal
- C++, Qt, QML
- Kein Source Code verfügbar
In Offenen Werkstätten
https://cowiki.offene-werkstaetten.org/uploads/2017-06-23_11-31-15_Zugangssysteme Überblick (WS).pdf
FabLab L’Aquila
https://github.com/FabLabAQ/LabAccessControl
Google makerspace-auth
Dresden (Roseguarden)
- Nutzerverwaltung über Web
- Zugangskontrolle mit unterschiedlichen Räumen
- Verifikation mit RFID
- basierend auf Raspberry Pi
- Github: https://github.com/mdrobisch/roseguarden
Neue Version in Entwicklung seit 01/2019
- Details siehe https://pad.gwdg.de/v-xVnpWQREmBGuLG_hYTfQ?both
- Repositories (v2): https://gitlab.com/roseguarden
- Demo: https://roseguarden.fabba.space/dashboard
München (FabLab)
-
Nutzeverwaltung über Web
-
Zugangskontrolle Räume und Geräte
-
RFID-basiert
-
Github
- Backend: https://github.com/sschaeffner/fabXaccess
- Frontend: https://github.com/sschaeffner/fabXdashboard
- Client für ESP32/M5Stack: https://github.com/sschaeffner/fabXclient
MakerSpace Graz (“LEASIE”)
Zitat: "Grundidee/Basistechnologie:
Jedes zu vermietende Gerät wird mit einem IOT Gerät, basierend auf Open-Hardware, ausgestattet, dass über WLAN direkt oder indirekt über einen Cloudserver (aktuell) mit der Blockchain kommuniziert. Diese IOT Geräte regeln den Zugang und messen mit unterschiedlichen Sensoren (aktuell Strom) den Zustand des Gerätes. Zwei Varianten: Eine simple „Zwischenstecker“ Lösung und eine erweiterte (aktuell) Variante für größere Maschinen. Beispiel Lasercutter: Es wird das Gerät nicht abrupt abgeschalten, sondern zuerst der Laser. Der Zugang wird über RFID Tags (aktuell) oder NFC (Handy) überprüft. Der Server ist ein Full Node und macht die Kommunikation mit der Blockchain sowie die Abrechnung. Abgerechnet wird 2 stufig: 1 Rechnung geht vom Provider (der der den Platz für die Vermietung stellt) an den Kunden. Eine 2te Rechnung wird für den Maschinenbesitzer an den Provider ausgestellt. Provider erhält eine Fee, Auch wird in eine gemeinsame Maschinenbruchversicherung eingezahlt. Vision: Wenn zB. viele FabLabs oder MakerSpaces an dem System hängen würden, wäre das ein brauchbarer Versicherungstopf. Dapp läuft Clientseitig und erledigt den Zahlungsverkehr, die Vermietung, die Stornierung und die Fehlermeldungen. Später soll noch eine Admin DApp geben, die die Kundenanlage, Maschinenanlage und Fehlermeldungen behandeln kann 2 Smart Contracts: 1 Renting und ein Invoice Contract. Möglichkeit einen eigenen gemeinsamen Tokens, ähnlich eines Gutscheinssystem mit Insentivemöglichkeiten zu verwenden (aktuell) oder an einen Token mit z.B. Eurobindung anzuhängen. Wenn der nächste Mieter keinen Fehler meldet, rechnet das System die tatsächlich verwendete Zeit und Strom ab und überweist den Diffbetrag inkl. Kaution retour. Bei Fehlermeldung wird die Kaution eingefroren, bis der Provider den Fehler mit dem Maschinenbesitzer klärt und die Fehlerkosten erhebt. Gleichzeitig wird die Maschine auch für weitere Buchungen gesperrt. Weitere geplante größere ToDo’s: Admin DApp, DATEV Schnittstelle zur direkten Verbuchung der Rechnungen (Buchhaltung) Ergänzend: Grundsätzlich geht es nicht nur um Maschinen, sondern generell um Ressourcen. z.b. wird darüber auch der Zugang zu den Räumlichkeiten freigeschalten. Weiterer grösser angedachter Entwicklungschritt: diese Ressourcen handelbar machen und eine allgemeine Cloud Plattform dafür zur Verfügung zu stellen (Bsp. Nachbar vermietet Rasenmäher). Ergänzend zum Ressourcenhandel: Wenn du die Ressource gemietet hast und jemand anderer sie dringender braucht, sollte sie dir automatisch zu einem höheren Preis abkaufbar sein. Generell: Für FabLabs, MakerSpaces sollte dieses ganze Konzept völlig OpenSource sein. Jeder soll sich z.B. frei entscheiden können, ob er einen eigenen Token auflegt oder die Vorteile des gemeinsamen Tokens nutzen will. Auch ob er die Hardware selbst bastelt (OpenHardware) etc. Umsatz soll über einen Shop und einem Cloudservice gemacht werden. Jedoch vorrangig über Eröffnung neuer Kundenkanäle wie z.b. Gewerbekunden oder auch Privatkunden über ein Portal, sowie professional Features wie Buchhaltungsschnittstellen, etc."
Capstone (ergänzt am 29.11.2019)
In Hackerspaces
LgHS (Liege Hackerspace, Belgien) (ergänzt am 29.11.2019)
Flipdot e.V. Kassel (ergänzt am 29.11.2019)
TH Köln
- Kombination mit Ilias
Frankreich
Italien
Coredump (Hackerspace Rapperswil-Jona, Schweiz) (ergänzt am 26.06.2020)
- Inventar: https://interna.coredump.ch/inventory/ (Source)
[Projektbeschreibung - MakeThings - Zugangs- & Verwaltungstool für Spaces]
Alternativen
FabMan (https://fabman.io/)
- zu teuer
- nicht OpenSource
open-taffeta
Offener Türöffner mit mobile app. Ausgelegt um an Gegensprechanlagen den Türöffner auszulösen und ein Klingeln zu verhindern wenn man sich selbst reinlässt.
Commons Booking
Verleihsystem für Lastenräder.
Brainstorming - Pad(s) / Arbeitspads
https://hazeco.re/codimd/7HkCBkSBRG6sYvT65wMPFg#
[OpenAccess Sytem Dokument zum Verbundstreffen]
[Mumble 26.11.19]
[Roseguarden]
[DiFlourBorane]
[Dudle für Sprachkonferenz 2]
[Agenda 09.12.2019]
[Protokoll 09.12.2019]
[Materialsammlung 29.12.2019 @36C3]
[Hackathon am 06.02.2020]
[Jitsi-Call am 18.02.2020]
[Diskussion in der Telegram-Gruppe des VoW am 25.02.]
[Treffen in der BHT am 04.03.2020]
[Call zu Werkstatt-Zugangssystemen (Schweiz) am 24.06.2020]
[Juli-Call Nr. 1]
[August Nr. 1]
30.06.2021 // Interfacer Deliverables
stable API for UI (Capn Proto) - Q3 2021
Update main API for controlling of the server, so the Client App can retrieve and display all required information.
OpenHardware SmartCard Initiator - Q4 2021
Release first OpenHardware Version of an OpenSource SmartCard System to activate machines.
Simple deployment method - Q4 2021
Add documentation and processes so that FabAccess can be easily deployed by non-technical users at local spaces and fablabs. Concentrate on documentation of the existing software stack and the setup process.
Audit-Log - Q4 2021
Output a structured log with the activity information about the machines, like who has when used this machine. So an ERP System can create an invoice from that data.
Basic UI - Q4 2021
Release a Beta Version of the UI with basic support of all features of the API
Federation - Q1 2022
Allow users to freely and seamlessly change their workspace between federated spaces
Scripting API - Q1 2022
Internal flows can be customised and extended in a scripting language like Python or Lua
Beta-Release - Q1 2022
Release a Beta Version of FabAccess
Branding and Templating UI - Q2 2022
Allow and help spaces and organisations to create a UI Version with specific customization for their applications
Maschinen Metadaten für erweiterte Umgebungen - Q3 2022
Allows filling machines representation with additional metadata, e.g. GPS data in the case of mobile machines.
extended monitoring and display of maschine parameters - Q4 2022
Support showing of machine metadata, with specific emphasis for branding and templating support so that different organizations can show different metadata as it suits their needs.
Optimisation and stabilty improvements of server and client in perpartation of completion of the funding phase - Q1 2023
Ensure that FabAccess will be usable beyond the timespan of the funding. Optimizing speed of all software involved and improving the stability in terms of software bugs and crashes to make use of FabAccess in production environments feasible.
29.04.2021 // Netzwerkabend Offene Werkstätten 04
06.04.2021 // Produkte für FabAccess
Die Produkte dürfen frei Verwendet werden und auch selber gedruckt werden. Wir stellen die Designs zur Verfügung, damit wir eine möglichst Hohe Wiedererkennung des Systems "FabAccess" erzeugen können. So können Nutzer das System auch in einem anderen FabLab erkennen.
Wir könnten dafür auch einen Shop aufmachen, in dem ein Obolus an die Entwickler geht und eine Finanzierung des Projekts erzeugt werden kann.
Style Guide
Farben
Primär
RGB: #00d4aa C: 68,27% M: 00,00% Y: 47,93% K: 00,00%
Sekundär
RGB: #3c474d C: 73,04% M: 55,09% Y: 49,02% K: 47,64%
Tertiär
RGB: C:
Schrift
Roboto
Print Produkte
Eingangsplakat
Das Eingangsplakat soll es Nutzern ermöglichen schnell die Domain des Space herrauszufinden. Inhalt NFC Tag - Spaceinformationen QR Code - Spaceinformationen Name das FabLabs
Maschinenaufkleber - Klein
A7
Readeraufkleber
A6
Elekrische Produkte
31.03.2021 // Abschlussbericht
Akronym: FabAccess Projekttitel: FabAccess - Förderierte Infrastruktursoftware für FabLabs, Makerspaces und andere offene Werkstätten Zuwendungsempfänger: Gregor Reitzenstein, Jannis Rieger, Joseph Langosch, Kai Kriegel, Tasso Mulzer GbR Name des Zuwendungsempfängers: Gregor Reitzenstein, Jannis Rieger, Joseph Langosch, Kai Kriegel, Tasso Mulzer GbR
Das diesem Bericht zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung unter dem Förderkennzeichen 01IS20S41 gefördert. Die Verantwortung für den Inhalt dieser Veröffentlichung liegt beim Autor.
Kurze Darstellung der Aufgabenstellung und Motivation
Was war Deine Motivation?
Wir möchten FabLab, MakerSpaces, usw. (Spaces) ein Tool geben, mit dem der Zugriff auf Maschinen verwaltet werden kann und so mehr Sicherheit in einem solchen Space entsteht. Weiterhin möchten wir die Zusammenarbeit von Spaces fördern in dem sich Föderationen aufbauen.
Welches Problem wolltest Du mit Deinem Projekt lösen?
Der Zugriff auf Maschinen an den sich Nutzer:innen verletzten können ist aufwändig und bei solchen Maschinen muss immer sichergestellt werden, dass nur Nutzer:in die eingewiesen sind auch Zugriff auf solche Maschienen haben.
Wie war die geplante Vorgehensweise zur Problemlösung (auch Angabe der wichtigsten Meilensteine)?
Vor 2 Jahren kam die Idee zu solch einem System, bei der Kommunikation mit anderen Spaces. Dabei ist herausgekommen, dass es vereinzelt anfängliche Lösungen gibt, aber noch keine über den Stand "Works-for-me" hinaus ist. Darauf hin wurde ein Lastenheft mit den Zielen an ein solches Projekt erstellt, um möglichst viele Anforderungen schon am Anfang eines Projekts vorliegen zu haben.
In der Föderphase sollte dann im erstem Monat die Struktur und die technischen Möglichkeiten erarbeitet werden, sowie in Kombination mit dem zweiten Monat die Proof-of-Concept umgesetzt werden. Parallel sollte dann im zweiten Monat mit der Arbeit an unserem Backend begonnen werden, da hier weniger Proof-of-Concepts ausstehen. Für den vierten Monat war ein Alpha-Test unseres Systems in unserem Labor geplant und danach im letzen Monat ein Beta-Test mit anderen Spaces um die Föderation und deren Konzepte zu erproben.
Beitrag des Projektes zu den Zielen der Förderinitative „Software-Sprint“
Welche Bezüge gibt es zu den Themenfeldern „Civic Tech“ und „Data Literacy“ des Software Sprints oder zu weiteren gesellschaftlich relevanten Zielen bzw. Lösungsansätzen?
Unsere Software soll den Verwaltungsaufwand in FabLabs, Makerspaces, usw. vereinfachen und auch mit kleinem Personal verwaltbarhalten. Dabei wird auch die Idee eines FabLabs berücksichtigt, nach der jeder Zugriff auf die Resourcen eines Spaces bekommen soll. Wir möchten so für mehr FabLabs sorgen, damit es mehr Orte der Bildung gibt.
Ausführliche Darstellung der Ergebnisse
Welche konkreten Ergebnisse hast Du erzielt? Konnten alle Meilensteine erreicht werden?
Wir haben sehr an der technischen Realisierung eines SmartCards-Systems gehangen, mit dem man sicher und Space übergreifend arbeiten kann, dazu haben wir einen Proof-of-Concept erstellt und arbeiten derzeit an der Umsetzung in unser System. Durch die Corona Pandemie haben wir unseren Alpha-Test und die geplanten Beta-Tests nicht umsetzten können, da der Zugang zu den Räumlichkeiten nicht möglich war. Das hat auch die Umsetzung der Software in die Länge gezogen. Wir haben zum aktuellen Zeitpunkt eine Pre-Alpha Version unseres Servers, sowie eine grundlegende Version unseres Clients. Bei den beiden Softwarekomponenten ist sehr viel Arbeitsaufwand in die Strukturierung geflossen, um nach den Rückmeldungen des Alpha-Tests, sowie der Beta-Tests mit möglichst wenig Aufwand den Code anpassen, sowie zukünftige Features einzubauen zu können. Die Planung der Funktionen und deren Strukturierung liegen auch noch vor und werden nach dem Alpha-Test überarbeitet und veröffentlicht. Technische Grundlagen für die Föderationsmöglichkeit zwischen Serverinstanzen wurden gelegt, jedoch zeigte sich im Laufe der Entwicklung das verschiedene technische Ansätze evaluiert werden müssen, wodurch sich die vollständige Implementation und Testung der Föderationsmöglichkeit nach hinten verschob.
Welche zusätzlichen Erkenntnisse hast Du aus der Projektarbeit gewonnen, auch im Hinblick auf die Begleitung durch die Open Knowledge Foundation?
Infrastrukturzentrierte Software die für den Einsatz in Räumlichkeiten gedacht ist, stellte uns ohne Zugriff auf die Infrastruktur und Räumlichkeiten vor ungeplante Probleme, insbesondere bei der Testung und Fehlerbehebung.
Zielgruppe, Nutzen und mögliche Weiterentwicklungen
Welcher Nutzen ergibt sich für die Zielgruppe aus den Ergebnissen Deines Projekts?
Durch die große Visibilität die unser Projekt durch die Förderung und auch direkt duch die Internetauftritte des BMBF und Prototypefund erhalten hat, zentriert sich die weitere Entwicklung auf FabAccess, anstatt auf Lösungen einzeler Makerspaces und FabLabs. Dies ist auch insbesondere ein Vorteil, weil durch die Prototypenphase der weitere Entwicklungsaufwand und sinnvolle Entwicklungsansätze besser eingeschätzt werden können.
Welche weiter-gehenden Effekte ergeben sich aus der Open-Source-Stellung der Ergebnisse?
Die offene Entwicklung des Projektes ermöglicht Space übergreifend an einer gemeinsammen Lösung zuarbeiten. Somit muss nicht jeder Space für sich eine solche Software einwickeln, die dann nur auf die Probleme des jeweiligen Spaces ausgelegt ist. Da alle Spaces ähnliche Probleme haben kann so die Arbeitsleistung auf ein Projekt fokusiert werden, dadruch wird die Stabilität und Sicherheit einer solchen Software erheblich verbessert. Sollte das Projekt FabAccess von den meisten Spaces benutzt werden können auch Vorschläge an die Industrie herangetragen werden, um so die Verfügbarkeit von kompatiblen Hardware zu erhöhen. Dadurch wird es kleiner, neuen Spaces ermöglicht schnell einen Einstieg in ein sicheren Betrieb finden. Auch die Anbindung neuer Hardware(elektronische Schlossystem, Smarte Steckdosen, usw.) kann so durch Offenlegung der Schnittstellen schneller eingebunden werden und nicht jeder Space muss das für sich alleine entwicklen.
Gibt es Ideen für die Weiterentwicklung Deiner Lösung und Pläne zu deren Umsetzung?
Der aktuelle Stand des Projektes soll von dem Alpha-Test Phase in die nächsten Phasen getrieben werden. Auch die Föderationsumsetzung wird erfolgen. Wir haben uns auch mit anderenen Anwendungsmöglichkeiten für unseren Core umgeschaut und sind dahingehend in Gesprächen mit Lastenradverleihvereinen, da diese mit den Möglichkeiten unseres Cores im Prinzip auch verliehen werden können. Weitere Sharing basierte System sind auch möglich, solange ein elektronisch ansteuerbares Schloss verwendet wird oder die auszuleihende Dinge einen Inventaraufkleber besitzten. Dieses Prinzip des Teilens wird dabei durch die Föderationsprinzipen unterstützt.
Hat die Arbeit in dem Projekt Dich in Deiner persönlichen, fachlichen Weiterentwicklung unterstützt?
Wir hatte die Möglichkeit uns mit der GUI Entwicklung in Xamarin zubeschäftigen, sowie mit der Backend Entwicklung in Rust. Desweiteren konnten wir Erfahrungen mit den Build- und Veröffentlichungssystem verschiedener Platformen sammeln.
Kurze Darstellung der Arbeiten, die zu keiner Lösung geführt haben
Gab es Arbeiten bzw. Lösungsansätze, die nicht weiter verfolgt wurden?
Die Verwendung von Mifare Classic RFID-Karten wurde am Anfang implementiert, jedoch auch wieder früh beendet. Zudem gab es mehrere Ansätze zur Implementation der Förderation zwischen Serverinstanzen, unter anderem ein Ansatz basierend auf dem IETF-Standardprotokoll DIAMETER.
Was waren die Hintergründe, und wie bist Du alternativ vorgegangen?
Da Mifare Classic Karten über keinerlei Kopierschutz verfügt wurde stattdessen auf Mifare DESFire Karten umgestellt. Die starke Authentifizierung der Karte erlaubt eine sichere Kommunikation gegenüber einem föderiertem Server. Die Entwicklungen des Förderationsansätze basierend auf DIAMETER wurden wieder verworfen, da DIAMETER zwar große Vorteile bei zukünftigen Entwicklungen alternativer Server, die mit den vorhandenen Instanzen föderieren können, besitzt, jedoch kamen wir nach einer Kosten-Nutzen-Abwägung zum Schluss das der Aufwand durch Umstellung auf DIAMETER, insbesondere in einer Protypenphase, nicht von den Vorteilen gerechtfertigt war.
Kurze Angabe von Präsentationsmöglichkeiten für mögliche Nutzer
Wo können sich Interessenten detailliert über Deine Projektergebnisse informieren (z.B. Webseite, GHitHub, Veröffentlichungen)?
Im Rahmen der Prototypenphase wurde von uns ein Webauftritt erstellt, dieser ist unter der URL https://fab-access.org zu finden. Zusätzlich verwenden wir die offene Entwicklungsplattform GitLab für unseren Code. Fortschritte und Pläne in der Entwicklung, Anregungen und Probleme andere Parteien können dort unter https://gitlab.com/fabinfra/fabaccess alle eingesehen werden. Eine weiter Erläuterung der Ziele und den Desingentscheidungen haben wir in einem Vortrag auf dem rC3 in Form eines Vortrags zusammengefasst, zu finden unter https://media.ccc.de/v/rc3-326175-fabaccess.
Kurze Erläuterung zur Einhaltung der Arbeits- und Kostenplanung
Gab es im Projektverlauf Ereignisse, die eine Anpassung der Planung erforderlich machten – z.B. Mehr- oder Minderaufwand bei der Bearbeitung von Teilaufgaben?
Da Dokumentation der Mifare DESFire nur mit einem Geheimhaltungsvertrag und nur an Firmenkunden ausgegeben wird, konnten wir nur auf von dritten erstellte, oft unvollständige Unterlagen und Beschreibungen der DESFire Karten und des verwendeten Protokolls zugreifen. Dadurch verzögerte sich die Implementation des PoC der SmartCard-Anbindung erheblich.
Kurze Darstellung von etwaigen Ergebnissen bei anderen Stellen
Gab es Entwicklungen anderer Personen oder Institutionen, die Einfluss auf Deine Arbeiten und die Zielsetzung hatten?
Mehrere Makerspaces haben die Entwicklungen des Projektes verfolgt. Besonders anzumerken ist hier die Entwicklung eines Spacebetreibers an einem Hardwareprototypen für einen integrierten Kartenleser. Zeitgleich zu der Prototypefundförderung wurde auch ein Schweizer Team gefördert das in einigen Bereichen Überschneidungen mit FabAccess hat und darauf hin vorschlug Entwicklungszeit anstatt in ihre eigene Insellösung in FabAccess zu stecken.
Wenn ja, worin bestand dieser und wie bist Du damit umgegangen?
Unser Fokus konzentrierte sich auf die für uns entwickelte Schließhardwareplattform, während andere Plattformoptionen in den Hintergrund traten. Zudem wurden eigenständige Aufgabenpakete entwickelt, die externe Entwickler für uns übernehmen konnten. Desweiteren wurde ein Zulip-Kanal ins Leben gerufen um eine besser Koordination zwischen den Teams zu erreichen, und dieser dann auch genutzt um einen besseren Kontakt zur weiteren Community aufrecht zu erhalten.
19.02.2021 // Demoweek Webseitentext - Korrektur
tags: DemoWeek
FabAccess Projekt Thumbnail
Das Projekt
Wir entwickeln FabAccess, ein föderierbares Verwaltungssystem für FabLabs, Makerspaces und Hackerspaces. Mit FabAccess soll der Zugriff auf Maschinen verwaltet werden, um so Unfälle zu vermeiden.
Das Team
TODO: Teammitglieder verstellen
- Tasso: Product-Owner
- Gregor: Mädchen für alles, Backend
- Jannis: Design, Frontend
- Joseph: Frontend, Design
- Kai: Infrastruktur, Libraries
Das Problem
Viele Hacker und Maker haben sich schon mit der Herausforderung befasst, ein eigenes FabLab nach den Vorstellungen von Neil Gershenfeld aufzubauen und dieses mit wenig Personal "sicher" zu betreiben. Um das möglich zumachen, haben diese auch angefangen eine Verwaltungssoftware für ihre eigenen Spaces zu schreiben. Auch wir standen vor dieser Herausforderung: Wie kann man "gefährliche" Maschinen, wie unsere alte Drehbank, sicher betreiben? Gleichzeitig sollte natürlich die Idee des eigenständigen Lernens im FabLab erhalten bleiben, ohne dass ständig 20 Angestellte allen Nutzer:innen beim Umgang mit solchen Maschinen über die Schulter schauen müssen. Somit war die Idee für unser Projekt FabAccess geboren.
Aber das ist noch nicht alles, was FabAccess ausmacht. Aufgrund des sehr begrenzten Platzes in unserem Labor ist es uns nicht möglich, unseren Nutzer:innen jede Maschine zur Verfügung zu stellen. Wie können wir es unseren Nutzer:innen also ermöglichen, unkompliziert an andere Maschinen zu kommen, ohne unnötigen Mehraufwand bei kooperierenden Spaces zu erzeugen? Mit diesem Problem ergibt sich der zweite wichtige Aspekt von FabAccess: Es ist auch ein föderierbares Verwaltungssystem. Somit können sich Spaces aller Art zusammenschließen und die Nutzer:innen je nach Makerproblem den passenden Space besuchen. So wird die Kommunikation und Zusammenarbeit zwischen allen gestärkt. Aus Kommunikation entsteht bekanntlich Innovation.
Die Ausgangslage
Da wir Kommunikation fördern wollen, haben wir zu Beginn des Projektes auch genau dort angefangen. Um möglichst allen Bedürfnissen und Wünschen, die aus vielen Perspektiven an ein solches Verwaltungssystem gestellt werden, gerecht zu werden, haben wir uns auf FabLab- und Makerkonferenzen umgehört und sind aktiv auf die verschiedensten Creator (Nutzer:innen eines Spaces) und Manager (Betreiber:innen) solcher Spaces zugegangen. Mit diesen haben wir uns in kleinen und mittleren Runden zusammengesetzt, um alle Ideen zusammenzuschreiben.
Natürlich dachten wir uns schon, dass wir nicht die Ersten sind, die sich an ein solches Projekt wagen. Daher haben wir nach guter OpenSource-Arbeitsweise, nach eben solchen Projekten gesucht, gefragt und sind auch dort aktiv auf die Beteiligten zugegangen. Die Projekte waren auf den verschiedenesten Ständen, von einfachen Frontend-Designs bis hin zu lokal verwendeten Systemen. Um nicht auf dem Stand von "works for me" zu bleiben, haben wir uns mit den Entwickler:innen solcher Systeme getroffen und uns über die Umsetzung und "Lessons Learned" unterhalten, gechattet und offen diskutiert.
Die vielen Anregungen aus diesen Runden haben wir in einem Lastenheft kondensiert und festgehalten. Dieses Lastenheft bildet die Grundlage für unser Projekt, auch wenn wir in unserer Arbeitsweise nicht im klassischen Wasserfallmodell geblieben sind. Selbstverständlich haben wir flexibel und teilweise mit agilen Konzepten gearbeitet.
Da all diese Projekte nur lokal im Einsatz waren und wir einen föderativen Ansatz verfolgten (der "Verband offener Werkstätten" war an diesem Wunsch nicht ganz unbeteiligt), mussten wir dort gezielt ansetzen. Daraufhin haben wir uns auf die Förderung des Prototype Fund beworben, um uns in der Förderphase voll auf die Planung und Entwicklung dieses Projekts konzentrieren zu können.
Hier haben wir eine Liste von bekannten Projekten ähnlicher Zielrichtung zusammengefasst:
- Commons Booking
- Fab Lab Siegen (David Amend)
- Düsseldorf (Fabian Meyer)
- Beuth Hochschule für Technik Berlin
- ETH Zürich
- Übersicht beim Verband offener Werkstätten
- FabLab L'Aquila
- Google makerspace-auth
- Dresden (Roseguarden)
- FabLab München
- MakerSpace Graz ("LEASIE")
- Hackerspace Liege
- Flipdot e.V. Kassel
- CoreDump, Rapperswil-Jona / Schweiz
- open-taffeta
Die Umsetzung
Da wir zu unseren Features und Plänen schon ein paar kleine Vorträge gehalten haben sowie vieles auf unserer Webseite niedergeschrieben ist, verlinken wir an dieser Stelle dorthin. Schaut es euch gerne an.
FabAccess Feature Beschreibung: fab-access.org
FabAccess Feature- und Planungsvortrag vom rC3: media.ccc.de
Folien vom rC3 Vortrag: docs.google.com
tl;dr: FabAccess besitzt drei Hauptfunktionalitäten:
- Maschinenverwaltung
- Berechtigungssystem
- Nutzer:innenverwaltung
Das Prinzip von FabAccess ist es, Maschinen über den Stromanschluss ein- und auszuschalten. So sind Maschinen im Normalfall stromlos und damit ungefährlich. Erst wenn Nutzer:innen an der Maschine sind, die für die sichere Bedienung befähigt und eingewiesen sind, wird die Maschine mit dem Stromnetz verbunden.
Tooling
Jedes Team braucht ein sinnvolles Tooling, die Frage ist nur, was heißt "sinnvoll"? Der Ansatz für unser Tooling basiert, wie bei den meisten Projekten, auf den vorhandenen Fähigkeiten der Entwickler:innen. Um einen möglichst stabilen Core zu entwickeln, wird unser Server in Rust entwickelt, da wir einen sehr guten Rustentwickler an Bord haben. Die Sprache ist auch gut für die Entwicklung stabiler Backends geeignet, weil viele Programmierfehler schon durch den relativ intelligenten Compiler verhindert werden.
Für das Frontend war es die "Wahl der Qual": Welche Plattformen will man unterstützen und mit welchem Framework kann man unsere Ideen überhaupt umsetzen? Unsere Wahl ist aufgrund der kurzen Förderphase auf C# mit Xamarin gefallen, da einer von uns schon etwas Erfahrung mit WPF-Entwicklung hatte und sich mit Hilfe von Xamarin ein Client gut auf fast alle Plattformen portieren lässt.
Für eine funktionierende und langfristige Föderation benötigten wir eine stabile API, über die die einzelnen Instanzen und Clients mit unserem Server(BFFH - Diflouroborane) kommunizieren können. Auch eine Abwärtskompatibilität ist sinnvoll, wenn BFFH von einzelnen Spaces auf deren Bedürfnisse angepasst werden können soll. Dabei sollte unser Referenzclient (Borepin) nicht funktionsunfähig werden. Um all dies möglich zu machen, ist unsere API in Cap'n Proto geschrieben.
Struktur von FabAccess, mit Schnittstellenaufteilung
Erweiterungen
Dieses Thema war bei Gesprächen mit den anderen Spaces immer vorne mit dabei, da keiner der Spaces seine selbst gebaute Hardware neu bauen will oder teuer eingekaufte Systeme verlieren möchte. Um das möglich zu machen, haben wir eine API geplant, die generisch genug ist, um verschiedenste Systeme anzubinden. Damit nicht jeder Space seine Hardware selbst basteln muss und damit zum Entwickeln eigener Software gezwungen wird, entwickeln wir von unserer Seite aus passende Referenzhardware, um den Einstieg zu erleichtern. Um die kommerziellen Produkte nicht außer acht zu lassen, arbeiten wir an der Einbindung der gängigsten Geräte, wie Shelly Plugs oder Systemen mit Tasmota und anderen. Somit kann sich ein Space beim Verwenden unseres Systems entweder unserer Bastelaufgabe stellen oder einen schnellen Einstieg durch gekaufte Produkte hinlegen.
Hardware
Hardware zur Anbindung an die Geräte wurde uns unter anderem von einem sehr engagierten Unterstützer zur Verfügung gestellt. Vielen Dank an dieser Stelle an Joris, der für uns den ersten Prototypen eines SmartCard-Readers entwickelt hat, der sich schon wunderbar an unsere Schnittstellen anbindet.
Drehbank mit ursprünglichem Schaltungsprototypen
Föderation
Nachdem wir die ganze Zeit von Föderation reden und schreiben, wollen wir auch die Frage klären, was Föderation für uns ist. Wir haben unseren Ansatz wie folgt definiert:
Föderation ist eine Form von Zusammenarbeit von Organisationen. Die Organisationen behalten dabei ihre Eigenständigkeit und arbeiten gleichberechtigt und weitgehend autonom bei der Erreichung gemeinsamer Ziele zusammen.
Unser gemeinsames Ziel mit FabAccess ist das niederschwellige und unkomplizierte Teilen von Nutzer:innen und somit die Verbesserung der Zusammenarbeit von Creatoren über Spacegrenzen hinweg sowie die gleichberechtigte Zusammenarbeit von Managern.
Unser Ansatz kann in der Realität wie folgt aussehen: Creator aus Space A geht zu Space B und kann dort mit der Einweisung für eine Maschine aus Space A die gleiche Maschine in Space B verwenden, ohne eine weitere Einweisung zu benötigen.
Wir haben gesammelt und wissen, was die meisten anderen Projekte machen und gemacht haben, zumindest innerhalb einer einzelnen Werkstatt. Allerdings gibt es verschiedene Dach-Organisationen, die diese Werkstätten als Verband gemeinsam vertreten. Um föderieren zu können, brauchen wir einen Standard, den alle nutzen können. Das können eine stabile API-Beschreibung und stabile Strukturen sein, die von den einzelnen Teilnehmenden abwärtskompatibel erweitert werden können, ohne dass die ursprünglich implementierte Föderation gestört wird.
Um nicht auf eine spezielle Hardware angewiesen zu sein, braucht es generische Schnittstellen, die komplexe und einfache Hardware unterstützen. Sicherheitsanforderungen sollen vorerst, so weit das geht, bei den Anwender:innen bleiben und nicht auf uns zurückfallen.
Was wir können (wollen): Ein sicheres und stabiles Berechtigungssystem bieten, das die notwendige Kommunikation realisiert und Events an generische Schnittstellen geben kann. Das System soll dabei granuliert und anwendungsorientiert Entscheidungen weitergeben. Weiterhin soll es den Anwender:innen dienen und dabei nicht in deren Prozesse eingreifen oder ihnen ungewollte Komplexität oder Strukturen aufzwingen oder gar in deren Entscheidungen einwirken.
Außerdem wollen wir, dass unter den einzelnen Instanzen gemeinsame Entscheidungen mit Föderation getroffen werden können, ohne dass die einzelnen Parteien ihre Rechte verlieren.
SmartCards
Um Maschinen sicher mit einer SmartCard aktivieren zu können und nicht nur über ein Handy oder einen PC, setzten wir auf NXP MIFARE DESFire Karten. Die Anforderungen an ein föderierbar einsetzbares SmartCard-System sind hoch, da so die jeweils andere Partei keine einfache Validierung der Karte durchführen kann. Auch das Authentifizieren mit einem Schlüssel gestaltet sich über Föderationen hinweg schwierig, da der Reader dem einen Space gehört und die Karte dem anderen. Ein Reader hat daher nicht immer die Schlüssel für die gelesenen Karten. Die DESFire-Karte besitzt ein Feature, mit dem eine Karte via OTA-Verfahren (Over-the-Air) direkt mit einem entfernten Server kommunizieren kann, ohne dass der Reader Schlüssel für die Karte benötigt. Der Reader übernimmt dabei nur die Rolle eines Proxys (Brücke/Vermittler). Mit diesem Ansatz stellen wir ein sicher föderierbares Kartensystem, was wir so bisher noch nicht im OpenSource-Bereich finden konnten.
Die Herausforderungen
Auch wir standen während der Umsetzung vor einigen Herausforderungen, die Schwierigsten haben wir mal niedergeschrieben.
Aller Anfang ist schwer
Da unser Projekt viele Aspekte und eine hohe Komplexität besitzt, war das Auswählen schwierig. Wir konnten nicht direkt einzelne Features separat bauen, da der Core erst implementiert werden musste, bevor wir mit solchen Funktionalitäten beginnen konnten. Auf der Core-Seite begannen wir mit dem Aufbau eines Event-Netzwerks und der Anbindung von einem MQTT Server sowie dem Aufbau der Datenbankstrukturen. Auf der Client-Seite war die Auswahl für unabhängige Aufgaben begrenzt, da die Funktionalität im Core und über die Cap'n Proto API abgebildet wird. Daher stürzten wir uns auf die Implementierung von dem SmartCard Proof-of-Concept und der Anbindung der Cap'n Proto API.
UX und NFC
In unserem ersten Coaching mit Simply Secure stellten wir unseren ersten Designentwurf für Borepin vor. Bei diesem Gespräch wurde angesprochen, dass wir ein Wiedererkennungsmerkmal für eine NFC-Interaktion kreieren sollten, um so Nutzer:innen eine einfache Erkennung von NFC-Tags oder Karten bereitzustellen. Daraufhin ist unser Design für eine NFC-Markierung entstanden.
SmartCard und Maschinensticker im FabAccess NFC Design
Föderation und Netzwerke
Bei der Föderationsplanung und -entwicklung hatten wir ein paar ungeklärte Fragen zu beantworten. Da unser langfristiges Ziel ist, über eine Föderation auch eine Abrechnung zu ermöglichen, sollten die Föderationsabläufe sicher und nachvollziehbar für beide Parteien sein. Da Föderation für beide Seiten einen erkennbaren Vorteil mit sich bringen muss, ist unsere Planung bisher nur eine direkte Föderation zu erlauben. Somit föderieren nur Spaces miteinander, deren Manager sich kennen und zusammenarbeiten wollen. Es ist keine Netzwerkbildung möglich, bei der ein Zusammenschluss von Spaces entsteht, bei dem ein neuer Space direkt Zugriff auf alle Spaces erhält, ohne diese selbstständig und gegenseitig zu akzeptieren.
Community
Bei Thema Community und Unterstützer:innen netzwerken wir nun schon seit über zwei Jahren für diese Projektidee und haben uns auch in Laufe der Förderung um eine Veröffentlichung unserer Fortschritte bemüht.
Um unsere Kommunikation für die Entwicklung des Projekts nicht in privaten Chatgruppe zuführen, haben wir uns für die Open Source Software Zulip entschieden und sind dort für neue und alte Interessierte und Unterstützer:innen leicht erreichbar. Das Threading ist in Zulip für ein solches Projekt ideal.
Durch die Verbindung unserer Teammitglieder zum Chaosumfeld haben wir unseren ersten Vortrag beim Chaostreff Potsdam Anfang Dezember gehalten. In diesem konnten wir unser Projekt vorstellen und die ersten Erkenntnisse und Planungen vorstellen. Vielen Dank an dieser Stelle an den Chaostreff Potsdam für diese Gelegenheit.
Da es nun schon fast Tradition ist, auf dem Chaos Communication Congress eine kleine Gesprächsrunde rund um das Thema FabLab zuführen, haben wir uns für eine digitale Gesprächsrunde auf dem rC3 entschieden. Durch diesen Talk konnten wir unserem Projekt zu mehr Öffentlichkeit verhelfen. Auch die Make hat uns darauf hin in einem ihrer Online-Artikel erwähnt sowie ein Beitrag in der aktuellen Ausgabe veröffentlicht. Dieses mediale Interesse sowie die Rückmeldungen haben uns gezeigt, dass wir auf einem guten Weg sind und unser Projekt etwas verändern könnte.
Der Stand
Wie leider so oft in durchgeplanten Projekten haben wir nicht alle Ziele schon am Ende des Förderzeitraums erreicht.
Wir haben, wie ihr im Video sehen könnt, einen Prototypen, der die Maschinen einschalten kann.
Das SmartCard-System haben wir bisher nur als Code Libraries und Proof-of-Concept vorliegen, es muss noch in den Core eingearbeitet werden.
Wir haben eine erste Version der API am Anfang des Projektes definiert, welche grundlegende Funktionen beinhaltet, die wir zu diesem Zeitpunkt schon festlegen konnten. Wir arbeiten gerade an einer verbesserten Version, in die unsere jetzigen Kenntnisse und zukünftigen Wünsche einfließen, um bald einen stabilen Stand bieten zu können. Auch die einzelnen Subsysteme, die wir definiert haben, werden jetzt dort eingearbeitet.
Auf der Seite des Clients gibt es noch einige Bugs zu fixen, um unseren Cap'n Proto Code auf allen Plattformen ausführen zu können. Auch müssen wir unsere Designs noch in den Client einbauen. Das ist der nächste Schritt nach der API-Verbesserung.
Auch muss unsere komplette Planung noch genauer aufgeschrieben werden und unsere Konzeptentscheidungen festgehalten werden.
Für die Föderierbarkeit müssen noch ein paar Umsetzungsentscheidungen getroffen werden, dass wir dann auch alles in die API einfließen lassen können.
Wie ihr seht, haben wir noch einiges zu tun.
Die Zukunft
Die gute Nachricht ist: Wir machen weiter.
Wir arbeiten an einer Strategie zur weiteren Förderung unseres Föderationskonzepts, um es gemeinsam mit dem Verband offener Werkstätten und dem Fab:Universe-Netzwerk fertigstellen zu können und ab der zweiten Hälfte des Jahres ein größeres Roll-out angehen zu können.
Auch wollen wir in einem Machbarkeitstest unseren Core (BFFH) erweitern und so testen, ob wir auch andere Anwendungen wie z. B. ein Netzwerk aus Lastenfahrradverleihen mit unserem System unterstützen können. Unser offener und generischer Ansatz scheint sich auszuzahlen.
Föderationsablaufbeispiel von FabAccess/DEMOKrAtIS DEMOKrAtIS ist der Projektname des Machbarkeitsprojektes
Mit unseren Verbündeten aus der Schweiz werden wir auch weiter zusammenarbeiten und bekommen mit etwas Glück aus der Richtung auch noch zwei Entwickler:innen als Unterstützung.
Auch an der Hardwarefront wird weiter getüftelt, mit unserem Unterstützer wollen wir eine neue Version des Readers erarbeiten, die wir als OpenHardware und als Bausatz bereitstellen wollen.
Für das Abrechnungssystem sind wir noch auf der Suche nach einem Partner, mit dem wir als Open-Source-Lösung den FabLabs, Makerspaces und Hackerspaces bei der Abrechnung von Leistungen helfen können.
Wie ihr sehen könnt, haben wir noch einige Ideen und Visionen, an denen wir arbeiten können. Und wir bleiben unserem Motto vom Kick-off der Förderphase treu: "3 Billion Devices run FabAccess".
Für alle, die noch schöne Ideen für unser Projekt haben oder uns bei der Umsetzung (auch bei unseren anderen Fab... Projekten) helfen wollen, können wir nur sagen, kommt auf unser Zulip, wir machen was Schönes draus.
Ein kleines Fazit
Zum Projekt
Wir setzten mit diesem Projekt unseren Wunsch nach einer zusammenarbeitenden Open-Source-Gesellschaft um.
Wir haben mehr Zeit in einige Aufgaben gesteckt, als wir erwartet und geplant hatten. Mit den Ergebnissen können wir aber zufrieden sein. Wir sind unserem Ziel und der ursprünglichen Idee ein großes Stück näher gekommen.
Wir müssen aber auch zugeben, dass wir an unserem Teammanagment arbeiten müssen: Die nicht vollsynchrone Arbeitsweise mit nur wenigen persönlichen Treffen in der Gruppe bringt einige Schwierigkeiten mit sich und kann schnell zu Spannungen führen.
Zur Prototype-Fund-Förderung
Die Förderung durch den Prototype Fund hat unserem Projekt einen riesigen Sprung nach vorne ermöglicht. Ohne die Möglichkeit, viel Zeit in Planung und Entwicklung stecken zu können und dabei trotzdem unseren diversen finanziellen Verpflichtungen nachkommen zu können, wären wir nie in dem halben Jahr auf das Level gekommen, auf dem wir jetzt sind.
Die Organisation vom Prototype Fund ist gut, wir würden uns aber noch mehr Unterstützung bei den steuerlichen und finanziellen Aspekten der Förderung wünschen. Die Coachings waren sehr hilfreich für die Design-Entscheidungen, für die wir auch schon viel Lob bekommen haben, vielen Dank an Eileen und Simply Secure an dieser Stelle.
Da wir für unser Projekt auch Hardware benötigten, hätten wir uns über die Möglichkeit einer Föderung der Arbeit an zum Beispiel der Hardware eines SmartCard-Readers gefreut.
Wir hoffen, dass das BMBF auch in Zukunft solche Civic Tech Projekte unterstützt und so einen Startboost gibt.
Vielen Dank auch an die Teams von Prototype Fund, DLR und des BMBF für die Planung und Unterstützung im Rahmen dieser Förderung.
12.02.2021 // DemoWeek: Videoskript
tags: DemoWeek
Idee
Demo, das es geht. Alle anderen Infos sind im Blogtext oder auf unserer Webseite
Das ganze wird aus einer Persektive gedreht, in der das Team neben der Fräse steht. Alle anderen Ansichten sollen über Einblendungen erfolgen, so dass diese als kleine Unterstützung zu dem gesagtem dienen.
Ablaufplan
Aktion | Kommentar | |
---|---|---|
0 | Vorstellung Team | Vorstellung der Team Mitglieder |
1 | Team vor der Drehbank | Vorstellung was ist FabAccess |
2 | Team vor der Drehbank | Warum Fabaccess + Zeige gefährliche Drehbank |
3 | ("Eine Hand" demonstriert Drehbank einschalten) | |
4 | Einblendung ESP Schütz | Lösung ESP Schütz, nur keine Software zum Ansteueren |
5 | Demo App einschalten der Drehbank | Auswählen der Maschine in der App und nutzten, dann Drehbank einschalten |
6 | Demo Shelly einschalten | Lampe(Maschine) in der App auswählen und einschalten Generik erklären |
7 | Ausblick SmartCard (Einblendung) | SmartCard und Reader einblenden, Einschalten über SmartCard möglich |
8 | Ausblick Föderation | Nutzer aus anderen Spaces können auch dieses System nutzten ohne großen Aufwand, mit Berechtigungsteilen |
9 | Abspann | Abspann |
Texte
Aktion 0 - Vorstellung (0:00 - Start Timestamp)
Einfache kurze Vorstellung der Protagonisten und des FabInfra Teams.
Aktion 1 - Was ist FabAccess? (0:20)
FabAccess ist ein föderierbares Verwaltungssystem für FabLabs, Makerspaces und Hackerspaces. Mit FabAccess soll der Zugriff auf Maschinen verwaltet werden können, um so Unfälle zu vermeiden. Das Ziel ist es, mehr Sicherheit in die Abläufe eines offen und niederschwellig gestalteten Werkstattbetriebs zu bringen.
Aktion 2 - Warum benötigt man FabAccess? (0:30)
Eine Drehbank ohne Anlaufschutz und nur mit einem einfachen Einschalter stellt ein sehr großes Sicherheitsrisiko dar. Um so uneingewiesenen Nutzern die Gefahr wegen Unwissenheit um die Drehbank gewickelt zu werden (und weitere Risiken im Werkstattbetrieb) zu ersparen benötigen Nutzer vorher eine Einweisung für Maschinen von denen auch im Normalbetrieb unvermeidbare Rest-Gefahren ausgehen. Die Maschinen sind nach einer Einweisung exakt so gefährlich wie vorher, die Nutzer kennen aber die Gefahren und können dadurch damit umgehen.
Aktion 3 - Drehbank einschalten (1:00)
Knopf zeigen (Wirklich nur eine Knopf) - Strudeleffekt (wenn's nicht Sch... aussieht)
Aktion 4 - ESP-Schütz (Historie - evtl. kürzen) (1:05)
Einschalten mit OpenHAB aus dem Büro ohne Wiederanlaufschutz .. ebenfalls riskant.
Aktion 5 - Demo Drehbank mit Wiederanlaufschutz über App einschalten (1:10)
Da FabAccess nur den Personen die berechtigt sind, also eingewiesen, erlaubt Maschinen zu benutzten, können auch nur diese Personen solche Maschinen einschalten. (Maschine in der App auswählen und auf Use klicken) -> Drehbank einschalten
Aktion 6 - Demo-Shelly einschalten (1:30)
Da FabAccess eine generische Schnittstelle bietet um solche Aktoren, wie den ESP32, anzubinden könnnen auch andere Geräte verwendet werden, wie diesen Shelly Plug hier.
- 6a Der einfach nur an eine Lampe angeschlossen ist. (Maschine in der App auswählen und auf Use klicken) -> Licht geht an
- 6b FabAccess kann auch komplexere Dinge steuern --> Hue-Lamp.
Aktion 7 - SmartCard (1:50)
Um im Makeralltag nicht immer sein Handy zu benötigen, bietet FabAccess eine SmartCard-Anbindung, durch die das Einschalten der Maschinen auch mit einer DESFire Karte und einem Reader erfolgen kann. Anbindung an QR-Code-Systeme ist auch möglich.
Aktion 8 - Föderation (2:10)
Um die Zusammenarbeit von Spaces zu unterstützen und zu fördern ist FabAccess föderierbar, so können Nutzer zwischen den Spaces hin und her wechseln ohne jedes mal neu in eine Maschine eingewiesen zu werden.
Abspann (2:30)
FabInfra-Team .. und (Mention/Props für) alle die an Vor- oder Parallel-Projekten gearbeitet haben (Joris/Marcio/Kevin/Faaabi/ .. wenn sie nichts dagegen haben).
Grün: #00d4aa 0 212 170 Hintergrund: #3c474d Grau: #adadad 173 173 173
Abstann Text
Das FabAccess Team: Jannis Rieger Tasso Mulzer Kai Kriegel Gregor Reitzenstein Joseph Langosch
Besonderer Dank an unsere Unterstützer:innen für das Projekt: Joris Bijkerk Maximilian Voigt Fabian Meyer Marcus Drobisch Kevin Krechan Marcio Ferreira dos Santos Timm Wille Thee Vanichangkul MrHat2010
und an das Kamerateam: fa
(Reihenfolge ungefähr so .. oder einfach alphabetisch)
12.02.2021 // Demoweek: Webseitentext
tags: DemoWeek
Ihr veröffentlicht einen Text über das Ziel, die Entstehung und andere interessante Aspekte eures Projekts oder Erkenntnisse aus der Förderphase.
FabAccess Projekt Thumbnail
Das Projekt
Wir entwickeln FabAccess, ein föderierbares Verwaltungssystem für FabLabs, Makerspaces und Hackerspaces. Mit FabAccess soll der Zugriff auf Maschinen verwaltet werden, um so Unfälle zu vermeiden.
Das Team
TODO: Teammitglieder verstellen
Das Problem
Viele Hacker und Maker haben sich schon mit der Herausforderung befasst ein eigenes FabLab nach den Vorstellungen von Neil Gershenfeld aufzubauen und dieses mit wenig Personal "sicher" zu betreiben. Um das möglich zumachen haben diese auch angefangen eine Verwaltungssoftware für ihre eigenen Spaces zu schreiben. Auch wir standen vor der Herausforderung: Wie kann man "gefährliche" Maschinen, wie unsere alte Drehbank, sicher betreiben? Gleichzeitig sollte natürlich die Idee des eigenständigen Lernens im FabLab erhalten bleiben, ohne dass ständig 20 Angestellte Jedem beim Umgang mit solchen Maschinen über die Schulter schauen müssen. Somit war die Idee für unsere Projekt FabAccess geboren.
Aber das ist noch nicht alles was FabAccess ausmacht. Durch den doch sehr begrenzten Platz in unserem Labor ist es uns nicht möglich jede Maschine unseren Nutzern zur Verfügung stellen zu können. Wie können wir es also unseren Nutzern ermöglichen, unkompliziert an andere Maschinen zu kommen und gleichzeitig so wenig wie möglich Mehraufwand bei kooperierenden Spaces zu erzeugen. Mit diesem Problem ergibt sich der zweite wichtige Aspekt von FabAccess, denn FabAccess ist ein föderierbares Verwaltungssystem. Somit können sich Spaces aller Art zusammenschließen und die Nutzer können je nach Makerproblem den passenden Space besuchen. So wird die Kommunikation und Zusammenarbeit zwischen allen gestärkt. Aus Kommunikation entsteht bekanntlich Innovation.
Die Ausgangslage
Da wir Kommunikation fördern wollen, haben wir zu Beginn des Projektes auch genau dort angefangen. Um möglichst allen Bedürfnissen und Wünschen, die aus vielen Perspektiven an ein solches Verwaltungssystem gestellt werden, gerecht zu werden, haben wir uns auf FabLab- und Makerkonferenzen umgehört und sind aktiv auf die verschiedensten Creator(Nutzer eines Spaces) und Manager(Betreiber eines Spaces) solcher Spaces zugegangen. Mit diesen gemeinsam haben wir uns in kleinen und mittleren Runden zusammengesetzt, um all die Ideen zusammenzuschreiben.
Natürlich dachten wir uns schon, dass wir nicht die Ersten sind, die sich an ein solches Projekt wagen. Daher haben wir nach guter OpenSource-Arbeitsweise, nach solchen Projekten gesucht, gefragt und sind auch dort aktiv auf die Beteiligten zugegangen. Die Projekte waren auf den verschiedenesten Ständen, von einfachen Frontend-Designs bis hin zu lokal verwendeten Systemen. Um nicht auf dem Stand von "works for me" zu bleiben, haben wir uns mit den Entwicklern solcher Systeme getroffen und uns über die Umsetzung und "Lessons Learned" unterhalten, gechattet, gemeetet und offen diskutiert.
Die vielen Anregungen aus diesen Runden haben wir in einem Lastenheft kondensiert und festgehalten. Dieses Lastenheft bildet die Grundlage für unser Projekt, auch wenn wir in unserer Arbeitsweise nicht im klassischen Wasserfallmodell geblieben sind. Selbstverständlich haben wir flexibel und teilweise mit agilen Konzepten gearbeitet haben.
Da all diese Projekte nur lokal im Einsatz waren und wir einen föderativen Ansatz verfolgten (der "Verband offener Werkstätten" war an diesem Wunsch nicht ganz unbeteiligt) mussten wir dort gezielt ansetzen. Daraufhin haben wir uns auf die Förderung des Prototype Fund beworben, um uns in der Förderphase voll auf die Planung und Entwicklung dieses Projekts konzentrieren zu können.
Liste von bekannten Projekten ähnlicher Zielrichtung:
- Commons Booking
- Fab Lab Siegen (David Amend)
- Düsseldorf (Fabian Meyer)
- Beuth Hochschule für Technik Berlin
- ETH Zürich
- Übersicht beim Verband offener Werkstätten
- FabLab L'Aquila
- Google makerspace-auth
- Dresden (Roseguarden)
- FabLab München
- MakerSpace Graz ("LEASIE")
- Hackerspace Liege
- Flipdot e.V. Kassel
- CoreDump, Rapperswil-Jona / Schweiz
- open-taffeta
Die Umsetzung
Da wir zu unseren Features und Plänen schon ein paar kleine Vorträge gehalten haben, sowie vieles auf unserer Webseite niedergeschrieben ist, verlinken wir an dieser Stelle dorthin. Schaut es euch gerne an.
FabAccess Feature Beschreibung: fab-access.org
FabAccess Feature- und Planungsvortrag vom rC3: media.ccc.de
Folien vom rC3 Vortrag: docs.google.com
tl;dr: FabAccess besitzt drei Hauptfunktionalitäten:
- Maschinenverwaltung
- Berechtigungssystem
- Nutzerverwaltung
Das Prinzip von FabAccess ist es, Maschinen über den Stromanschluss ein- und auszuschalten. So sind Maschinen im Normalfall stromlos und damit ungefährlich. Erst wenn Nutzer an der Maschine sind, die für die sichere Bedienung befähigt und eingewiesen sind, wird die Maschine mit dem Stromnetz verbunden.
Warning Wir werden in dem weiteren Text mehr auf die Projektumsetzung und die Prototype Fund Förderung eingehen, da wir die Features schon ausführlicher und besser in den Beiträgen erklärt haben.
Tooling
Jedes Team braucht ein sinnvolles Tooling, die Frage ist nur, was heißt "sinnvoll"? (yeah!! - Tooldiskussionen!!) Der Ansatz für unser Tooling basiert, wie bei den meisten Projekten, auf den vorhandenen Fähigkeiten der Entwickler. Um einen möglichst stabilen Core zu entwickeln wird unsere Server in Rust entwickelt, da wir einen sehr guten Rustentwickler an Bord haben. Die Sprache ist auch gut für die Entwicklung stabiler Backends geeignet, weil viele Programmierfehler schon durch den relativ intelligenten Compiler verhindert werden.
Für das Frontend war es die "Wahl der Qual", welche Plattformen will man unterstützen und mit welchem Framework kann man unsere Ideen überhaupt umsetzen. Unsere Wahl ist aufgrund der kurzen Förderphase auf C# mit Xamarin gefallen, da einer von uns schon etwas Erfahrung mit WPF-Entwicklung hatte und sich mit Hilfe von Xamarin ein Client gut auf fast alle Plattformen portieren lässt.
Für eine funktionierende und langfristige Föderation benötigten wir eine stabile API, über die die einzelnen Instanzen und Clients mit unserem Server(BFFH - Diflouroborane) kommunizieren können. Auch eine Abwärtskompatibilität ist sinnvoll, wenn BFFH von einzelnen Spaces auf deren Bedürfnisse angepasst werden können soll. Dabei sollte unser Referenzclient (Borepin) nicht funktionsunfähig werden. Um all dies möglich zu machen, ist unsere API in Cap'n Proto geschrieben.
Struktur von FabAccess, mit Schnittstellenaufteilung
Erweiterungen
Dieses Thema war bei Gesprächen mit den anderen Spaces immer vorne mit dabei, da keiner der Spaces seine selbst gebaute Hardware neu bauen will oder teuer eingekaufte Systeme verlieren möchte. Um das möglich zu machen, haben wir eine API geplant, die generisch genug ist um verschiedenste Systeme anzubinden. Damit nicht jeder Space seine Hardware selbst basteln muss und damit zum Entwickeln eigener Software gezwungen wird, entwickeln wir von unserer Seite aus passende Referenzhardware um den Einstig zu erleichtern. Um die kommerziellen Produkte nicht außer Acht zu lassen, arbeiten wir an der Einbindung der gängigsten Geräte, wie Shelly Plugs oder Systeme mit Tasmota und anderen. Somit kann sich ein Space beim Verwenden unseres Systems entweder unserer Bastelaufgabe stellen oder einen schnellen Einstieg durch gekaufte Produkte hinlegen.
Hardware
An der Hardware haben wir durch die Bindung der Förderung leider nicht so viel arbeiten können, aber wir haben einen sehr engagierten Unterstützter gefunden (Vielen Dank an dieser Stelle an Joris), der für uns den ersten Prototypen eines SmartCard-Readers entwickelt hat, der sich schon wunderbar an unsere Schnittstellen anbindet. Für weitere Hardware zum Schalten haben wir schon vor der Förderphase eine Gruppe aus der Schweiz gefunden, die mit uns bei diesem Vorhaben zusammenarbeitet.
Also erstmal noch ein kleines "coming soon".
Drehbank mit erstem Schaltungsprototypen
SmartCards
Einen SmartCard-Reader benötigen wir durch den Wunsch Maschinen mit einer SmartCard zu aktivieren und nicht nur über ein Handy oder einen PC. Dieses Feature war bei der Planung nicht vollständig in seiner Komplexität zu erfassen. Es gibt einige gute Open Source Libraries, mit denen sich so gut wie alle auf dem Markt befindlichen SmartCards lesen und beschreiben lassen. Die Frage, die wir uns in diesem Zusammenhang stellen mussten war, welche der Karten unterstützen wir und was sind unsere Anforderungen an eine SmartCard. In einem anderen Projekt werden NXP MIFARE Classic Karten verwendet. Da diese schon seit über 10 Jahren keinen ernstzunehmenden Schutz mehr gegen Clonen der Karten bieten, haben wir uns gegen eine solche Lösung entschieden. Die Anforderungen an ein föderierbar einsetzbares SmartCard-System sind hoch, da so die jeweils andere Partei keine einfache Validierung der Karte durchführen kann. Auch das Authentifizieren mit einem Schlüssel gestaltet sich über Föderationen hinweg schwierig, da der Reader dem einen Space gehört und die Karte dem anderen. Ein Reader hat daher nicht immer die Schlüssel für die gelesenen Karten. Um das valide und nutzbar umzusetzen haben wir uns für eine kostengünstige Lösung, mit NXP Mifare DESFire Karten entschieden. Die Karte besitzt das Feature, dass sie OTA (Over-the-Air) mit entfernten Servern kommunizieren kann. Somit kann zwischen der Karte und dem Server direkt verschlüsselt kommunziert werden und der Reader spielt nur Proxy. Mit diesem Ansatz stellen wir ein sicher föderierbares Kartensystem, was wir so bisher noch nicht im OpenSource-Bereich finden konnten.
Föderation
Nachdem wir die ganze Zeit von Föderation reden und schreiben wollen wir auch die Frage klären, was Föderation für uns ist. Wir haben unseren Ansatz wie folgt definiert:
Föderation ist eine Form von Zusammenarbeit von Organisationen. Die Organisationen behalten dabei ihre Eigenständigkeit und arbeiten gleichberechtigt und weitgehend autonom bei der Erreichung gemeinsamer Ziele zusammen.
Unser gemeinsames Ziel mit FabAccess ist das niederschwellige und unkomplizierte Teilen von Nutzern und somit die Verbesserung der Zusammenarbeit von Creatoren über Spacegrenzen hinweg, sowie die gleichberechtigte Zusammenarbeit von Managern.
Unser Ansatz kann in der Realität wie folgt aussehen: Creator aus Space A geht zu Space B und kann dort mit der Einweisung für eine Maschine aus Space A die gleiche Maschine in Space B verwenden, ohne eine weitere Einweisung zu benötigen.
Wir haben gesammelt und wissen was die meisten anderen Projekte machen und gemacht haben. Zumindest innerhalb einer einzelnen Werkstatt. Allerdings gibt es verschiedene Dach-Organisationen, die diese Werkstätten als Verband gemeinsam vertreten. Um föderieren zu können brauchen wir einen Standard, den alle nutzen können. Also eine stabile API-Beschreibung und stabile Strukturen, die von den einzelnen Teilnehmern abwärtskompatibel erweitert werden können, ohne dass die ursprünglich implementierte Föderation gestört wird.
Um nicht auf eine spezielle Hardware angewiesen zu sein braucht es generische Schnittstellen, die komplexe und einfache Hardware unterstützen. Sicherheitsanforderungen sollen vorerst so weit das geht beim Anwender bleiben und nicht auf uns zurückfallen.
Was wir können (können wollen): Ein sicheres und stabiles Berechtigungssystem bieten, das die notwendige Kommunikation realisiert und Events an generische Schnittstellen geben kann. Das System soll dabei granuliert und anwenderorientiert Entscheidungen weitergeben. Weiterhin soll es den Anwendern dienen und dabei nicht in deren Prozesse eingreifen oder ihnen ungewollte Komplexität oder Strukturen aufzwingen, oder gar in deren Entscheidungen einwirken.
Und dass unter den einzelnen Instanzen gemeinsame Entscheidungen mit Föderation getroffen werden können, ohne dass die einzelnen Parteien ihre Rechte verlieren.
Die Herausforderungen
Auch wir standen während der Umsetzung vor einigen Herausforderungen, die Schwierigsten haben wir mal niedergeschrieben.
Aller Anfang ist schwer
Da unser Projekt viele Aspekte und eine hohe Komplexität besitzt war das Auswählen schwierig. Wir konnten nicht direkt einzelene Features seperat bauen, da der Core erst implementiert werden musste, bevor wir mit solchen Funktionalitäten beginnen konnten. Auf der Core-Seite begannen wir mit dem Aufbau eines Event-Netzwerks und der Anbindung von einem MQTT Server, sowie dem Aufbau der Datenbankstrukturen. Auf der Client-Seite war die Auswahl für unabhängige Aufgaben begrenzt, da die Funktionalität im Core und über die Cap'n Proto API abgebildet wird. Daher stürzten wir uns auf die Implenetierung von dem SmartCard Proof-of-Concept und der Anbindung der Cap'n Proto API.
Closed Source SmartCards
Die Möglichkeit für ein OTA-Verfahren, mit den DESFire Karten, haben wir einem Beispiel Dokument direkt von NXP entnommen. Zum Glück hat sich ein Entwickler schon mit der Implementierung eines solchen Verfahren beschäftigt und die nötigen Schritte in ein bisschen Python Code validiert und mit einer kurzen Beschreibung auf GitHub veröffentlicht. Auf der Suche nach NFC-Libraries stellt sich eine über ein Netzwerk aufgebaute Verbindung als nicht sehr verbreitet heraus und die Libraries waren alle so aufgebaut, direkt mit der Karte über einen Reader oder die von Windows bereitgestellt PC/SC (Personal Computer/Smart Card API) zu kommunizieren. Da wir die Kommunikation mit Karte vom BFFH aus durchführen müssten wir sowohl für C# als auch für Rust eine verwendbare Bibliothek finden. Da sich keine passenden Library finden ließ, haben wir uns der Herausforderung gestellt und selber eine Klassenbibliothek in C# begonnen, die wir nach Rust porten wollten. Das stellte sich als schwerer heraus als gedacht, da die Dokumentation von der von uns verwendeten DESFire Karten unter einem NDA(Geheimhaltungsvertrag) steht und wir mit unserem Open Source Code diese Anforderungen nicht erfüllen können. An diesem Zeitpunkt begann für uns eine umfangreiche Recherche und Dokumentensammlung, wie die DESFire Karte funktioniert. Da die bekannten Libraries leider keine Kommunikationsbeispiele besitzten haben wir Tests für unsere Bibliothek aufgebaut, die genau einer reale Kommunikation mit der Karte entspricht. Mit diesen Tests können wir einfacher unseren Code in Rust testen. Wir werden unsere Unterlagen dazu nach einer Aufarbeitung auch bei uns in einem eigenen GitLab-Projekt veröffentlichen. Da wir anderen Entwicklern die Arbeit mit diesen Karten vereinfachen möchten.
UX und NFC
In unserem ersten Coaching, mit SimpleSecure stellten wir unseren ersten Designentwurf für Borepin vor. Bei diesem Gespräch stellt sich heraus, dass wir an dem Wiedererkennungsmerkmal für eine NFC Interaktion kreieren sollten, um so Nutzern eine einfache Erkennung von NFC Tags oder Karten bereitzustellen. Somit ist unser Design für eine NFC Markierung entstanden.
SmartCard und Maschinensticker im FabAccess NFC Design
Föderation und Netzwerke
Bei der Föderationsplanung und -entwicklung hatten wir ein paar ungeklärte Fragen zu beantworten. Da unser langfristiges Ziel ist über eine Föderation auch ein Abrechnung zu ermöglichen sollten die Föderationsabläufe sicher und nachvollziehbar für beide Partein sein. Da Föderation für beide Seiten ein Vorteil mit sich bringen muss, sind bisher die Planung von unserer Seite nur eine direkte Föderation zu erlauben. Somit föderieren nur Spaces miteinandern, wo sich die Manager kennen und zusammenarbeiten wollen. Es ist keine Netzwerkbildung möglich, bei der ein Zusammenschluss von Spaces entsteht, bei dem ein neuer Spaces direkt Zugriff alle Space bekommt ohne diese selbstständig und gegenseitig zu akzeptieren. Diese Entscheidung hat viele Diskussionen mit sich gebracht, da wir aber auch keine rechtliche Grundlage sehen dort Berechtigungen auszutauschen halten wir diese Vorgehenweise in der aktuellen Position für die sinnvollste. Wir wollen ja auch die Kommunikation fördern, also warum sollten die Manager denn nicht, mit einander mal geredet haben.
Community
Bei Thema Community und Unterstüzer netzwerken wir nun schon seit über zwei Jahren für diese Projektidee und haben uns auch in Laufe der Förderung, um eine Veröffentlichung unser Fortschritte bemüht.
Um unsere Kommunikation für die Entwicklung des Projekts nicht in privaten Chatgruppe zuführen haben wir uns für die Open Source Software Zulip entschieden und sind dort für neue und alte Interessierte und Unterstützer leicht erreichbar. Und das Threading ist in Zulip für ein solches Projekt ideal, um hier mal ein bisschen Werbung zumachen.
Durch die Verbindung unser Teammitglieder zum Chaosumfeld haben wir unseren ersten Vortrag beim Chaostreff Potsdam, anfang Dezember, gehalten. Das war zwar bei uns noch nicht so geplant hatte sich aber durch ein Missverständnis so ergeben. In diesem konnten wir unser Projekt vorstellen und die ersten Erkenntnisse und Planungen vorstellen. Vielen Dank an dieser Stelle an den Chaostreff Potsdam.
Da es nun schon fast Tradition ist auf dem Chaos Communication Congress eine kleine Gesprächsrunde rund um das Thema FabLab zuführen haben wir uns für eine digitale Gesprächsrunde auf dem rC3 entschieden. Durch diesen Talk konnten wir unserem Projekt zu mehr Öffentlichkeit verhelfen. Auch die Make hat uns darauf hin in einem ihrer Online Artikel erwähnt, sowie ein Beitrag in der aktuellen Ausgabe veröffentlicht. Dieses mediale Interesse, sowie die Rückmeldungen haben uns gezeigt, dass wir auf einem guten Weg sind und unser Projekt etwas verändern könnte.
Der Stand
Wie leider so oft in durchgeplanten Projekten haben wir nicht alle Ziele schon am Ende des Förderzeitraums erreicht.
Wir haben wie ihr in dem Video gesehen habt einen Prototypen der Maschinen einschalten kann.
Das SmartCard-System haben wir bisher nur als Code Libraries und Proof-of-Concept vorliegen, es muss noch in den Core eingearbeitet werden.
Wir haben eine erste Version der API am Anfang des Projektes definiert, welche grundlegende Funktionen beinhaltet hat die wir zu diesem Zeitpunkt schon festlegen konnten. Wir arbeiten gerade an einer verbesserten Version in die unsere jetzigen Kenntnisse und zukünftigen Wünsche einfließen, um bald einen stabilen Stand bieten zu können. Auch die einzelenen Subsysteme die wir definiert haben werden jetzt dort eingearbeitet.
Auf der Seite des Clients gibt es noch einige Bugs zu fixen, um unseren Cap'n Proto Code auf allen Plattformen ausführen zu können. Auch müssen wir unsere Designs noch in den Client einbauen, das ist der nächste Schritt nach der API Verbesserung.
Auch muss unsere komplette Planung noch genauer aufgeschrieben werden und unsere Konzept-Entscheidungen festgehalten werden.
Für die Föderierbarkeit müssen noch ein paar Umsetzungsentscheidungen getroffen werden, dass wir dann auch alles in die API einfließen lassen können.
Wie ihr seht haben wir noch einiges zu tun.
Die Zukunft
Die gute Nachricht ist, wir machen weiter.
Wir arbeiten an einer Strategie zur weiteren Förderung unseres Föderationskonzepts, um das gemeinsam mit dem Verband offener Werkstätten und dem Fab:Universe-Netzwerk fertigstellen zu können, um ab der zweiten Hälfte des Jahres ein größeres Rollout angehen zu können.
Auch wollen wir in einem Machbarkeitstest unseren Core (BFFH) erweitern und so testen, ob wir auch andere Anwendungen wie z.B. ein Netzwerk aus Lastenfahrradverleihen mit unserem System unterstützen können. Unser offener und generischer Ansatz scheint sich auszuzahlen.
Föderationsablaufbeispiel von FabAccess/DEMOKrAtIS DEMOKrAtIS ist der Projektname des Machbarkeitsprojektes
Mit unseren Verbündeten aus der Schweiz werden wir auch weiter zusammenarbeiten und bekommen mit etwas Glück aus der Richtung auch noch zwei Entwickler*innen als Unterstützung.
Auch an der Hardwarefront wird weiter getüftelt, mit unserem Unterstützer wollen wir eine neue Version des Readers erarbeiten, die wir als OpenHardware und als Bausatz bereitstellen wollen.
Zu dem Thema Abrechnungssystem sind wir noch auf der Suche nach einem Partner mit dem wir als Open Source Lösung den FabLabs, Makerspaces und Hackerspaces bei der Abrechnung von Leistungen helfen können.
Wie ihr sehen könnt, haben wir noch einige Ideen und Visionen, an denen wir arbeiten können. Und wir bleiben unserem Motto vom Kickoff der Förderphase treu "3 Billion Devices run FabAccess".
Für alle die noch schöne Ideen für unser Projekt haben oder uns bei der Umsetzung (auch bei unseren anderen Fab... Projekten) helfen wollen, können wir nur sagen, kommt auf unser Zulip, wir machen was Schönes draus.
Ein kleines Fazit
Vom Projekt
Wir setzten mit diesem Projekt unseren Wunsch nach einer zusammenarbeitenden Open Source Gesellschaft um.
Leider waren auch wir durch die Corona Pandemie gebremst und auch einige Projektkontakte sind im Sande verlaufen. An der Stelle: Das war in keinem Fall Absicht!! - meldet euch einfach wieder bei uns, wenn ihr Zeit und Lust habt. Wir freuen uns über jeden der mit macht. Im großen und ganzen haben wir das Beste aus der geförderten Zeit gemacht.
Wir haben mehr Zeit in einige Aufgaben gesteckt als wir erwartet und geplant hatten. Mit den Ergebnissen können wir aber zufrieden sein. Wir sind unserem Ziel und der ursprünglichen Idee ein großes Stück näher gekommen.
Wir müssen aber auch zugeben, dass wir an unserem Teammanagment arbeiten müssen, die nicht vollsynchrone Arbeitsweise mit nur wenigen persönlichen Treffen in der Gruppe bringt einige Schwierigkeiten mit sich und kann schnell zu Spannungen führen.
Von der Prototype Fund Förderung
Die Förderung durch den Protoype Fund hat unserem Projekt einen riesigen Sprung nach vorne verschafft. Ohne die Möglichkeit, viel Zeit in Planung und Entwicklung stecken zu können und dabei trotzdem unseren diversen finanziellen Verpflichtungen nachkommen zu können, wären wir nie in dem halben Jahr auf das Level gekommen, auf dem wir jetzt sind.
Die Organisation vom Prototype Fund ist gut, wir würden uns aber noch mehr Unterstützung bei den steuerlichen und finanziellen Aspekten der Förderung wünschen. Die Coachings waren sehr hilfreich für die Design Entscheidungen, für die wir auch schon viel Lob bekommen haben, vielen Dank an Eileen und Simply Secure an dieser Stelle.
Wir hoffen, dass das BMBF auch in Zukunft solche Civic Tech Projekte unterstützt und so einen Startboost gibt.
Vielen Dank auch an das Team vom Prototype Fund für die Planung und Unterstützung bei dieser Förderung.
02.02.2021 // FabAccess Struktur
Die Struktur von FabAccess soll größtmögliche Flexibilität bieten, um so den jeweiligen Anwendern die Anpassungsmöglichkeiten an deren Strukturen zu gewärleisten.
Die Erweiterbarkeit ist durch generische Schnittstellen zu weiteren Softwarepaketen und den Hardwarekomponenten gegeben und so nicht an einen Herrsteller gebunden.
Die Auswertung von Aktionen des Systems kann über eine Schnittstelle(Audit Log) erfolgen, um so eigene Software wie z.B. ein Abrechnungsystem anzubinden und den Funktionsumfang an den jeweiligen Bedarf anzupassen.
Vom Projekt her werden schon Anbindungen an übliche externe Systeme (Shelly, Tasmota, Odoo, …) bereitgestellt, um einen einfachen Einstieg zu ermöglichen. Weiterhin wird eine kuratierte Plattform zur Sammlung von solchen Schnittstellen-Software oder -Hardware zur Verfügung gestellt.
26.01.2021 // Projektskizze FabAccess IGP
tags: IGP
, FabAccess
[TOC]
Allgemeines
IGP-Föderung
Innovationsprogramm für Geschäftsmodelle und Pionierlösungen
:::info https://www.bmwi.de/Redaktion/DE/Artikel/Innovation/IGP/igp-einstieg.html :::
In der dritten Ausschreibungsrunde zu Innovationen im Bereich Bildung und Informationszugang mit hohem „sozialen Impact“ werden Ideen in den Fokus genommen, die Bildungsmöglichkeiten schaffen oder verbessern und/oder dazu beitragen, neue oder leichtere Zugänge zu Informationen zu ermöglichen. Die Projektideen sind geprägt von einem primär nichttechnischen Entwicklungscharakter, gleichwohl können neue technische Entwicklungen genutzt, adaptiert und in neue Zusammenhänge gebracht werden.
Projekt Details
https://fab-infra.org/de/projects/fabaccess/
Projekt-Antrag
Allgemeines
Projekt-Antrag
Antrag ist bis zum 2.2.2021 15 Uhr online einzureichen Dazu wird benötigt ein Teilnahmeantrag (Skizze):
- mit kurzer Projektbeschreibung
- erläuternden Abbildungen
- Angaben zu den vorgesehenen Antragstellern
Hier stehen Ihnen alle relevanten IGP-Dokumente zum Teilnahmewettbewerb der dritten Ausschreibungsrunde zur Verfügung: https://www.bmwi.de/Redaktion/DE/Artikel/Innovation/IGP/dokumente-teilnahmewettbewerb.html
OnlineAntrag: https://www.vdivde-it.de/submission/acl_users/credentials_cookie_auth/require_login?came_from=https%3A//www.vdivde-it.de/submission/bekanntmachungen/2027/p/1983578896/logged_out die Zugangsdaten sind in der Personaldatei
Antragsfinanzierung
hier muss auch die Antragssumme errechnet werden, etc.: https://www.bmwi.de/Redaktion/DE/Downloads/I/igp-hilfe-tool-zur-berechnung-der-voraussichtlichen-zuwendung.pdf?__blob=publicationFile&v=6 https://www.bmwi.de/Redaktion/DE/Downloads/I/igp-hilfe-tool-zur-berechnung-von-mitarbeiter-und-umsatzzahlen.pdf?__blob=publicationFile&v=4
Online Antrag
Kurztitel
Federated:Access /F:A
Vollständiger Titel der Projektskizze
"Nutzen ist das neue Haben“ und „Teilen das neue Besitzen“ Alltagsimplementierte Kreislaufführung von Ressourcen mittels "Zugang zu.. statt Eigentum an…"
Projektform
A: Experimentelle Einzel- oder Kooperationsprojekte in der innovativen Frühphase mit dem Charakter von Machbarkeitstests
Kurzbeschreibung
1000 Zeichen
Teilen und somit nachhaltige Ressourcenschonung im Alltag zu stärken und zu etablieren ist die adressierte Herausforderung: Alle haben unzählige Güter die nur zeitweise genutzt werden. Eine Bohrmaschine z.B. wird im Schnitt pro Jahr nur eine Stunde genutzt und liegt ansonsten im Schrank. Eigentlich könnten diese Dinge auch Freunden oder Nachbarn, d.h. Anderen zur Verfügung gestellt werden. Und nicht nur private Ressourcen, sondern auch die von Organisationen und Institutionen, Unternehmen oder Einrichtungen der kommunalen Daseinsvorsorge werden nicht so genutzt, wie sie könnten. Überlassung ist an Kriterien und Bedingungen geknüpft. Beispielsweise muss die Fähigkeit zur sachkundigen Handhabung eines Dings, die Zugehörigkeit zu einer autorisierten Personengruppe oder bestehender Versicherungsschutz nachgewiesen werden, damit Zugang gewährt werden kann. Gesamtgesellschaftlich wird Zugang zu den Ressourcen, die wir teilen und damit temporär besitzen können, benötigt. F:A gewährt diesen.
Frühester Beginn
Juli 2021 (ist gesetzt)
Antragssteller
Verbund Offener Werkstätten
Andere Einrichtungen vertreten über die mitarbeitenden Personen
- (FabLab an der Beuth)
- ...
IGP Poster
Innovationsbedarf
max. 2.500 Zeichen inkl. Leerzeichen
Verdeutlichen Sie insbesondere, wie durch die Adressierung des Bedarfs ein „sozialer Impact“, also eine positive Wirkung für das Gemeinwohl, entstehen kann.
Wichtig ist, dass der Neuigkeitswert der Projektidee und auch das längerfristige Potenzial der Innovation gut erkennbar sind.
Bedarf fundiert begründen und nach Möglichkeit belegen.
In jedem Fall sollte deutlich werden, dass Ihre Innovation hohen Neuigkeitswert besitzt und auf eine konkrete Problemstellung, einen Nutzen für die Zielgruppe (bei uns die Gesellschaft ?), einen unbefriedigten Bedarf o. Ä. zielt. In dieser Kategorie werden vor allem die Bewertungskriterien Innovationshöhe, wirtschaftliche Nachhaltigkeit und sozialer Impact bewertet.
Welchen Bedarf adressieren wir mit unserer Idee? (es geht auch um das "Heben ungenutzter Potentiale")
Warum muss es realisiert werden?
Welche Zielgruppe, welches gesellschaftlich wichtige Feld adressieren wir?
Lösungsansatz
Geschäftsidee/Pionierlösung
Die Darstellung Ihrer Geschäftsidee/Pionierlösung muss ohne weitere Quellen/Verweise/Dokumente verständlich und überzeugend sein. Quellenangaben und externe Verlinkungen können als Belege für Ihre Aussagen genannt werden, sie dürfen aber nicht für das Verständnis der Skizze essentiell sein! Beschreiben Sie,wie Ihre Geschäftsidee/Pionierlösung den Innovationsbedarf adressiert und ggf. die identifizierte Angebotslücke ausnutzt. Dabei ist es wichtig, die Idee mit ihren Stärken,Potentialen und vor allem ihrem Neuigkeitswert prägnant darzustellen. Beschreiben Sie bitte, welchen Mehrwert die von Ihnen adressierte Zielgruppe durch Ihre Pionierlösung gewinntund arbeiten Sie u.a.damit das Alleinstellungsmerkmal Ihrer Innovation heraus. Gehen Sie bitte auch auf die grundsätzliche Machbarkeit ein, und vermitteln Sie diese insbesondere für Projekte der Projektform B, z. B.durch den Verweis auf geleistete Vorarbeiten.
Umsetzung
max. 3.500 Zeichen
Wettbewerb
max. 3.000 Zeichen
Antragsstellende
Antragstellende Unternehmen und Einrichtungen
max. 2000 Zeichen
Qualifikation der vorgesehenen Mitarbeiter
Wirkungspotenzial
max. 3.000 Zeichen
Förderbedarf
max. 2.000 Zeichen
Grobstruktur
PTF rechnet mit 50€/h p.Person. 40h pro Woche, aufgeteilt auf die Leute die dabei sind. Förderung reicht dann nicht - bzw. Wochenstunden sind recht klein. --> Wochenstunden oder Honorar runter --> Laufzeit auf zB 8 Monate verkürzt: je 1 Monat Ein- & Ausstieg in/ ausm Projekt sowie 6 Monate Testphase
Wann brauchen wir die UG --> schreiben, dass wir die gründen & zur Antragsstellung tut's auch der VoW e.V.
Basis-Info-Seiten zu F:A ==> gibt es mehr Quellen ? https://fab-access.org/de/projects/fabaccess/ https://fabinfra.gitlab.io/fabaccess_lastenheft/FabAccess_Lastenheft.pdf
LoIs einholen von ? -> Nein, brauchen wir nicht jetzt.
Angaben für die Online-Abgabe:
Wir können bis zu 4 Abbildungen mit je 100 Zeichen Text beifügen. Diese Möglichkeit ist freiwillig.
Zwei Abbildungen können im Abschnitt Lösungsansatz eingefügt werden.
Zwei weitere Abbildungen können am Ende des IGP-Posters eingefügt werden.
Welchen Aspekt Ihrer Skizze Sie durch die Abbildungen illustrieren möchten, obliegt natürlich Ihnen.
Frühester Beginn:
Bestätigen, dass die Umsetzung noch nicht begonnen ist: Nee, weil die Machbarkeitstests noch ausstehen.
*Wir müssen ein sog. IGP-Poster ausfüllen in dem Online-Tool (Zugang siehe oben), hier die Themen die wir beantworten müssen, schreibt dazu was euch einfällt:
1. Innovationsbedarf - max. 2.500 Zeichen inkl. Leerzeichen.
welchen Bedarf adressieren wir mit unserer Idee ? (es geht auch um das "Heben ungenutzter Potentiale")
Warum muss es realisiert werden ?
Welche Zielgruppe, welches gesellschaftlich wichtige Feld adressieren wir ?
Verdeutlichen Sie insbesondere, wie durch die Adressierung des Bedarfs ein „sozialer Impact“, also eine positive Wirkung für das Gemeinwohl, entstehen kann.
Wichtig ist, dass der Neuigkeitswert der Projektidee und auch das längerfristige Potenzial der Innovation gut erkennbar sind.
Bedarf fundiert begründen und nach Möglichkeit belegen.
In jedem Fall sollte deutlich werden, dass Ihre Innovation hohen Neuigkeitswert besitzt und auf eine konkrete Problemstellung, einen Nutzen für die Zielgruppe (bei uns die Gesellschaft ?), einen unbefriedigten Bedarf o. Ä. zielt. In dieser Kategorie werden vor allem die Bewertungskriterien Innovationshöhe, wirtschaftliche Nachhaltigkeit und sozialer Impact bewertet.
[aus meinem Text - habe ich als Kurztetxt genommen] Teilen und somit nachhaltige Ressourcenschonung im Alltag zu stärken und zu etablieren ist die adressierte Herausforderung: Alle haben unzählige Güter, die nur zeitweise genutzt werden. Eine Bohrmaschine z.B. wird im Schnitt pro Jahr nur eine Stunde genutzt und liegt ansonsten im Schrank. Eigentlich könnten diese Dinge auch Freunden oder Nachbarn, d.h. Anderen zur Verfügung gestellt werden. Und nicht nur private Ressourcen, sondern auch die von Organisationen und Institutionen, Unternehmen oder Einrichtungen der kommunalen Daseinsvorsorge werden nicht so genutzt, wie sie könnten. Überlassung ist an Kriterien und Bedingungen geknüpft. Beispielsweise muss die Fähigkeit zur sachkundigen Handhabung eines Dings, die Zugehörigkeit zu einer autorisierten Personengruppe oder bestehender Versicherungsschutz nachgewiesen werden, damit Zugang gewährt werden kann. [bis hier als Kurztext genutzt]
Gesamtgesellschaftlich wird Zugang zu den Ressourcen, die wir teilen und damit temporär besitzen können, benötigt.
Ressourcen gemeinsam nutzen ! *Open Source, Gemeingüter, Teilhabe, Ressourcenschonung, Sharing "Nutzen ist das neue Haben“ und „Teilen ist das neue Besitzen“. Zugang zu.. statt Eigentum an… Mit dem Projekt Fab:Access startet ein quelloffenes, multifunktionales und plattformunabhängiges Open Source Soft- und Hardware Zugangssystem. Dies gilt es im Praxistest zu prüfen, zu optimieren und abschliessend zu etablieren. Eine förderierbare Automatisierungslösung für partizipative Strukturen und Communities. Sie soll den Teilnehmenden eine selbstgesteuerte, sichere und gleichberechtigte Nutzung von Ressourcen garantieren, durch eine leichte Berechtigungs- und Nutzenden-Verwaltung.
2. Lösungsansatz -
in zwei Teile gegliedert: Zum einen den Kern Ihrer Projektidee überzeugend beschreiben [2.1]: WIE wollen Sie den identifizierten Bedarf decken, WELCHE Lösung im Bereich Bildung/Informationszugang wollen Sie der adressierten Gruppe bzw. den potentiellen Kunden anbieten? Zum anderen müssen Sie die geplante Umsetzung [2.2] ausführlich darstellen. Erläutern Sie dafür nachvollziehbar, wie Sie (ggf. gemeinsam mit Kooperationspartnern) Ihre Projektidee realisieren wollen. Zudem haben Sie an dieser Stelle die Gelegenheit, Ihrer Teilnahmeskizze zwei Abbildungen beizufügen. Wählen Sie Abbildungen, durch die Ihr Lösungsansatz gut für Dritte nachvollziehbar wird. Nutzen Sie die Abbildungen, um Inhalte zu transportieren! In dieser Kategorie werden vor allem die Bewertungskriterien Qualität und Überzeugungskraft des Projekts bewertet.
2.1 Geschäftsidee/Pionierlösung
Die Darstellung Ihrer Geschäftsidee/Pionierlösung muss ohne weitere Quellen/Verweise/Dokumente verständlich und überzeugend sein. Quellenangaben und externe Verlinkungen können als Belege für Ihre Aussagen genannt werden, sie dürfen aber nicht für das Verständnis der Skizze essentiell sein! Beschreiben Sie,wie Ihre Geschäftsidee/Pionierlösung den Innovationsbedarf adressiert und ggf. die identifizierte Angebotslücke ausnutzt. Dabei ist es wichtig, die Idee mit ihren Stärken,Potentialen und vor allem ihrem Neuigkeitswert prägnant darzustellen. Beschreiben Sie bitte, welchen Mehrwert die von Ihnen adressierte Zielgruppe durch Ihre Pionierlösung gewinntund arbeiten Sie u.a.damit das Alleinstellungsmerkmal Ihrer Innovation heraus. Gehen Sie bitte auch auf die grundsätzliche Machbarkeit ein, und vermitteln Sie diese insbesondere für Projekte der Projektform B, z. B.durch den Verweis auf geleistete Vorarbeiten.
[aus meinem Text] In Offenen Werkstätten werden Räume, Werkzeuge und Maschinen, Materialien und Wissen bereits selbstverständlich geteilt, gemeinsam genutzt und gepflegt. Eine der wesentlichen Herausforderungen dieser offenen Communities ist, den Zugriff auf Infrastrukturen (Maschinen, Räume, Objekte) so auszubalancieren, dass jedes Individuum sich gleichberechtigt und niederschwellig maximal entfalten kann und gleichzeitig die „Tragik der Allmende“, d.h. die Einschränkung der Möglichkeiten Dritter durch Übernutzung oder rücksichtsloses Verhalten, möglichst minimal bleibt. Diese Praxis und Herausforderung gilt es, gesamtgesellschaftlich zu etablieren. In Nachbarschaften, in und zwischen Unternehmen, in Einrichtungen der öffentlichen Daseinsvorsorge, etc. Ausgehend von denen, die diese Praxis bereits leben hin zu jenen, für die es bisher fremd ist Damit Sharing auf gesellschaftliche Resonanz jenseits von Vermiet-Geschäftsideen stoßen kann, sind digitale Werkzeuge wichtig, die den Gemeinwohlinteressen und der Entwicklung von Nachhaltigkeitskulturen verpflichtet sind und Kooperation statt Konkurrenz, Zugang statt Ausschluss sowie Gemeinwohl statt Egoismus fördern.
Beispiele für Finanzierung:
- https://uberspace.de/en/product/#prices
- Posteo
- pay as much as you can
- Service für Orte die Fab:Access nutzen, aber nicht selber installieren und/ oder warten können/ wollen, so auch gemeinwohlorientierte Nutzungen in Kommunen, etc
- neben den Anwendungs-Fällen an den verschiedenen Orten werden weitere Anwendungsbedarfe bzw. Optionen zusammengetragen und wenn möglich (mindestens als Schnittstelle) hinzugefügt (Beispiel Bezahlsystem)
[name=T. Mulzer] s/Cases/Fällen/ ?
- es wird ein tragfähiges Geschäftsmodell erarbeitet um Neuinstallationen bei weiteren Orten, Support und stetige Optimierung samt Vertriebssystem (z.B. Website ?) gewährleisten zu können.
- we compiled into turning openness into a consistent competitive advantage, we identified that the application of open practices should always be paired with well-researched strategic intent. Without clarity of purpose, organizations will not (and nor should they) maintain long-term commitment to working with community https://medium.com/mozilla-open-innovation/whats-your-open-source-strategy-here-are-10-answers-383221b3f9d3
- Lösungsansatz -
2.2 Umsetzung (max. 3.500 Zeichen)
Hier müssen Sie den geplanten Lösungsweg zur Realisierung Ihrer Projektidee darlegen. Dazu gehört eine Erläuterung von aufeinander aufbauenden Projektphasen im beantragten Projekt mit nachvollziehbarer Beschreibung von Arbeitsinhalten, eine Darstellung des Entwicklungs-bzw. Anpassungsbedarfs sowie Beschreibungen von Herausforderungen und Risiken entlang des Lösungsweges, die auch den Förderbedarf (d. h. keine Finanzierung aus eigenen Mitteln möglich) belegen. Definieren Sie möglichst auch Meilensteine für Ihr Projekt. Diese stellen wichtige Etappen entlang des Lösungsweges dar, also Teilziele, an denen Sie den Projektfortschritt messen können. Falls Sie ein Kooperationsprojekt beantragen, sollte deutlich werden, welcher Partner welchen Anteil leistet und welche Meilensteine für welches Teilvorhaben relevant sind. Die Meilensteine sollten Ihnen zeigen, ob Sie mit dem ursprünglich angestrebten Lösungsweg Ihre Ziele erreichen können. Erläutern Sie hier, ob Sie das Projekt nur mit Ihrem Team bzw. den Projektpartnern umsetzen können, oder ob Sie Zuarbeiten von Dritten benötigen, wofür die Vergabe von Aufträgen ? erforderlich wäre. Diese Aufträge an Dritte sollten an dieser Stelle kurz erläutert werden. Wer soll welche Aufgaben wann für das Projektumsetzen? Wie werden diese Ergebnisse im Projekt verwendet?
Was liefert das aktuelle Projekt bis Juni 2021 ?/ Wo steigen wir im Juli 2021 ein ?
- Proof of concept? D.h. Einzelelemente des Konzeptes funktionieren an sich, aber nicht konkret als Anwendung...
- Prototyp? D.h. Einzelelemente funktionieren und sind mal als System zusammen zum Laufen gebracht worden, manuelle Anpassung und Bastelei ist für Portierung notwendig?
- Spezialistenlösung nur für offene Werkstätten mit IT KnowHow? d.h. Für eine offene Werkstatt läßt sich das system operativ einsetzen, bedarf jedoch IT Kenntnisse um es zu installieren und zu warten. Was soll die Anwendung am Ende des Projektes konkret können?
- Fertig installierbare Anwendung als Insellösung? D.h. man kann einen Raspberry Pi mit standard Linux nehmen, läd die pakete runter, geht auf eine Konfigurationsseite , gibt die anwendungsrelevante Parametern an (Reader, Akuatoren, sonstige), und kann loslegen
- Fertig installierbare Anwendung mit schittstellen / Anbindung zu "übliche" Anwendungen (Odoo, Kivitendo, vereinssoftware)?
- Nur stand-allone Demonstratoren in ausgewählte Werkstätten / Initiativen?
- Vernetze Demonstratoren in ausgewählte Werkstätten / Initiativen?
Minimum viable Product entwickeln und dann in der Community testen Testbetrieb mit den ausgewählten, beteiligten Orten/ Projekten für 6 Monate plus 1 Monat Vor- sowie 1 Monat Nachbereitung
-
alle Orte erhalten die Hardware in dem Grad der Fertigstellung wie sie in der Lage sind, diese zu nutzen (das Vorkonfigurieren im Kostenplan einstellen!), entsprechend sollten Orte dabei sein, die sich alles selber zusammen bauen können ebenso wie Orte denen alles installiert wird.
-
alle Orte erhalten durch Projektmittel finanziert ein Basis-Set der erforderlichen Hardware plus x SmartCards
-
alle Orte stellen selber erforderliche Serverkapazitäten soweit erforderlich
-
es gibt einen analogen Ablaufplan für alle Beteiligten sowie Austauschrunden pro Ort mit dem Projekt-Team ebenso wie Austauschrunden mit allen Orten und dem Projekt-Team zusammen (Honorare, ggfs Reisekosten für alle die Zeit geben).
Mögliche Testorte mit verbindlichen Ansprechpartner*innen:
machbar Potsdam / Martin Koll
Eigenbaukombinat Halle/ Roberto (über Frauke)
Konglomerat eV Dresden/ Betti (über Frauke)
Wir bauen Zukunft eG/ Frauke Hehl
TH Brandenburg/ Lisa (über Tasso)
Beuth Hochschule / Tasso Mulzer
Makerspace Bocholt gUG / Joris Bijkerk
Flotte Potsdam / Chris (über Tasso)
Orte mit verschiedenen Anforderungen, z.B. im ländlichen oder urbanen Raum, mehr-Gewerke-Projekte wie Konglomerat eV in Dresden oder Eigenbaukombinat in Halle, andere Gemeinschaftseinrichtungen wie zB. Stadtteiltreffs, Gemeinschaftsgärten oder ...?
Bisher haben wir recht homogene Orte, keine Bibliothek oder was weiss ich. Vielleicht starten wir mit unseren Orten und nehem im letzten Drittel noch 1-2 andere Orte mit anderen Voraussetzungen dazu ?so 1/3 der Zeit mit unseren Orten arbeiten, im 2/3 2 weitere Orte mit weiteren Herausforderungen ausfindig machen und die im letzten Drittel dann mit reinholen ?
[name=T. Mulzer] Vorschlag aus der TH Brandenburg: Klimawerkstatt, Werder/Havel [name=J. Bijkerk] macht Sinn
Entwurf Anschreibe-Text für die bisher anvisierten Orte: Hallo Ihr Menschen vom xy, aktuell ist das Zugangstool Open:Acces (https://fab-access.org/de/projects/fabaccess/) in Entwicklung. Damit es gut in die Landschaft der Offenen Werkstätten, Makerspaces, etc. eingeführt werden kann, wollen wir einen Testphase organisieren, in der wir mit Orten, welche verschiedene Anforderungen mitbringen, zusammen arbeiten in der Erprobung und Praxisanwendung des Tools. Gerne möchten wir auch euch dazu einladen. Was braucht es dazu ? Ein bis zwei verbindliche Ansprechpartner, die zusammen mit uns Entwicklern und Menschen vom Verbund der Offenen Werkstätten 6 Monate das Tool testen. Los gehen soll es, so die Ressourcen bis dahin akquiriert sind, im August 2021 bis einschliesslich Januar 2022. In eurem Space soll Open:Access angewendet werden und ihr berichtet uns und den anderen Orten die ebenalls in dieser Phase dabei sind, was wie läuft, fehlt, verändert werden sollte usw. Ihr arbeitet also bei euch vor Ort und nehmt an Austauschrunden mit uns und allen in diesen 6 Monaten teil. Bitte gebt uns bescheid, ob ihr dabei seid und wenn ja, wer von euch für uns die Kontaktperson(en) sind. ... ==> gerne ergänzen, umschreiben etc ! - Danke
Weitere Anwendungen des Tools in diesen Netzwerken/ Verbünden:
- Repair-Cafes
- Gemeinschaftsgärten
- Flotte Berlin Lastenradverleih
- Solawi
- initiativen-fuer-materialkreislaeufe
- Haus der Statistik bzw verschiedenste Inis darin
- VBS (Verband Brandenburger Segler)
- Ladesäulenbetreiber
- ...
Ein (Software)Projekt, das soziale Strukturen unterstützt und entwickelt und nicht eins, das primär kommerzielle Interessen bedient. Was auch durch und mit diesen Strukturen sich weiter entwickelt, Beispiel freifunk.net
Durch das Tool bekommen viele Menschen die Möglichkeit, sichere/ überschaubare Zugänge zu Infrastruktur zu erhalten ohne das dazu immer eine Zugang-gebende Person vor Ort sein muss.
Skalierbar und damit von grossem Interesse für das Gemeinwohl.
3. Wettbewerb (max.3.000 Zeichen)
Hier soll erläutert werden, wie sich Ihre angestrebte Lösung vom Wettbewerb im Sinne bereits bestehender vergleichbarer Angebote abhebt, sowohl national als auch international. Nutzen Sie die Kategorie, um den Gutachterinnen und Gutachtern zu zeigen, dass Sie das spezifische (Wettbewerbs-)Umfeld kennen und um möglichenationale und internationale Anbieter und deren alternative Lösungen/Angebote wissen. Wie viele und welche direkten Konkurrenten bzw. andere Anbieter gibt es ggf.und wo sehen Sie Vor- bzw. auch Nachteile Ihrer angestrebten Innovation? Welche Markteintrittsbarrieren oder Herausforderungen bei der Implementierung bestehen? Dies betrifft u. U. auch regulative Rahmenbedingungen sowie Patent-und Schutzrechte. Nur wenn Sie das spezifische Anbieterumfeld bzw. den bestehenden Wettbewerb klar und präzise beschreiben, wird auch der Wettbewerbsvorteil Ihres Ansatzes bzw. sein Alleinstellungsmerkmal nachvollziehbar! Dadurch können Sie auch verdeutlichen, welche ungenutzten Potenziale u.a. in Hinblick auf gesellschaftlichen Nutzen durch Ihre Innovation gehoben werden können. Benennen Sie zudem ganz konkret, worin bzw. wie sich Ihre Innovation von bestehenden Lösungen unterscheidet. Belegen Sie dies mit konkreten (soweit möglich auch quantitativen) Parametern/Aspekten Ihrer Innovation im Vergleich zu verfügbaren Lösungen. Bei Projekten der Form A, die sich noch in der innovativen Frühphase befinden, kann eine detaillierte Wettbewerbsanalyse dagegen Teil des vorgesehenen Machbarkeitstests sein. Gleichwohl muss auch in diesem Fall grundlegendend beschrieben werden, wie sich die angestrebte Innovation von Bestehendem abheben soll. Bitte verweisen Sie zudem möglichst mit Links auf bestehende Konkurrenzlösungen, von denen Sie sich abheben möchten (Beispiel https://fabman.io/ - was gibt es noch ?). In dieser Kategorie werden vor allem die Bewertungskriterien Innovationshöhe, wirtschaftlicheNachhaltigkeit und sozialer Impact bewertet!
""einer durchgeführten Recherche zu Vor- und Nachteilen eingesetzter Zugangssysteme wo finde ich das ???
Es existieren bereits technische Lösungen für Zugangssysteme (Fabman.io), allerdings sind diese proprietär und von teuren Lizenzen abhängig und oft an sehr spezifische Anwendungsbereiche angepasst, die der Vielfalt offener Räume und ihrer Bedürfnisse nicht gerecht werden. bestehende Systeme sind … zu teuer Fabman.io - Anschaffung: ca. 4.700€ (bei 20 Geräte), laufende Kosten 350€/ Monat FabAccess - Anschaffung: ca. 1.000€ (bei 20 Geräte), keine laufende Kosten. … passen nicht vollständig zu unseren Bedürfnissen. … nicht problemlos in bestehende Strukturen integrierbar … kein föderativen Ansatz … nicht für andere soziale Konzepte verwendbar ... nicht selber veränderbar Fab:Access
Was sind dabei unsere Ziele?
Das System soll sich verbreiten, das bedeutet.
Das System soll auf einer möglichst breiten und agilen Basis entwickelt werden.
Wir wollen für die User entwickeln, nicht für uns.
Das System soll Menschen Arbeit abnehmen statt aufbürden.
Das System soll im Rahmen einer nachhaltigen Struktur entstehen - nicht an einer Person hängen, sondern jederzeit durch andere weiterentwickelt werden können.
–> strictly OpenSource.
In Zukunft optional als Föderation funktionieren
Leihs ist ein Ausleihsystem das an der ZHDK (Züricher Hochschule der Künste) entwickelt wird. Es bietet Datenstrukturen die ausleihbare Gegenstände gut beschreiben. FabAccess wird Schnittstellen zu Leihs haben.
FabManager ist ein Managementsystem für offene Werkstätten als Open Source Lösung. Das System ist ein "Copy-Paste system" mit dem für offene Werkstätten ein Mitglieds- und Maschinenmanagement System zur Verfügung steht. Die Anbindung von FabAccess an Fabmanager würde für offene Werkstätten ein vollwertiges Verwaltungssystem als Open Source Lösung darstellen. FabManager wurde in Frankreich entwickelt. besteht Kontakt ? können wir den benennen ?
Sammlung laufender Aktivitäten: https://pad.gwdg.de/DsyvzN4TQyyB5M94ZCBihQ?both
Referenztexte (Beispielhaft) https://tools.ietf.org/html/rfc7831 Application Bridging for Federated Access Beyond Web (ABFAB) von 05/2016 by Internet Engineering Task Force (IETF) Architecture/ Bedeutung von Förderation
https://medium.com/mozilla-open-innovation research report from Mozilla and Open Tech Strategies provides new perspectives on framing open source strategy. 05/2018
4.1 Antragstellende Unternehmen und Einrichtungen (max 2000 Zeichen)
Eignung, Erfahrungen und Kompetenzen des Skizzeneinreichersbzw. der einreichenden Unternehmen/ Einrichtungen, Vorarbeiten und Referenzen eingehen, so dass die Eignung deutlich wird. Bei Kooperationsprojekten soll hier zudem deutlich werden, in welcher Form sich die antragstellenden Unternehmen/Einrichtungen komplementär als Projektpartner ergänzen und wie die Zusammenarbeit bzw. Arbeitsteilung zwischen den Partnern und den wesentlichen mitarbeitenden Personen gestaltet werden soll. Geben Sie bitte eine kurze Kompetenzbeschreibung eines jeden Kooperationspartners ab.
Verbund Offener Werkstätten e.V. zusammen mit?
4.2 Qualifikation der vorgesehenen Mitarbeiter
stellen Sie die am Projekt voraussichtlich mitwirkenden Personen bzgl. Berufs-, Bildungs-und Erfahrungshintergründen vor, inklusive Schlüsselqualifikationen und relevante Arbeitserfahrungen, so dass die Eignung der vorgesehenen Personen beurteilt werden kann Frauke Hehl VOW /Koordination Maximilian Voigt (begleitend ?) VOW /Koordination Tasso Mulzer Joris Bijkerk (Tester und Beschaffung und Bau von Hardware) Gregor, Kai, Joseph, ... weitere Entwickler ?
https://www.heise.de/news/FabAccess-Bessere-Maschinenverwaltung-fuer-Fablabs-5027184.html?fbclid=IwAR0dbaOY20l3n2RuR8D8RbOV9Y_KmausQqqMsZSe7qP4oxqYE5o64La-1IE
5. Wirkungspotenzial (max. 3.000 Zeichen)
Bitte erläutern Sie, welches Potential Ihre Innovationhat, von der adressierten Zielgruppe angenommen zu werden und auf diese Weise eine nachhaltige positive Wirkung für das Gemeinwohl zu entfalten. Idealerweise sollte ein möglicher gesellschaftlicher Nutzen deutlich werden, der deutlich über das Projekt hinausgeht. Schätzen Sie dabei bitte die Anzahl der möglichen Nutzer samt der Nutzungsintensität bzw. die Marktgröße ab. Bitte achten Sie darauf, dass der gesellschaftliche Nutzen Ihrer Innovation möglichst objektiv dargestellt werden sollte, so,dass z.B. ein breiter gesellschaftlicher Konsens über den Nutzen nachvollziehbar ist. Von großer Bedeutung ist zudem die „wirtschaftliche Nachhaltigkeit“ Ihres Projekts. Bitte stellen Sie dar, wie die zu entwickelnde Pionierlösung bzw. das zu entwickelnde Geschäftsmodell („Projektergebnis“) prosperieren soll bzw. auch nach der IGP-Förderungwirtschaftlich tragfähig ist und aus eigener Kraft weiterexistieren bzw. -expandieren kann. Dies wird in der Regel gut durch die Darstellung eines entsprechenden Umsatzpotenzials möglich sein. Sollte die Natur Ihrer Lösung derart sein, dass sie selbst keinen Umsatz generieren kann, sollte ein Konzept vorgelegt werden, wie das Fortbestehen der Lösung insbesondere durch andere Finanzierungsquellen (z.B. Sponsoring, Spenden, Lizensierung) nach Auslaufen der IGP-Förderung gut gesichert werden kann. Es sollte ersichtlich werden, dass das Projektansinnen mindestens verstetigt werden kann, auch wenn die Förderung durch IGP beendet ist. Wünschenswert wäre eine über die Verstetigung hinausgehende Prosperität des Projektergebnisses nach Förderende. Die Schwerpunkte Ihrer Ausführungen in dieser Kategorie sollten je nach Projektform wie folgt ausgelegt werden:Projektform A: Ordnen Sie bitte das Thema Ihres Machbarkeitstests im zu untersuchenden Umfeld/Markt ein. Es sollte u.a. deutlich werden, ob Sie eine Lösung für eine Nische schaffen wollen und wenn ja, wie groß diese Nische ist oder ob Sie sich im Wettbewerb mit sehr vielen anderen Teilnehmern befinden. Welche Ideen haben Sie bereits,potentielle Nutzer zu überzeugen bzw. Anteile dieses Marktes zu erobern? In der Kategorie „Wirkungspotenzial“ werden vor allem die Bewertungskriterien sozialer Impact und wirtschaftliche Nachhaltigkeit bewertet.
[aus meinem Text] Zukunftsfähige Werteorientierungen leiten das Handeln und fördern Gerechtigkeit im Miteinander.
Open Source Code und Hardware, umfassend dokumentiert und als gemeines Gut kostenfrei für alle veröffentlicht und nutzbar gestaltet. Ohne spezifische technische Vorkenntnisse vorauszusetzen. Aufbauend auf einer durchgeführten Recherche zu Vor- und Nachteilen eingesetzter Zugangssysteme, ist ein entsprechendes OS-System in unserem Netzwerk bereits in Programmierung. Akteure u.a. von der Beuth Hochschule für Technik Berlin und der Eidgenössischen Technischen Hochschule Zürich arbeiten daran. Um die Idee weiter entwickeln zu können, muss der Umsetzungsplan vom status quo zum „minimum viable system“ konzipiert werden. Das Netzwerk würde mithilfe des Preisgeldes um Mitwirkende aus weiteren Einrichtungen aus Wissenschaft, Forschung und Entwicklung erweitert. Neben fachlicher Expertise sind Kompetenz zur internen, wie externen Kommunikation und Öffentlichkeitsarbeit hilfreich, sowie zielgerichtetes Vorgehen bei Implementierung und den iterativen Weiterentwicklungsphasen mit der Werkstätten-Community.
Im Produktiveinsatz in ausgewählten Offenen Werkstätten können neben soft- und hardware-Aspekten insbesondere die leitenden Arbeitshypothesen überprüft werden (zu Auswirkungen auf Diversität, Teilhabe und Engagement von Nutzer*innen, sowie Management und Organisationsentwicklung beispielsweise). Ein evaluierter Proof of Concept erleichtert dann die Übertragung der Soft- und Hardware auf andere Kontexte, für die Zugangs- und Berechtigungsregelungen etabliert werden. Ziel ist, transdisziplinäre Anwendungs- und Forschungssettings zu entwickeln, d.h. die Idee in verschiedenen Reallaboren zu testen. Beispielsweise in Bibliotheken, Unternehmen, Bildungseinrichtungen, etc.
Die direkte Folge einer Umsetzung der Idee Fab:Access kann sein, dass die bisherige Landschaft der infrastrukturteilenden Communities wie die der Offenen Werkstätten einen starken Wachstumsschub erleben und sich weiter diversifizieren. Auf der Plattform www.offene-werkstaetten.org sind derzeit ca. 400 Initiativen unterschiedlichster Art und Größe verzeichnet. Je einfacher und aufwandsärmer es wird gemeinschaftliche Güter und Infrastrukturen zu managen, desto wahrscheinlicher, dass andere von dieser sozialen Innovation angesteckt werden und diese sich verbreitet. Im urbanen wie im ländlichen Raum. Durch das System können beliebige Infrastrukturen geöffnet und zugänglich gemacht werden, d.h. brachliegende Ressourcen könnten zur „Offenen Werkstatt“ werden. Bürger*innen könnten über ein einfaches und individualisierbares, kostenfreies System für Sharing diese Kultur des Teilens in gelebte Alltagspraxis überführen und Ressourcen mit anderen gemeinsam drüber nutzen.
Plattformübergreifend heißt u.a. auch möglichst große Flexibilität bei der Systemwahl. Ob nun Desktop- oder Serverlösung, App oder RFID-Karten… Langfristig könnten multiple Lösungen entstehen, die es erlauben sicher und DSGVO-konform individuelle und gruppenbezogene Zugangsberechtigungen, sowie solche mit z.B. örtlich-geografischer Reichweite, zu verwalten: Ein förderiertes IT-System für Sharing. Statt eines Vertriebssystems für ein technisches Produkt, wird es über lokale Offene Werkstätten reale Anlaufpunkte geben, in denen diese digitalen Werkzeuge und Hilfsmittel für Sharing adaptiert und eingesetzt werden. Hilfe für die Anwendung in anderem Kontext kann hier eingeholt werden, wie heute schon Offene Werkstätten Knotenpunkte lokaler Nachbarschaftshilfe darstellen. Commoning statt Business, d.h. ein Ökosystem hilft die (neue) Kultur und Praxis des Teilens in die Kapillaren der Gesellschaft vordringen zu lassen.
6. Förderbedarf (max. 2.000 Zeichen)
Erläutern, warum staatlicher Förderbedarf ? Dabei sollten Sie auf die Risiken und Herausforderungen eingehen, die Sie bei der Umsetzung der Projektidee erwarten (siehe Abschnitt 2.2) und die eine private oder anderweitige Finanzierung des Projekts ggf. erschweren. Warum das Projekt nicht vollständig aus Eigenmitteln bezahlt werden kann ? Nur Förderung, wenn es ohne Förderung gar nicht oder nur mit Zeitverzögerung und in bedeutend geringerem Umfang realisiert werden könnte ! In dieser Kategorie werden vor allem die Bewertungskriterien Anreizeffekt und Innovationswagnis bewertet.
Finanzierung 75% (bei Gemeinnützigkeit) Zuwendung, Rest Eigen- oder Drittmittel, maximale Zuwendung 49.000€ Eigenmittel könnte aktuell der VOW beisteuern (bis zu 20.000€) BEACHTE DIE VORGABEN ZUR HONORARGESTALTUNG !
[name=J. Bijkerk] Hardware-Kosten: Je "Ort" brauchen wir
- ein RPi (50€)
- Minimale IT Infrastruktur (250€) (-> passiver PoE Router, Kabel, Wlan-Router)
- 5-10 Lesegeräte (je 30€)
- 50 DESfire-Karten (je 2€) d.h. 550€ bis 700€ pro "Ort" allgemein bräuchte man
- Reiskosten (Projekt-Reisen und Reisen-um-Föderation-auzuprobieren)
- Weiterentwicklung Hardware (Material 400€)
- Personalkosten
Bewertungskriterien
zu den einzelnen Tops die wir beantworten müssen, wird am Ende immer genannt, welches Bewertungskriterium dafür besonders relevant ist.
- Innovationshöhe: Wesentlich hierfür sind Kreativität, Wagemut und Pioniercharakter des Ansatzes sowie sein Neuigkeitswert auf nationalem und internationalem Level.
- Anreizeffekt: Der Förderbedarf muss schlüssig begründet sein. Bei den Projektformen A und B muss das realistisch erreichbare Gelingen einer Innovation, aber gleichwohl die mit der Umsetzung verbundenen Risiken erkennbar sein. Im Fokus steht die Frage, warum staatliche Hilfe notwendig sein soll.
- Qualität und Überzeugungskraft des Projekts: Ein Projekt sollte über eine klare Zielorientierung sowie über einen logischen und konzistenten Aufbau verfügen.
- Vermarktungschancen: In der dritten Ausschreibungsrunde zum Thema Innovationen im Bereich Bildung und Informationszugang werden soziale Innovation im Sinne besonders gemeinwohlorientierter Innovationen besonders berücksichtigt. Daher werden statt des Bewertungskriteriums „Vermarktungschancen“ die Kriterien „sozialer Impact“ und „wirtschaftliche Nachhaltigkeit“ bewertet: Sozialer Impact: Potenzial der positiven Wirkungen auf das Gemeinwohl, Nutzen des Projekts für die Gesellschaft, inkl. Skalierbarkeit des Ansatzes auf andere Bereiche bzw. Regionen. (z.B. Förderation !) Wirtschaftliche Nachhaltigkeit: Überzeugungskraft des Konzepts für die Prosperität des Projektergebnisses nach Abschluss der IPG-Förderung durch andere Finanzierungsquellen, wie z.B. Umsätze (Service, F:A zu installieren und zu warten), die durch die Innovation erzielt werden.
Antragsdokumente
-
Übersicht: https://www.bmwi.de/Redaktion/DE/Downloads/I/igp-faktenblatt-zur-3-ausschreibungsrunde-zu-bildung.pdf?__blob=publicationFile&v=4
-
Ausfüllhilfen: Überblick https://www.bmwi.de/Redaktion/DE/Artikel/Innovation/IGP/dokumente-teilnahmewettbewerb.html Hinweise zum Ausfüllen des IGP-Posters im Rahmen desTeilnahmeantrags (nachfolgend Teilnahmeskizze/Skizze)für die Projektformen A und B https://www.bmwi.de/Redaktion/DE/Downloads/I/igp-ausf%C3%BCllhilfe-projektform-a-b.pdf?__blob=publicationFile&v=8 Hinweise zum Ausfüllen des IGP-Business-Sheets im Rahmen der Teilnahmeskizze https://www.bmwi.de/Redaktion/DE/Downloads/I/igp-ausfuellhilfe-fuer-das-igp-business-sheet-fuer-alle-projektformen.pdf?__blob=publicationFile&v=6 Aktuelle Informationen, Dokumente und Termine rund um das IGP https://www.bmwi.de/Redaktion/DE/Artikel/Innovation/IGP/igp-service.html
Telegram-Gruppe
- https://t.me/joinchat/F2sJ6IG1hqviN9qv
26.01.2021 // Borepin Doc
Known Bugs
https://github.com/xamarin/Xamarin.Forms/issues/1575
https://github.com/xamarin/Xamarin.Forms/issues/10437
22.01.2021 // Antwort Repair-Cafe
Sehr geehrte Damen und Herren,
eignet sich Ihre neue Plattform auch für Repair-Cafes? Ich suche schon lange so ein Ticketsystem, damit ich z.B. nicht mit meinem kaputten Breitbild-Fernseher mit Bus & Bahn zum nächsten Repair-Cafe fahre um dann zu erfahren, dass keiner Zeit für mein Problem hat oder sich nicht auskennt und ich unverrichteter Dinge wieder nach Hause fahren muß. Die Dingfabrik in Köln ist sowieso der Meinung, dass so ein Cafe als Schwerpunkt "Cafe und Kuchen" hat, weil es ja alles Freiwillige sind, die das machen? Wenn die freiwillige Feuerwehr auch diesen Standpunkt vertreten würde, dann würde Ihr brenndes Haus nicht mehr gelöscht, oder wenn andere Dienste wie z.B. das DRK, dass auch vorrangig von Freiwilligen organisiert wird, so denken würde, dann würden keine Blutspendetermine mehr laufen um Leben zu retten, oder die Corona-Impfungen könnten nicht stattfinden, weil die Ehrenamtlichen gerade Kaffee trinken und Kuchen essen Aber die Betonköpfe von der Dingfabrik lassen sich leider nicht umstimmen und lehnen mein Engagement ab. Daher versuche ich schon länger etwas Alternatives auf die Beine zu stellen durch ein Repair-Wiki oder eine Plattform, wo man seine Dienste bereitstellen kann und Leute darauf reagieren können. Aber da ich nur eine Privatperson bin, weiß ich zur Zeit nicht wie ich es zeitlich, räumlich und personell organisieren soll? Sind Sie auch der Meinung, dass man weiter der Umwelt schaden sollte und massiv Elektroschrott produzieren soll, weil es kein Recht auf Reparatur gibt? Oder würden Sie auch für den Umweltschutz eintreten und mir helfen meine Idee in die Tat umzusetzen? Leider kenne ich mich mit "Cap'n Proto" nicht aus. Warum schreiben Sie es nicht mit PHP oder Python, dann könnte ich Sie unterstützen. Über eine freundliche und konstruktive Antwort würde ich mich sehr freuen.
Mit freundlichen Grüßen
Meinungen:
- Oh weih, ist der Mensch frustriert... (TMu)
- Er hat ein soziales Problem mit der Dingfabrik - das wird FabAccess nicht lösen. - selbst wenn die Dingfabrik (oder er) irgendwann FabAccess einsetzt. (-"-)
- Sehe ich auch so (TheJoKlLa)
-
Freundliche und konstruktive Antwort > Diese Mail
Kurzantworten: eignet sich Ihre neue Plattform auch für Repair-Cafes? Prinzipiell ja, sofern RepairCafes Maschinen zur Nutzung anbieten und Einweisungen dafür geben. Allerdings eher nicht, für dass was Sie vorhaben ... wir werden aber nicht in das Termin-Management von Repair-Cafes eingreifen und das wird FabAccess auch nicht darstellen.
Ticketsystem Für ein Ticket System gibt es bessere Alternativen, Jira oder RequestTracker zum Beispiel.
Sind Sie auch der Meinung, dass man weiter der Umwelt schaden sollte und massiv Elektroschrott produzieren soll, weil es kein Recht auf Reparatur gibt? Nein
Oder würden Sie auch für den Umweltschutz eintreten und mir helfen meine Idee in die Tat umzusetzen? Können wir leider nicht (... wir sind mit FabAccess ausreichend beschäftigt... und nicht in Köln.)
Warum schreiben Sie es nicht mit PHP oder Python, dann könnte ich Sie unterstützen. 0. Weil ich will. * PHP / Python ist nicht besser als $Language, auch nicht als Rust. * Rust ist nicht besser als $Language, auch nicht als PHP. * Aber ich schreibe die software nunmal anstatt mich drueber auszuhaeulen wie schlimm $Repaircafe ist. Also ist es Rust.
-
Warum nicht PHP/Python sondern spezifisch Rust?
- Geschwindigkeit
- Und damit Effizienz. Die Tatsache das wir Python verwenden traegt inzwischen nicht unwesentlich zum Klimawandel bei.
- Sicherheit
- Gegen Bugs die in Netzwerksoftware oft Exploits verursachen, z.b. double free, buffer overflow (vgl. Heartbleed), buffer underflow aber auch gegen Logik-Bugs durch starke Typen
- Stabilität
- Sowohl auf ABI-level, Rust hängt am Ende nur noch von der glibc ab
- Die Software selber wird dadurch weniger warscheinlich abstürzen
- Ich kann Rust besser als Python und wesentlich besser als PHP
- Geschwindigkeit
-
Cap'n Proto ist keine Programmiersprache sondern eine Schemasprache und definiert die Schnittstelle sinnvoll damit externe [Personen] Clients sinnvoll schreiben können und die nicht ständig in die Luft fliegen weil irgendwas irgendwo eine Sache im Api ändert die inkompatibel ist
-
Es wird eine Python Implentation der API geben, mit der kann dann ein eigener Client geschrieben werden
Antwort
Sehr geehrter Herr M....,
unsere Software FabAccess ist zur Verwaltung von FabLabs und offenen Werkstätten gedacht, um so den Umgang mit Maschinen sicherer zu machen. Für den Einsatz in Repair-Cafes eignet sich unsere Software nur, wenn in diesem Umfeld Maschinen oder Gegenstände verliehen werden.
Für das Vorhaben was Sie anstreben bietet sich aus unserer Sicht eher ein Open Source Ticket System wie Jira oder RequestTracker an. Teilweise wird so etwas auch z.B. auf Discourse abgebildet. Auf einer solchen Plattform könnte Ihre Idee aufgebaut werden.
Wir unterstützten natürlich den Ansatz von Repair-Cafes, mehr zu reparieren und weniger zu entsorgen. Manche von uns sind auch in RepairCafes direkt aktiv und beteiligt. Allerding kann unsere Software bei diesem Problem nicht helfen.
Leider können wir Ihnen bei Ihrem Projekt nicht helfen, aber wir hoffen wir konnten Ihnen einen Weg zeigen, wie Sie mit Ihrem Projekt starten können.
Die Toolwahl wurde tatsächlich am Projekt-Start ausführlich disktuiert und ist für unser Projekt den Kenntnissen unserer Entwickler gefolgt, um in der kurzen Zeit der Föderphase einen langfristig schnell und stabil laufenden und möglichst von Programmierfehlern freien Prototypen zu erhalten. Der Rust-Compiler verhindert an der Stelle Fehler, die in anderen Programmiersprachen gerne übersehen werden und produziert dabei sehr effizienten Maschinencode ohne viele externe Abhängigkeiten.
Als Info für Sie: Bei Capt'n Proto handelt es sich nicht um eine Programiersprache die wir verwenden, sondern um die Schemasprache mit der wir unsere API definieren. Für unseren Anwendungszweck, eine möglichst stabile und erweiterbare API zu bauen eignet sich Capt'n Proto daher besonders gut. Über diese Herangehensweise können wir anderen Open Source Entwicklern wie Ihnen eine Möglichkeit geben unsere Software zu erweitern, wie zu Beispiel einen eigenen Client zu schreiben.
Wir hoffen wir konnten Ihre Fragen alle beantworten und wünschen Ihnen noch viel Glück und Erfolg bei der Umsetzung Ihrer Idee, die Repair-Cafes zu revolutionieren.
Mit freundlichen Grüßen
Das Fab-Infra Team
21.01.2021 // API Meeting
Bootstrap Interface, für Informationen ohne Authentifizierung Von dort aus kann man sich dann Authentifizieren
Bootstrap Interface:
- Serverinformationen
- sich authentifizieren
- Ping
- (Post Prototype) Server-Module auslesen
Maschine Subsystem:
-
Maschinen lesen
-
Maschinen reservieren
-
Maschinen editieren
-
Maschinen (als Dummy / ohne weitere Informationen) erstellen (Nur fuer 3rd party client)
- QR-Code
TIS-23D
=> Maschine ID<namespace>/TIS-23D
=> Permissionbffh.machine.create.<namespace>.*
- QR-Code
-
Tags - Key / Value
- Key: Position - Value: Map Kind $Value
- Key: Static - Value: struct Position on a map
- Key: Preise - value: ??
- Super wichtig fuer foederierte Aktionen wo Preise von $zuhause zu $foederiertemVerein unterschiedlich sind.
- Key: Stromverbrauch - Value: Ampere-Wert
- Key: Custom(String) - Value: Leaf Bytes (Tree Bytes)
Good:
- Key: "https://lastenrad.de/fabaccess-ns/kilometerstand" - Value: Varint
Bad:
- Key: "varint" - Value: Bool
- Key: Position - Value: Map Kind $Value
-
Metadaten
Permission Subsystem (Admin):
- Berechtigungen lesen
- Berechtigungen erstellen
- Berechtigungen editieren
- Nutzer lesen
- Nutzer erstellen
- Nutzer editieren
Interaction Subsystem:
- Mapping Initiator => Machine (Event)
- kommt ungefragt und asynchron rein
- FabAccess weiß vorher was kommt
- .. um einen Wert einer Maschine (z.B. aus/an) zu ändern
- Mapping Machine => Actor (Actor)
- Mapping Sensor => Machine (Behaviour)
- wird von FabAccess regelmäßig abgefragt
- oder kommt ungefragt und asynchron rein
- .. Wert der draussen aktuell ist und zur weiteren Verarbeitung zur Verfügung steht.
- Effekte / Rule (Effect) (Event / Behaviour -> Event / Behaviour)
- Kann (wenn das gut ist) NodeRed verwenden.
- Oder ähnlich wie in OpenHAB.
- ... gerne textbasiert & funktioniert
- wenn web/app/...-basiert gerne auch, Hauptsache funktioniert.
Föderation Subsystem:
- Nutzer validieren
- Rollen eines Nutzer auslesen koennen
- Alle (fuer den jeweiligen Server sichtbaren) Rollenbeschreibungen auslesen koennen
- Rollen sind immer lokal, koennen aber auf eine remote gruppe gemapt werden, i.e. als diese equivalent gesetzt werden
- Remote user die in einer remote role sind kriegen damit trotzdem lokale roles
Über das Bootstrap Interface können mehrer Verbindungen aufgemacht werden.
Föderated Sachen sind immer authentifiziert über ein Zertifikat.
Audit Log
15.01.2021 // Maschinenlist - D,A,CH
Maschinenlist - D,A,CH
Hier können die verschienden genutzten Maschine je FabLab eingetragen werden.
Den FabLab Namen bitte als Überschrift einfügen.
BHT
FVM-Labor / FabLab
Art | Hersteller | Typ/Bezeichnung | Anschluss | Besonderheiten |
---|---|---|---|---|
Werkzeugfräse | Mikron | WF31DE | 16A, 3phasig | eine Phase reicht. Evtl. spannend, die Maschine mit Überwachung/Steuerung einer Absauganlage / Kühlmittelpumpe zu ergänzen. |
Drehbank | Leinen | MLZ | 16A, 3phasig | eine Phase reicht. |
Wasserstrahl | Flow Systems | FlowJet | 64A?, 3phasig | eine Phase reicht. Evtl. Kühlwassersteuerung automatisieren. |
Senkerodieranlage | Mitsubishi | J80 | 32A, 3phasig | eine Phase reicht. |
Dampfphasen-Lötanlage | IBL | --- | 16A, 3phasig | Vorlaufzeit ca. 30 min. Nachlaufzeit einige Stunden. Sollte mit dem Kühlaggregat gekoppelt werden (Kühlung springt mit Maschine an, Maschine lässt sich nicht ohne Kühlung betreiben). Wassersteuerung integrieren. |
Multilayer-Presse | HML | --- | 16A, 3phasig | Sollte mit dem Kühlaggregat gekoppelt werden. |
Präzisionsbohrfräse | Klingelnberg | Alpha 01l | 16A, 3phasig | Sollte mit dem Kühlaggregat gekoppelt werden. |
Bestückautomat | Mydata | TP9 | SchuKo | |
Bestückautomat | ATN | InoPlacer | SchuKo | |
Leiterplattenfräse | LPKF | ProtoMat S62 | SchuKo | |
Metallsäge | ... | ... | SchuKo | Sichern |
Bohrmaschine | Maxion | Unimax 1 Frequenz | SchuKo | Sichern |
Bohrmaschine | Flott | --- | SchuKo | Sichern |
Galvanik-Anlage | Bungard | --- | SchuKo | Sichern |
Galvanik-Anlage | Englert | --- | 16A, 3phasig | Sichern |
Werkzeugwagen | Perschmann | --- | nur Ausleihe | Evtl. Bild-Station / Waage / ... für Rückgabe bauen. |
Löt-Tische | Weller / JBL / ... | verschieden | Tisch-Stromleiste | verhindern, dass einfach am Nachbar-Tisch angeklemmt wird? |
09.12.2020 // Punkte Chaostreff Potsdam
- props für Performance als Requirement
wir müssen man bei den Schweizern nachfragen, wie es bei denen steht
modify permissions on the fly
Meldesystem für defekte Maschinen
PiImage für FabAccess
An Konferenz im Oktober teilnehmen
06.12.2020 // Transcript Test Meeting
Tasso (Laborleiter) aus dem Labor in der Uni soll ein FabLab werden.
Schöne Geschichte: 2016 wollte Tasso eine FabLab bauen, Idee durch Makerfaire
Was ist ein FabLab? Ein Fabrication Laboratorie, nach der Idee von Nile Gerschenfield vom MIT (2005), Studenten soll die Maschine bedinenen können, um so Mitarbeiter für das Forschungsprojekt zu haben. How to make allmost anything, war der Name des Kurses Durch diesen Kurs trafen sich verschiendenste Studenten, die nicht geahnte Projekte umsetzten.
2007 Konzept für FabLab erstellt.
Wir wollen an der Beuth studierende nach diesem Konzept ausbilden.
In Tassos Labor steht eine Drehbank, nach der Idee von Niel Gerschenfiled sollen Studierende autoditaktisch den Umgang mit dieser Machiene lernen. Das ist ein anderer Ansatz als früher mit 3 Jahre Ausbildung, dabei hat man den Umgang mit der Maschine unter Aufsicht erlernt. Tasso mangelt es an 5 Werkstattmeistern, die darauf achten, dass sich die Studierende nicht weh tun. Bei 25 bis 28 Studenten im Labor und dann nicht alle in einem Raum, dadurch kann nicht gesteuert werden, wer die Drehbank ein und ausschaltet. Dadruch wurde ein Schütz an die Drehbank geklemmt, mit einem ESP8266. Um die Maschine mit WLAN ein und aus zuschalten. Mit MQTT und OpenHAB. OpenHAB ist eine Smart Home software, die mit Logik aktoren und Sensoren verbindet. Der Nachteil von OpenHAB ist, dass jeder der im gleichen Netzwerk wie die Drehbank ist, kann jede Maschine ein und ausschalten. Eine Drehbank aus der Ferne ein und auszuschalten ist gefährlich. Die Drehbank ist eine gefährliche Maschine, wenn man nicht eingewiesen ist, wird aber in einem FabLab benötigt.
2018 und 2019 gab es Leute mit FabLabs die sich in der Uni Siegen getroffen haben. Tasso fragt in die Runde ob wer das selbe Problem hat und ob jemand an einer Steuerungssoftware arbeitet. Darauf haben sich 2 (von 25) Leute gemeldet, die daran arbeiten, mit einem Prototyp. Nach weiteren Rückfragen stellte sich raus Work for Me. 2019 die gleiche Frage 8 Leute melden sich von 80 Leuten, auf die Frage wer das veröffentlichen möchte, gingen die Hände wieder runter. Tasso hat darauf hin die Vernetzung dieser Gruppen übernommen. 12-13 Projekt, keines Fertig. Klingt einfach ist ja nur Maschine ein und ausschalten, also nur 1 Bit. 2019 der Verband der offenen Werkstätten hat sich als nächstes Projekt gemeldet. Also sollte man eine solche Software nicht nur auf Hochschule beschränken, sondern auch externe FabLabs einbinden. Darauf hin fiel das Stichwort Fereation. Das macht es richtig kopleziert. Novemeber bis Februar wurden viele Calls abgehalten um das alles mal zu sammeln. Gregor wollte das alleine schreiben. Tasso meinte das noch mehr gebruacht werden. Joseph ist dann durch längere Aufenthalte im Labor bei den Meetings dabei gewesen. Kai und Janis haben sich druch die Suche nach Team Mitglidern für den Prototypefunde dazugefunden. Jannis hat zum Go lernen Projekt nummer 15 Eröffnet. Und Gergor hat mir einem QR-Code system Projekt nummer 16 gestartet. Durch den Verband der offenen Werkstätten hat sich der Kontakt und die Idee mit dem Prototypefund ergeben. Daruch wurde Projekt nummer 17 gegründet.
Dadruch wurde einmal alle Anforderungen an das Projekt zusammen getragen, also an das "Core Team" und alles was Tasso noch wusste. "Core Team" (12 Leute) ist ein Teil von 45 Leuten, die sich für das Projekt interessieren und es umsetzten wollten und können. Daraus wurde ein Lastenheft gegossen. Mit einer Anforderungsliste.
RFID Karten - Smartcards Maschine sicher schalten Einfache Machinen abbilden - Es ist egal ob eine Machine ein Drehbank oder ein Schraubenzieher ist, wenn ich die Nutze ist die nicht mehr da. Daruch kann man sehen ob ein Tisch benutzt wird oder nur zumüllt und man den abräumen kann. Maschine als Admin auch nutzten, wenn ein anderer die Maschine gerade "nutzt". Override ist, dass die Maschine auch geht, wenn unser System offline ist. Also wenn BFFH - Diflourboran, also etwas was man nicht bei Google findet. Das ganz soll auf eine Pi laufen können. Unsere Client - Borpin
Zum Konzept Use Cases Die Idee ist, dass du als neuer Nutzer in FabLab kommst und dann die Frage stellst, was muss ich hier tun, damit ich die Maschinen nutzten darf. Aktuell würdest du dir einen Admin suchen, der lässt dich dann einen Vertrag unteschreiben. Also "Leihverträge" ... (nicht so wichtig) Dadurch kannst du jetzt an eine Drehbank gehen und diese einschalten, auch wenn du davon keine Ahnung hast. Dadruch muss der Admin immer genau schauen wer was macht und diese Arbeit soll weg automatisiert werden, damit Tasso mehr Zeit für andere Dinge hat.
Mit unserem System: Als neuer Nutzer kannst du dich über Borpin registrieren und unterschreibst dann einen Vertrag, dann wirst du vom Admin freigeschaltet und bekommst deine SmartCard. Dann darft du erstmal nichts tun, außer unrestricted Maschine nutzten (schraubenzieher) Mit deiner SmartCard kannst du jetzt an eine Maschine gehen und dann wird dir gesagt, dass du nicht nutzten darfst ohne Einweisung. Also musst du zu Tasso gehen und dir eine Einweisung geben lassen. Ab jetzt darfst du die Maschine frei nutzten und Tasso ist aus seiner Sicherungspflicht entbunden. Wir machen dann den Strom ein und aus für diese Maschien, wenn du deine Karte auf den Reader legst.
Abrechnungen ist ein Feature was gefordert wurde, aber wir nicht sofort leisten. Man soll minutengenau deine Maschinen nutzung abrechen.
Studenten chippen ;)
Föderationskonzept Die Zusammenarbeit von Organisationen kann in Form einer Föderation erfolgen, die wie eine politische Föderation organisiert ist: Die Organisationen behalten ihre Eigenständigkeit und arbeiten gleichberechtigt und weitgehend autonom bei der Erreichung gemeinsamer Ziele zusammen.
Es gibt das Konzept, das man einfach aus zwei Makerspaces eines macht, mit zwei standorten. Das ist nicht so schön.
Durch die Föderation ist es möglich Nutzer zwischen den FabLabs auszutauschen. Das heißt Nutzer die bei Tasso in die Benutzung der Drehbank eingewiesen wurden, da kann Joris in seinem Space der die gleiche Drehbank hat und Tassos Einweisungen vertraut, diesen Nutzer bei sich auch erlauben die Drehbank zu benutzten.
Die Föderation kann auch auf die Abrechnung ausgeweitet werden. Also wenn du als Nutzer von Tasso bei Joris die Drehbank nutzt, dann muss nicht Joris dir dafür eine Rechnung schreiben, sondern dann kommt das durch Tasso. Tasso und Joris müssen dann nur noch die jeweilige Differenz der Beträge überweisen.
Die Föderatoin hat 3 Stufen:
- Nutzer können bei anderen Spaces Ihre Karte wiederverwenden. Alos SSO mäßig. Also bei der Einrichung der Föderation ist das der erste Schritt.
- Berechtigung können zwischen den Spaces geteilt werden.
- Finanzierung, dass kommt erst später
Zu den SmartCard. In normal Fall liegt auf der SmartCard eine verschlüsselte Datei. Wenn du die Datei entschlüsseln kannst, dann ist die Karte Authentifiziert. Also bei MIFARE Classic Karten benötigt der Reader den Schlüssel, um die Datei zu entschlüsseln. Bei DESFire Karten kann die Funktion von OTA genutzt werden. Das heißt, die Kommunikation mit der Karte erfolgt direkt und verschlüsselt zwischen Reader und dem Server selber. Metro Karten nutzten, das zum Beispiel, wenn sie auf der Karte einen Betrag speichern, so kannst du über dein Handy diese Karten aufladen. Dadurch braucht der föderierte Space keine Schlüssel für die Karten des anderen Spaces. Bei DESFire wird ein Session Key generiert, dadurch kann keine Replay Attacke verwendet werden. Durch diese Anforderung haben wir uns für DESFire entschieden. DESFire Karten kosten nur 1€ im Einkauf. SmartCards sind Beständiger gegen Dreck und eignen sich daher besser in FabLabs. Auf den SmartCards sind öffentlich dein Username (kann pseodonimisert werden) und der Space zu dem du gehörst. Also ein DNS Host Adresse.
Nutzertracking Für die Abrechnung wird es benötigt. Aber für den normalen Betrieb wird kein Log benötigt, in dem der Admin sehen kann wer wann welche Maschine benutzt hat. Allerdings wäre es sinnvoll den letzten Nutzer zu speichern, damit man bei Beschädigung den Verursacher ermitteln kann. So kann der neue Nutzer beim Begin der Nutzung feststellen, dass er die Maschine nicht beschädigt hat. Und der Admin dem entsprechend handeln kann.
Unser System soll auch für Schließsystem verwendet werden, die Versicherung lässt grüßen. Daher sollte man schon loggen, wann welcher Nutzer durch diese Tür gegangen ist, um so Diebstähle nachvollziehen zu können.
Maschinen sind generich implementiert, also kann man als Betreiber jeden Aktor verwenden, für den man unsere API implementiert hat.
Wir bauen für das Scannen eine Reader Kit zur Verfügung zum Nachbauen.
Bei Türschlössern geht es uns um den Datenschutz, also wir würden das am liebsten garnicht einbauen.
Leihs ist ein anderes Thema.
Wir haben Sticker im eine Wiedererkennungswert um Maschinen scannen zu können. Das kann auch als Ausleihsystem verwendet werden. Maschinen sollen über NTAG oder QR Code gescannt werden. So kann unser System auch für Anleitungen verwendet werden.
Odoo soll über unser Audit Log gefüttert werden. Odoo ist ein ERP System
Uber das Audit Log können die aktuellen Ereignisse ausgelesen werden. Daruch kann eine Abrechnung erstellt werden.
Reservieren von Maschinen soll möglich sein. Wir wollen kein Schedule Plan für eine Maschine erstellen und verwalten. Machinen Watching wäre im Client sinnvoll. Maschinen sollen nur für einen bestimmten Zeitraum reserviert werden, also für den Weg zu Space nicht von wem anders für 5 Studen genutzt wird. Da Maker nicht plaungsorientiert arbeitn, sondern Impuloriertier, sehen wir nicht die notwendigkeit Reservierung für die nächste Woche vornehmen zu müssen. Außerdem sollen Maschinen nicht blockiert werden, durch solche Reservierungen. Bei einer Reservierung kann ein Admin auch die Maschine an wen anderes übergeben oder selber nutzten. Und es dauert immer länger, wenn jemand eine Maschine verwendent, da man nicht alles genau weiß wie lange es dauert. Und es soll auch nicht auf das Aufräumen verzichtet werden. Maschinen können auch mit einer Abnahme erst wieder Verfügbar gemacht werden.
Wir können kein Zeitmanagment nicht leisten für alle Space Nutzer.
Reservierung sollte ein Cooldown haben, damit man nicht direkt wieder Reservieren kann.
Ldap ist nicht so wichtig
Space API und FabLabs.io ...
01.12.2020 // Zusammenfassung - Freies Meeting
Um einen Überblick für unser Projekt zu erarbeiten haben wir ein Meeting mit einer externen Person durchgeführt. Dabei war das Ziel unser Projekt jemanden ohne Vorkenntnisse zu erklären und verständlich zumachen, somit mussten wir alle Punkte die unser Projekt betreffen ansprechen. Aus den Aufnahmen wurden folgende Punkte zusammengefasst. Mit diesen Punkten soll eine Präsentation für die Vorstellungen unseres Projekts erarbeit werden.
24.11.2020 // Webseiten Text
FabAccess
Unsere Core Features
Föderation
- Schließe dich mit anderen FabLabs zusammen, so können eure Nutzer beliebig zwischen eueren Spaces wechseln Wenn du mit einem Space Föderieren möchtest bieten wir dir 3 Stufen an:
- Nutzer aus dem anderen Space können ihre Karte auch bei dir verwenden
- Nutzer sind bei dir Registriert, der Föderierte Space übernimmt die Authentifizierung für dich. (wie bei SSO)
- Nutzer aus dem anderen Space können ihre Karte und ihre Gruppen auch bei dir verwenden
- Nutzer sind bei dir Registriert, wie bei 1. und du kannst die Gruppen des anderen Space bei dir Verwenden, wenn du zum Beispiel die gleichen Maschinen hast. Das spart Zeit bei der Einweisung und du und der andere Betreiber müsst nicht alles doppelt und dreifach erklären.
- Nutzer aus dem anderen Space können ihre Karte und ihre Gruppen auch bei dir verwenden. Die Abrechung für diese Nutzter übernimmt dabei der andere Space für dich.
- So musst du dich nicht um die Abrechung für externe Nutzer kümmern. So kannst du und andere Space zum Beispiel gesammlete monatliche Differenzrechnungen abrechnen. Das spart Zeit bei der Buchführung und deinen Nutzer können auch Ihre Rechnungen besser im Blick behalten.
Maschinenverwaltung
- Verwalte wer deine Maschinen beutzten darf und verhindere uneingewiese Nutzung
Nutzerverwaltung
- Behalte deine Nutzer immer im Blick, sogar wenn du mit anderen Spaces föderierst
SmartCard
- Gib deine Nutzern eine SmartCard in die Hand, damit nur deine Nutzer deine Maschinen nutzten können
Self Hosted
- Du hostest FabAccess selber und kannst dich trozdem mit anderen Spaces zusammenschließen
Automatisiere deine Verwaltung
- Bestimme wann man Maschinen nutzten darf oder schalte alle Maschinen gleichzeitig ab
Erweiterbarkeit
- Möchtest du eigene Hardware zum erkennen oder schalten verwenden, dann erweitere FabAccess einfach mit ein paar Zeilen Code
Features
- User Federation
- Maschinenverwaltung
- Rechteverwaltung
- SmartCard
- Automatisierung
- Open Source
- User Managment
- Self Hosted
- Intuitive Interface
- Designed for Security and Privacy
- Einfach erweiterbar
18.11.2020 // Stellenausschreibung - SHK
Wir suchen Unterstützung für unserer Projekt "FabAccess"
Wer sind wir und was tun wir?
Wir sind eine Gruppe von Studierenden, die in Zusammenarbeit mit Betreibern und Mitarbeitern von FabLabs und Makerspaces, Software und Hardware zur Automatisierung der Verwaltung erarbeiten und umsetzen.
Wir arbeiten seit September an der Umsetzung des ersten Projekts "FabAccess". Durch dieses soll der Zugriff und die Steuerung von Maschinen automatisiert werden.
Für diese Umsetzung brauchen wir Unterstützung. Wir haben mehrere Aufgaben, die wir im Rahmen einer studentischen Hilfskraftsstelle auszuschreiben.
Leider können wir nur eine Person engagieren. Für eine Bewerbung wähle eines der Themen aus und bewirb dich darauf bei uns.
Du findest uns unter fab-access.org
Schicke uns deine Bewerbung an contribute@fab-access.org
1. Python API Library
Wir schreiben unsere eigene API in Cap'n Proto für unseren Server. Dafür benötigen wir jemanden, um für die API eine Python Library zu schreiben, um damit Befehle an unseren Server zu senden oder Daten davon abzurufen. Hierfür würden wir gerne die APIs von FabLabs.io und SpaceAPI.io anbinden, um automatisiert die Ausstattung und den Öffnungsstatus des FabLabs an diese Seiten zu übermitteln.
Skills:
- Python
- JSON-API
- Git
- Selbstständiges Arbeiten
2. Rust ABI Anbindung
Wir schreiben unsere eigene ABI zum Anbinden von verschiedene Sensoren und Aktoren, um diese dann über unseren Server zu steuern. Hierfür würden wir gerne unser Sortiment an unterstützen Sensoren und Aktoren erweitern. Wir suchen jemanden, um für folgende Aktoren und Sensoren eine Anbindung zu implementieren:
- Nuki Türschlösser
- Shelly Smart Plug
- Tasmota
Skills:
- Rust
- Git
- Selbstständiges Arbeiten
16.11.2020 // Themen für eine SHK Stelle
Python
FabAccess-API in Python -> damit SpaceAPI.io oder FabLabs.io anbinden Package das erweiterbare Abstraktion für unsere API liefert Program das damit dann SpaceAPI.io & FabLabs.io füttern geht
- Networking
- Python
- Cap'n Proto
Accounting anbinden
- Nutzungsdaten-CSV Beispielprogram
C#
=> UI bauen (Xamarin)
- Teamfähigkeit
- Erreichbarkeit
- Kommunikation
- GTK ?
C# + Rust
Authentifizierung
- GSM
- OTP
- YubiKey
Jeweils PoC Implemtentation in BFFH(Rust) und eventuell in Borpin(C#) und eventuell PoC Reader(C/C++)
Rust
=> Sensoren + Aktoren
- Nuki Türschlösser
- Shelly Smart Plug
- Tasomta
- etc.
=> SQL/LDAP Adapter für Nutzer etc.
Elektrotechnik
- Drehstrom schalten
- Moralisch vertretbar als Box zu "verkaufen"
- WLAN + LAN
- MQTT
- Firmware mit SensorAPI/AktorAPI
C/C++
generische Firmware STM32 ESP32
19.10.2020 // How to Prototype Fund
Was ist zu tun, wenn das Finanzamt die Tätigkeit als gewerblich eingestuft hat?
Solange noch keine Steuernbezahlt wurden kann das Finanzamt die Einstufung der Tätigkeit als gewerblich noch zu freiberuflich ändern. Dafür soll eine Nachricht, in der steht, dass man der Meinung ist, dass es sich hierbei um eine freiberufliche Tätigkeit handelt und eine Begründung dazu, sowie ein entsprechender Nachweis. Für die Prototype Föderung wäre das der Zuwendungsbescheid des DLR.
Leider ist das Finanzamt öfferts der Meinung, dass es sich bei freiberufliche n Tätigkeit um folgende handelt:
Freiberufler arbeiten selbstständig und eigenverantwortlich. Ihre Tätigkeit kann erzieherischer, schriftstellerischer, unterrichtender oder wissenschaftlicher Natur sein.
Dabei wir die Ausbildung für die Tätigkeit vorrausgestzt. Da man die Tätigkeit als Software Entwickler aber auch ohne abgeschlossene Ausbildung ausführen kann. Gibt es Gerichtsurteile, die die Tätigkeit als "Autodidakt" in IT Berufen anerkannt haben.
16.10.2020 // Contribute - Borepin
Contribute - Borepin
On Windows
- Install Visual Studio 2019
download Visual Studio
- with Xamarin
- with UWP
- with .NET Desktop
- Install GTKSharp for Windows download GTKSharp
- Clone Borepin download Borepin
- Load Borepin
- Build Borepin
If Step 5. Build Borepin is failing because of GTKSharp, it could help to restart your PC.
Build GTK Project
-
Install mono, gtk-sharp, msbuild, nuget 1.1 Debian based
$ apt install mono-complete, gtk-sharp2, nuget
1.2 ArchLinux based
$ pacman -S mono, mono-msbuild, gtk-sharp-2, nuget
-
Clone Borepin
$ git clone https://gitlab.com/fabinfra/fabaccess/client.git
-
Build Borepin
$ cd client $ msbuild -t:Borepin_GTK
-
Run Borepin
$ mono ./Borepin/Borepin.GTK/bin/Debug/Borepin.GTK.exe
You can also use Rider or monodevelop as an IDE for development on Borepin
Testing
We use NUnit for testing.
15.10.2020 // Team-Meeting 15.10.2020
tags: Meeting
Themen
-
Studenzettel
-
Audit Log Joris wollte wissen, wie das aussehen wird, damit er das mal an seine ERP Software anbinden kann. Eine Erweitung von SysLog EventLog maschinenlesbar
-
FabReader
- TLS mit fixen Key
- Key wird über eine Master-Card ausgestellt
- JSON ist fertig Joris schickt uns ein Exemplar zu zum testen
-
NFC Lib
- Protieren nach Rust
- PICC ChangeKey fehlt noch
- CMAC ist noch nicht implementiert
- Testing muss nachgezogen werden
-
Capt'n Proto API
- Funktioniert der Vorschlag auf GitHub
- Was muss noch getan werden
Tagets:
- C++ / Python
- C#
- Rust
- Haskell
-
Kooperationsvertrag Mail an Lewkowicz
-
PrePaid Gregor kümmert sich.
-
Coaching Montag Meeting nachfragen
13.10.2020 // DESFire Protokoll
Müssen wir uns mal anschauen, da die das können, was wir wollen
Links
-
DESFire Commands sind nur unter NDA verfügbar.
-
Easypay DESFire Lib - sehr brauchbar
Bytes
APDU Commands
- SELECT = 00 a4 04 00 07 d2 76 00 00 85 01 00 00
- VERSION = 90 60 00 00 00
- CONTINUE = 90 AF 00 00 00
APDU Responses
APDU responses will first contain the data followed by two status bytes.
- FRAME_CONTINUE = 91 AF
- OPERATION_OK = 91 00
- OK = 90 00
- INIT = ??
- VERSION 1 = 04 01 01 01 00 1a 05
- VERSION 2 = 04 01 01 01 03 1a 05
- VERSIOn 3 = 04 91 3a 29 93 26 80 00 00 00 00 00 39 08
Instructions DESFire (used inside ADPU)
CLA = 0x90 APDU Sturuktur -> ISO/IEC 7816-4 Befehle -> DESFire
- 0x0A = AUTHENTICATE
- 0x1A = AUTHENTICATE_ISO
- 0xAA = AUTHENTICATE_AES
- 0x71 = AUTHENTICATE_EV2_FIRST (EV2 only)
- 0x77 = AUTHENTICATE_EV2_NONFIRST (EV2 only)
- 0x54 = CHANGE_KEY_SETTINGS
- 0x5C = SET_CONFIGURATION
- 0xC4 = CHANGE_KEY
- 0x?? = CHANGE_KEY_EV2 (EV2 only)
- 0x?? = INITIALIZE_KEY_SET (EV2 only)
- 0x?? = FINALIZE_KEY_SET (EV2 only)
- 0x?? = ROLL_KEY_SET (EV2 only)
- 0x64 = GET_KEY_VERSION
- 0xCA = CREATE_APPLICATION
- 0x?? = CREATE_DELIGATE_APPLICATION (EV2 only)
- 0xDA = DELETE_APPLICATION
- 0x6A = GET_APPLICATION_IDS
- 0x6E = FREE_MEMORY
- 0x6D = GET_DF_NAMES
- 0x?? = GET_DELIGATE_INFO (EV2 only)
- 0x45 = GET_KEY_SETTINGS
- 0x5A = SELECT_APPLICATION
- 0xFC = FORMAT_PICC
- 0x60 = GET_VERSION
- 0x51 = GET_CARD_UID
- 0x6F = GET_FILE_IDS
- 0xF5 = GET_FILE_SETTINGS
- 0x5F = CHANGE_FILE_SETTINGS
- 0xCD = CREATE_STDDATAFILE
- 0xCB = CREATE_BACKUPDATAFILE
- 0xCC = CREATE_VALUE_FILE
- 0xC1 = CREATE_LINEAR_RECORD_FILE
- 0xC0 = CREATE_CYCLIC_RECORD_FILE
- 0x?? = CREATE_TRANSACTION_MAC_FILE (EV2 only)
- 0xDF = DELETE_FILE
- 0x61 = GET_ISO_FILE_IDS
- 0xBD = READ_DATA (manchmal auch als 0x8D beschrieben)
- 0x3D = WRITE_DATA
- 0x6C = GET_VALUE
- 0x0C = CREDIT
- 0xDC = DEBIT
- 0x1C = LIMITED_CREDIT
- 0x3B = WRITE_RECORD
- 0xBB = READ_RECORDS
- 0xEB = CLEAR_RECORD_FILE
- 0x?? = UPDATE_RECORD_FILE
- 0xC7 = COMMIT_TRANSACTION
- 0xA7 = ABORT_TRANSACTION
- 0xAF = CONTINUE
- 0x?? = COMMIT_READER_ID (EV2 only)
Instructions ISO/IEC 7816-4 (nativ, aber von DESFire unterstützt)
CLA = 0x00 APDU Sturuktur -> ISO/IEC 7816-4 Befehle -> ISO/IEC 7816-4
- 0xA4 = SELECT FILE
- 0xB0 = READ BINARY
- 0xD6 = UPDATE BINARY
- 0xB2 = READ RECORDS
- 0xE2 = APPEND RECORD
- 0x84 = GET CHALLENGE
- 0x88 = INTERNAL AUTHENTICATE
- 0x82 = EXTERNAL AUTHENTICATE
Instruction ISO 14443-3
Status Codes
from https://github.com/JavaCardOS/pyResMan/blob/master/pyResMan/DESFireEx.py#L54 which, has it from https://github.com/jekkos/android-hce-desfire/blob/master/hceappletdesfire/src/main/java/net/jpeelaer/hce/desfire/DesfireStatusWord.java
- 0x00 = OPERATION_OK Successful operation
- 0x0C = NO_CHANGES No changes done to backup files, CommitTransaction / AbortTransaction not necessary
- 0x0E = OUT_OF_EEPROM_ERROR Insufficient NV-Memory to complete command
- 0x1C = ILLEGAL_COMMAND_CODE Command code not supported
- 0x1E = INTEGRITY_ERROR CRC or MAC does not match data Padding bytes not valid
- 0x40 = NO_SUCH_KEY Invalid key number specified
- 0x7E = LENGTH_ERROR Length of command string invalid
- 0x9D = PERMISSION_DENIED Current configuration / status does not allow the requested command
- 0x9E = PARAMETER_ERROR Value of the parameter(s) invalid
- 0xA0 = APPLICATION_NOT_FOUND Requested AID not present on PICC
- 0xA1 = APPL_INTEGRITY_ERROR Unrecoverable error within application, application will be disabled
- 0xAE = AUTHENTICATION_ERROR Current authentication status does not allow the requested command
- 0xAF = ADDITIONAL_FRAME Additional data frame is expected to be sent
- 0xBE = BOUNDARY_ERROR Attempt to read/write data from/to beyond the file's/record's limits. Attempt to exceed the limits of a value file.
- 0xC1 = PICC_INTEGRITY_ERROR Unrecoverable error within PICC, PICC will be disabled
- 0xCA = COMMAND_ABORTED Previous Command was not fully completed Not all Frames were requested or provided by the PCD
- 0xCD = PICC_DISABLED_ERROR PICC was disabled by an unrecoverable error
- 0xCE = COUNT_ERROR Number of Applications limited to 28, no additional CreateApplication possible
- 0xDE = DUPLICATE_ERROR Creation of file/application failed because file/application with same number already exists
- 0xEE = EEPROM_ERROR Could not complete NV-write operation due to loss of power, internal backup/rollback mechanism activated
- 0xF0 = FILE_NOT_FOUND Specified file number does not exist
- 0xF1 = FILE_INTEGRITY_ERROR Unrecoverable error within file, file will be disabled
Files
Not shure yet what these constants do.
crypto operations
- TDES = 00
- TKTDES = 40
- AES = 80
File types
- STANDARD_DATA_FILE = 00
- BACKUP_DATA_FILE = 01
- VALUE_FILE = 02
- LINEAR_RECORD_FILE = 03
- CYCLIC_RECORD_FILE = 04
Transmission modes
- PLAIN_COMMUNICATION = 00
- PLAIN_COMMUNICATION_MAC = 01
- FULLY_ENCRYPTED = 02
Getestet Reader und Treiber
ACS ACR122U-A9 | Microsoft Usbccid-Smartcard-Leser (WUDF) | Windows 10
13.10.2020 // Mitschnitt - OTA Proof-of-Concepts
connected
send 901a0000010000
recv a1bf8c11e96c9e4491af
RndA: eba87149d88ced0d
send 90af000010e055e9553cbfd8ae34cb7e0b9051bd4e00
recv 83ee10665e78da619100
send 90fc000000
recv 56730aec09169b2e9100
send 901a0000010000
recv 18e7f105cdfc574291af
RndA: 0278d460c6aa4af4
send 90af000010ac299e117b1c7eeb8984737978c546a800
recv b36cebe94cee71799100
session_key: 0278d46084f2ccea
iv: 0000000000000000
send 90ca000005eeffc00b8300
recv 89bad4f6f92dbc479100
session_key: 0278d46084f2ccea
iv: 0000000000000000
send 905a000003eeffc000
recv 9100
send 90aa0000010000
recv eda2aa1582cc7252d9bf19a330d4a9d191af
RndB_Enc: eda2aa1582cc7252d9bf19a330d4a9d1
RndB: 482ddc54426e6dee560413b8d95471f5
RndA: bc14dfde20074617e45a8822f06fdd91
send 90af0000207c2f74c3df09a484fc71e6e19b5ba3523a69b853cd91c6d603a1d714d8c3784800
recv b704f5283f60a82869e9252732a9f6ae9100
RndA_Enc: b704f5283f60a82869e9252732a9f6ae
changing key #00 to 45eeb8338ae8f49a032e85bb11143530
hdr: c400
cmd: c40045eeb8338ae8f49a032e85bb1114353010
cryptogram: 45eeb8338ae8f49a032e85bb111435301095c3894b0000000000000000000000
session_key: bc14dfde482ddc54f06fdd91d95471f5
iv: 00000000000000000000000000000000
cryptogram_enc: c4dc9ae48dd8a8073f7f9e9159335f29d16637cf3db18f982180f0b4de5d7a86
send 90c400002100c4dc9ae48dd8a8073f7f9e9159335f29d16637cf3db18f982180f0b4de5d7a8600
recv 9100
send 90aa0000010000
recv 189aa068a47e2f21ec81b1bc39f719d891af
RndB_Enc: 189aa068a47e2f21ec81b1bc39f719d8
RndB: 44c29525f6e679c0fea16b44d1af57e7
RndA: 3a100d71772cbf182c307691bc63d9ea
send 90af000020cbe7fc1f24ba588eb6a6562f92d0d74d9acd7af44e70e300df24a47ce377894500
recv 9607d533b5e018e51e33eea26f2b0a379100
RndA_Enc: 9607d533b5e018e51e33eea26f2b0a37
changing key #01 to 8db1f942f2d7cc82f6fa1486a30f8c12
session_key: 3a100d7144c29525bc63d9ead1af57e7
iv: 00000000000000000000000000000000
send 90c400002101619db367d23d64798871530300f5802ea9d55be543569934f5c47382d9075fbe00
recv da11d391cae880d39100
session_key: 3a100d7144c29525bc63d9ead1af57e7
iv: 00000000000000000000000000000000
changing key #02 to 77611d170c449df6f294c48581ab315d
session_key: 3a100d7144c29525bc63d9ead1af57e7
iv: 00000000000000000000000000000000
send 90c40000210234dfb57fd4aa1958244b415d098f96c571e0adf96bb3a5a01cb41d605e3d32cc00
recv 301e8cc99fe418549100
session_key: 3a100d7144c29525bc63d9ead1af57e7
iv: 00000000000000000000000000000000
session_key: 3a100d7144c29525bc63d9ead1af57e7
iv: 00000000000000000000000000000000
send 90cc0000110103102000000000ffff0000000000000000
recv 9fe32c9db79aae139100
session_key: 3a100d7144c29525bc63d9ead1af57e7
iv: 00000000000000000000000000000000
session_key: 3a100d7144c29525bc63d9ead1af57e7
iv: 00000000000000000000000000000000
send 90cc0000110203102000000000ffff0000000000000000
recv 014f0d71b8b85ceb9100
session_key: 3a100d7144c29525bc63d9ead1af57e7
iv: 00000000000000000000000000000000
done
websocket connection closed
05.10.2020 // QR-Code/NTAG Identifizierung
Ziel
Ziel dieses Features soll es sein, eine Identifizierung von Gegenständen über QR-Codes zu ermöglichen (bsp.: zum Ausleihen von Werkzeug, benutzen von Tischen).
Es wird also nicht für jeden Gegenstand ein Card Reader benötigt, dies übernimmt dann Borepin auf dem Handy des Nutzers.
Es kann auch ein zentraller PC zum Ausleihen von Gegenständen bereitgestellt werden, der dann mit einer Kamera und einem NFC Reader ausgestattet ist über den die Nutzer dann das machen können. Dafür müssen keine Nutzerdaten auf diesem PC gespeichert werden, sondern der Nutzer nur seine Karte auf den Reader legen.
Auf dem QR-Code / NTAG wird eine UID + Domain gespeichert, so können auch Externe dieses System nutzten.
Bei der NTAG Verwendung kann über RFID Scanner Tore (Warensicherungsanlage) so auch Diebstahl verhindert werden.
05.10.2020 // Audit Log
tags: Feature
Ziel
Ziel dieses Features soll es sein, dass Änderungen im BFFH als Log über eine interne Schnittstelle ausgegeben werden und von dritten Anwendungen ausgewertet werden können (bsp.: zur Abrechnung).
An das Audit Log können eigene Komponenten angebunden werden, die dann mit den Daten zum Beispiel ein Odoo System zur Abrechung befüllen.
Die Verteilung könnte über einen MQTT Broker erfolgen ???
05.10.2020 // Kartenverwaltung
tags: Feature
Ziel
Ziel dieses Features soll es sein, dass jeder Nutzer eine eigene Smart Card erhält, mit der er sich an allen Endpunkten anmelden kann.
Als Kartenlösung verwenden wir Mifare DesFire EV2 Karten. EV2 Karten haben Rolling Keys. Die Kommunikation zu der Karte erfolgt nur zwischen Karte und BFFH (Backend), der Reader dient nur als Proxy. Je Nutzer können eine oder mehrere Karten hinterlegt werden. Die Karten können bei Verlust gesperrt werden. Der Space der die Karte ausgibt hat als einziger den Master Key der Karte und es wird nur eine Application mit eigenen Keys benötigt, somit können die Karten auch von anderen Systemen verwendet werden. Externe Spaces müssen keine eigenen Karten ausgeben, sondern die Nutzer können ihre Karte überall anmelden.
Die Karte wird als primäre Identifizierungs und Authentifizierungs Methode genutzt. Man benötigt kein Handy, um sich zu authentifizieren. Zur Authentifizierung wird die OTA Implementierung von Mifare DesFire verwendet. Dadurch erhält der Reader, also das Endgerät, keine Schlüssel für die Karte des Nutzers. Somit kann auch über einen entfernten Space die Karte authentifiziert werden, ohne das der lokale Space den Schlüssel benötigt.
Nutzer können Maschinen über diese Karte nutzen oder ausleihen.
FAQ
Warum verwendet ihr keine Mifare Classic Karten?
Aus Gründen Einfach Nein!
Wie werden neue Reader angemeldet?
Mit einer MASTER Karte werden die READER authentifiziert und erhalten darauf ein Zertifikat vom Server womit jede weitere Kommunikation authentifiziert wird.
Reader authentifiziert sich mit einem TLS Two-Way Handshake gegenüber dem BFFH.
Was steht auf der MASTER Karte?
Es gibt zwei Möglichkeiten
Muss
- Karte enthält ein Zertifikat
- Domain für BFFH (Steht auch im Zertifikat)
- Zertifikat mit dem der Reader sich anmelden kann
- Karte dient als Authentifizierung
- Domain für BFFH
- Karte kann sich authentifizieren
Welche Verschlüsselung verwenden wir für die DESFire Karten?
AES
01.10.2020 // Kooperationsvertrag
Kooperationsvertrag
- Server Housing mit ungeblockter IP
- Zugang zum FVM Labor
- Hardwarenutzung des FVM Labors
28.09.2020 // Prototypefund Monday Update - 28.07.2020
tags: MondayUpdate
FabAccess
Done:
- Update Website
- More NFC Lib implemented
Doing / Plan to do this week: Server:
Client:
- Implement Card Actions with NFC Lib
- Add Linux and Android Support for NFC Lib
Infrastructure:
- Xamarin Build Server
Challenges:
Motivation:
- More Feedback and Support from our Community
21.09.2020 // Prototypefund Monday Update - 21.09.2020
tags: MondayUpdate
Done:
- NFC PoC fnished
- Setup CI Infrastructure
- Automated testing and linting of server
- Automated builds of client on Windows, Android, iOS
- first actuator implemented and tested (shelly)
- intern database implemted
Doing / Plan to do this week: Server:
- define full API, for the Client and Server communication
Client:
- write more on NFC Lib
- test OTA with the NFC Lib
Infrastructure:
- finish CI setup for Linux and macOS
- survey for the "Verband der offenen Werkstätten", if all of our design descissions are aceptable
Challenges:
- US Export Administration Regulations for Crypto in Apps
Motivation:
- question from "Verband der offenen Werkstätten": When will you finish?
- all PoCs work
21.09.2020 // Tooling für das FabAccess Team
Kommunikation
Wie wird untereinander kommuniziert?
Konferenzen
Chat
- Rocketchat
- Zulip
Filesharing
Wie werden Dateien ausgetauscht?
Large Data
- Nextcloud
Code
- GitLab
Creating
Wie wird gemeinsam an neuen Ideen gearbeitet?
Text Based
- Hackmd
- Codimd
Visual Based
- Lucidchart
- Miro
Projektplaung
Wie werden Aufgaben und Anforderungen geteilt?
Projektplanung
- GitLab
- Basecamp
Aufgabenplanung
- GitLab
- Basecamp
Kalender / Zeitplanung
- GitLab
- Nextcloud
- Basecamp
Dokumentation
Wie wird dokumentiert?
allgemeine Dokumentation
- GitLab
Code-Dokumentation
- ???
Website
- GitLab
07.09.2020 // Monitoring
tags: Feature
Ziel
Ziel dieses Features soll es sein, dass der Zustand jeder Maschinen überwacht werden kann.
Die Zustände der Maschinen sind öffentlich einsehbar oder nur für registierte Nutzer. Der Nutzer kann so erkennen, ob eine Maschine belegt ist. Der Betreiber kann sehen wer die Maschine gerade nutzte und von wem sie als letztes benutzt wurde. Grafana Template bereitstellen. Nur Betreiber können den Nutzer sehen.
Performance/andere Metriken aus BFFH exportieren Öffentliche Metriken für Prometheus exportieren.
Alle Maschinen Einträge und deren Spezifikation sind öffentlich einsehbar und können an fablabs.io übertragen werden.
07.09.2020 // Nutzungs- / Nutzerverwaltung
tags: Feature
Ziel
Ziel dieses Features soll es sein, das Nutzer über das BFFH verwaltet werden können und diese Berechtigungen erhalten.
05.09.2020 // Gespräch mit Joris 05.09.2020
- ESP32 wird er einbauen
- DesFire OTA schaut er sich an
- Bisher mit Mifaire Ultralight C probiert
- Domain findet er sinnvoller als nur UUID
- RC522 Hack um die Sendeleistung zu erhöhen
- Es wäre auch ein Zahlenpad möglich
- Er wird die längeren Aktivierungszeite testen
- DesFire ev2 würden wir dann verwenden
- v2 könnte mit einem E-Ink Display werden
- Authentifizierung von Readern sollten wir einbauen, um im Notfall Mifaire Classic Systeme besser zu schützten auch Föderationsübergreifend
05.09.2020 // Features zur Diskussion
tags: Feature
- Box zum Karten zurückgeben, wobei der Besitzer der Karte benachrichtigt wird, dass seine Karte zurück gegeben wurde.
04.09.2020 // Offene Fragen
tags: Questions
Welche Systeme gibt es bereits? Wie sind solche System aufgebaut?
04.09.2020 // Föderation
tags: Feature
Ziel
Ziel dieses Features soll es sein, dass FabLabs untereinander föderieren können, ohne ein gemeinsamme FabAccess Instanz zu nutzten.
04.09.2020 // Maschinenkontrolle
tags: Feature
Ziel
Ziel dieses Features soll es sein, dass Maschinen über das BFFH ein und aus geschaltet werden können, sowie ihren jeweiligen Status melden können.
04.09.2020 // Föderartions Konzept
Wie wird die Berechtigungsfreigabe für Maschinen in andere FabLabs übergeben? Gibt es hierzu eine Berechtigungsmartix oder übergeodrnetet Gruppen. Wenn in einem anderem FabLab eine Berechtigung erworben wird, wie werden diese gespeichert?
Whitelists für Domains
Modi der Föderation
- Authentifikation
- Das FabHome kann die Person Authentifizieren
- eventuell Nutzerdatenübertragung
- Berechtigung
- das FabHome kann sagen, welche Berechtigungen die Person besitzt
- Wenn ein Nutzer in einem anderen Space (A) als dem FabHome (B) eine Berechtigung erlangt, dann darf A die Berechtigung des Nutzers auf dem Space B ändern (hinzufügen), wenn Space B dem Space A im Berechtigungs Modus vertraut.
- Abrechnung
- Das FabHome ist in der Lage der Person eine Rechnung zu schreiben.
Nutzerdatenübertragung
Nutzerinformaton
- Jeder Nutzer hat null oder mehr Karten Schlüssel
- Jeder Schlüssel kann entweder valide oder deaktiviert sein. (Enventuelle spätere Erweiterung)
Authentifizierung in der Föderation
Space A: Ein FabLab Space B: Das FabHome des Nutzers Space A föderiert mit Space B und der Nutzer hat 2FA eingeschaltet.
Karte->Reader: Hier bin ich!
Reader->Space A: Karte möchte sich Authentifizieren
Note over Space A: Föderiere ich mit Space B?
Space A->Space B: Diese Karte möchte sich Authentifizieren.
Space B->Karte: OTA
Note over Space B: Nutzer kann Authorisiert werden
Karte->Space B: OTA
Space B-->Reader: Warte auf 2FA
Space B->Nutzer: 2FA: Ist das eine legitime Authentifikation?
Nutzer->Space B: Ja, ist es
Space B->Space A: Der Nutzer ist Authentifiziert!
Note over Space A: Aktoren ausführen.
Space A-->Reader: Nutzer ist Authentifiziert!
Zwei-Faktor-Authentifikation
- Wenn der FabHome eine Authentifikationsanfrage erhällt kann der Nutzer durch ein vorher festgesetztes Medium um eine Bestätigung gebeten werden.
- 2FA ist für den Nutzer optional.
- Sensoren/Aktoren in FabLabs können 2FA vom Nutzer erzwingen.
- Mögliche Wege sind:
- Mobile App
- E-Mail (OTP)
- SMS? (OTP)
Glosar
- FabHome
- Der Space bei der eine Person seine Karte erstellt hat.
Wie wird die Nutzungsbedingungen der einzelnen Spaces an den Nutzter weitergegeben? Wer könnte für Haftungsfragen aufkommen. Wie werden Berechtigungen gehandhabt, wenn Space A eine Berechtigung ausstellt, wo der Home Space B ist und Space B mit Space föderiert und dann die Berechtigung annerkennen soll von Space A.
Für den Anfang nicht wichtig aber später sehr. Welche vertraglichen Regeln müssen für eine Föderartion mit FabAccess müssen festgehalten werden?
11.08.2020 // August-Call Nr. 1 Fab-Access
Geschobene Themen aus dem Juli-Call Nr. 1:
Link zum vorherigen Protokoll:
https://pad.gwdg.de/USEMMX9ZQTKwoSOlMd1eyQ
Hardware-Kommunikations-Fragen (Joris)
- Wieviel Logik sollte / Muss in der Hardware implementiert sein? Um verschiedene Hardware (Leser mit/ohne Diplay, mit/ohne Relais, mit/ohne Leistungserfassung) zu unterstützen wäre der Vorschlag, möglichst viel Logik in die Software (Back-end?) zu implementieren.
- In welcher Form werden anzeigbare Nachrichten übermittelt (als Klartext oder als Befehl, der dann von der Hardware interpretiert wird)? Vorschlag ist mit Befehle zu arbeiten, da dies ebenfalls mehr Flexibilität bei der Hardware (unterschiedliche Displays) ermöglicht. Nachteil ist, das man nicht so flexibel in der Erweiterung der Anzeigetexte ist (dies eine Neuprogrammierung der Hardware erfordert)
- Wenn die Lesegeräte unabhängig sind von den Aktuatoren, ist die “Notfreischaltung” bei Software oder Netzprobleme nicht möglich. Entweder Implementiert man hier eine direkte Kommunikation zwischen Leser und Aktuator über den Broker oder muss den Aktuator von Hand schalten. Was ist bevorzugt?
- Die Idee ist, die Hardware über einen Setup-modus als Access Point zu konfigurieren. Hier wird die Broker-IP, Geräte-ID etc. eingetragen. Hier kann auch das Verahlten (z.B. Log-out über RFID Karte oder einfach per Taste) konfiguriert werden.
- Sollte die Hardware ESP8266 basiert sein, gibt es nur den Analog-Eingang um eine Taste zu integrieren. Solle mehr als eine Taste benötigt werden, wird man z.B. auf dem ESP32 umschwenken müssen (Eine Taste wird z.B. für Bestätigung der Beaufsichtung der Maschine im Betrieb benötigt). Welche Szenarien für Tastennutzung gibt es?
- Eine Variante ist z.B. der Wemos D1 oder NodeMCU v3 … 8266 mit mehr herausgeführten digitalen Anschlüssen als der ESP01. (TMu, 2020-08-11)
Lastenheft vorstellen / durchsprechen.
Fragen(Joris):
Anforderungsliste:
- 4 Override -> So wie es hier beschreiben ist erfordert dies eine Integration von Kartenleser und Leistungsmodule. Bei Verwendung von separaten Leistungsmodule (z. B. Tasmota) könnte dies manuell über eine Taste erfolgen (somit ungesichert). Hier würde mich die Erfahrung von Card2Go interessieren.
- An der Stelle ist bei den Prototypen für Card2Go tatsächlich Card-Reader und Schaltmodul (im Protoyp eine LED, später Relais / SSR / Schütz) eine Einheit … bzw. der Card-Reader hat einen direkten Ausgang, über den er das Schaltmodul betätigen kann. (TMu, 2020-08-11)
- In der Firmware vom CardReader sind dann “Master-Karten” (rote Karte / grüne Karte) hinterlegt, die nicht gegen das Backend verifiziert werden, sondern die direkt und ohne Rückfrage schalten. (TMu, 2020-08-11)
- 8 Nutzerhinweise ausgeben -> hier ist die Frage wo welche Nutzerhinweise hinterlegt sind, bzw. wie sichergestellt wird, dass diese auch sinnvoll formatiert auf die Anzeigen angezeigt werden (je nach Hardware).
- Ein Beispiel ist dass 30 Minuten vor dem finalen “Strom ist weg” in der Anzeige ein Zähler rückwärts läuft, der den Nutzer sachte drauf hinweist dass er evtl. mal langsam ans Ende denken sollte, wenn er noch Zeit / Strom braucht um die Maschine ordentlich herunterzufahren / zu putzen. Hilft drastisch, einen geordneten Feierabend im Labor hinzubekommen / durchzusetzen.
- Wieder abhängig von Berechtigungen … es wird sicher Nutzer geben, die auch nach “Feierabend” da bleiben und aufräumen dürfen. (TMu, 2020-08-11)
- 11 Reservierung von Maschinen -> gibt es hier ein angedachtes Konzept (z.B. Erfahrung von andere Systeme). Reservierung ist unter Punkt 13 in die Zukunft verschoben?
- Reservieren im offenen Werkstattbereich ist … nicht offen. (“Handtuch-Mentalität” entgegenwirken.)
- A: Maschine ist reserviert, Fertigungs-Daten sind nicht fertig (im Sinne von “wirklich fertig!”) -> die Maschine steht, obwohl jmd. anders sie nutzen könnte.
- B: Maschine ist morgen reserviert, Fertigungs-Daten sind aber unerwartet früh (jetzt) schon fertig -> Ich kann erst morgen weitermachen, obwohl ich faktisch schon heute könnte.
- Reservierung ist z.B. in begrenztem Umfang sinnvoll … der normale Weg ist “first come, first serve” … mit einer möglichen Priorisierung (z.B. in einer Lehr-Hochschule: “Lehre vor Forschung vor Privat vor Industrie”) (TMu, 2020-08-11)
- ich sitz zuhause, hab ca. 45 Minuten bis zum Lab, seh im Netz dass die Maschine frei ist und möchte nicht umsonst hinfahren, weil mir in 10 min. jemand die Maschine wegschnappt während ich unterwegs bin.
- Im Lab ist jeden Mittwoch um 14:00 bis 15:00 Maschineneinweisung.
- Grundsätzlich: Freie Maschinen können genutzt werden, arbeitende Maschinen erst wieder, sobald sie fertig (geputzt / abgenommen) sind. Toilettenpause ohne Maschinenrückgabe ist dabei okay, Mittagessen grenzwertig, “am nächsten Tag geht’s weiter” ist üblicherweise indiskutabel. (TMu, 2020-08-11)
- Reservieren im offenen Werkstattbereich ist … nicht offen. (“Handtuch-Mentalität” entgegenwirken.)
- 13 Relation Zeit-Maschine -> dieser Punkt klingt für mich etwas kryptisch. Erläuterung erhofft :-)
- 15 Öffnungszeiten festlegen -> hier würde ich ein Maschinenbezogenes Konzept wünschen. Zenario wäre hier, dass aufgrund von Auflagen, bestimmte Maschinen spezifische Nutzungszeiten haben.
- 19 Statusanzeige -> Hier würde ich mir einige konkrete Beispiele als Szenario wünschen.
allgemeine Fragen:
- allgemein wird an einigen Stellen von “Maschine übergeben” geschrieben. Da mir aktuell noch die Praxis fehlt, ist das für mich noch etwas vage. Hier würde mir ein Praxis-Zenario helfen
- Ein Szenario ist z.B. Nutzer 1 (A) ist eigentlich fertig, würde jetzt anfangen die Maschine zu putzen und zurückzugeben. Nutzer 2 (B) steht ningelnd daneben und würde gerne schnell und unbyrokratisch übernehmen. B kann dann von A die Maschine unter der Bedingung übernehmen, dass er die volle Verantwortung für etwaige Schäden die auf dem Mist von A gewachsen sind … und für das Putzen und zurückgeben der Maschine übernimmt. Die Idee ist an der Stelle, beim Weggang von A ein (definierbares) Zeitfenster von z.B. 15 Sekunden zu lassen, innerhalb dessen ein B (mit entsprechender Berechtigungs-Kombination aus “darf übernehmen” und “darf diese Maschine jetzt bedienen”) die Maschine direkt übernehmen kann. Das Zeitfenster muss dabei so kurz sein, dass A in jedem Fall mitbekommen kann, wenn jemand übernimmt. (TMu, 2020-08-11)
- Konkret: A nimmt die RFID-Karte weg, B muss die Option freigeschaltet haben und innerhalb von 15 Sekunden seine Karte auflegen, dann “gehört” ihm die Maschine und er kann los legen. (TMu, 2020-08-11)
- Ist die “Eingangstür-Kontrolle” (z.B. bei 24/7 Zutriff) ebenfalls mit drin oder soll dieser ausgeschlossen werden?
- Soweit eine Eingangstür eine “Maschine” ist, die bei Nutzung jeweils für ca. 5 Sekunden einschaltbar ist. Ja. Wenn die Eingangstür eine “Maschine” ist, von deren Funktion die Sicherheit im Lab oder die einzige Zutritts-Option, die zudem nicht anderweitig verhindert werden kann abhängig ist … nope.
- Konkret:
- Wenn ein zusätzliches (mechanisches) Schloss existiert und mit FabAccess nur wenn dieses aufgesperrt ist, die Tür geöffnet werden kann … okay.
- Wenn eine Panikschließung existiert, so dass man von innen jederzeit raus kommt … okay.
- Wenn man durch Yberlisten von FabAccess sofort unbefugten Zutritt zum Lab bekommt … nicht okay.
- Wenn man bei Stromausfall (durch FabAccess) nicht mehr raus kommt … nicht okay. (TMu, 2020-08-11)
- Final entscheiden muss das am Ende jedes Lab für sich. Seitens FabAccess ist da allerdings halbwegs klare Kommunikation wichtig, damit die Labs das auch wirklich und richtig informiert entscheiden können. (TMu, 2020-08-11)
- Authentifizierung über SASL -> relevant für die Hardware+Code?
- Abrechnung (Non-Features) -> das macht Sinn, aber hier würde ich mir schon ein “nutzbaren” Output wünschen der in einer Abrechnugnssoftware weiterverwendet werden kann. Was ist hier aktuell angedacht?
Sonstiges
-
Link zum System (AWS-Basiert) welches von der FH-Bocholt “anprogrammiert” wurde. Vielleicht gibt es ja das eine oder andere Brauchbare. Bei Interesse einfach anmelden, dann schalte ich euch frei. https://pord.d2o1hsizt1sm7z.amplifyapp.com/#/login
-
Webbasiertes Buchungstool (Testumgebung) um die Anforderungen (Funktion & UX/UI) mit Makerspaces explorativ zu definieren: beta.makethings.ch
-
salesforce.org als kostenlose Lösung mit einigen ERP-Funktionen, welche spannend wären zu testen
21.07.2020 // Themensammlung Juli-Call FabAccess
Geschobene Themen für den Juli-Call Nr. 2 / August Nr. 1:
Hardware-Kommunikations-Fragen (Joris)
Lastenheft vorstellen / durchsprechen.
Link zur nächsten Themensammlung / zum nächsten Protokoll:
https://pad.gwdg.de/XBEsTtDvSbquhtqFpQk0Zw
Zusammenfassung Juli-Call Nr. 1:
-
Wir fahren erst mal mit Gitlab-Issues.
- Vorteil: Weniger Logins, Gitlab-Issues wurden in letzter Zeit gut weiterentwickelt und geben wohl fast so viel her wie Jira.
- Nachteil: Keine erkennbar - kann evtl. in 1 bis 2 Jahren nochmal evaluiert werden - oder wenn jemand im Lauf der Zeit “Schmerzen” mit Gitlab bekommt.
-
Erreichbarkeit:
- Wir setzen einen (kleinen!) Mailserver mit Mailman auf, der EMails an info@fabaccess.org /.de / … an die Core-Leute und issue@fabaccess.org /.de / … über ServiceDesk in Gitlab-Issues wirft.
- Gregor macht beim Einrichten mit.
-
Doku wird erst mal in readthedocs.io angefangen und evaluiert, ob das funktioniert. Joris testet, ob das auch für Hardware funktioniert.
Tooldiskussionen
Projektmanagement
- Jira
- Verwenden oder bleiben lassen?
- Cloud oder SelfHosted?
- mit Confluence?
- mit BitBucket?
- mit …?
- wer wartet den Server (mit)?
- oder Gitlab-Issues ||||
Erreichbarkeit
- Mailman
- Addresse / Hosting
- wer wartet den Mailserver (mit)?
Doku
… wo schreiben / pflegen?
- readthedocs.io? ||||
- jgm/gitit <dequbed>
Architektur
Stand/Pläne PrototypeFund
Hardware
Ansätze / Stände
24.06.2020 // Call zu Werkstatt-Zugangssystemen 2020-06-24
Teilnehmer:
Marcio
Max
Tasso (tasso.mulzer@beuth-hochschule.de)
tom
Marcio: Baut seit ca. 10 Jahren offene Werkstätten / MakerSpaces - hat bemerkt, dass er immer wieder an den selben Dingen angestoßen ist. Es gibt wenige verwendbare / einsetzbare Tools. Hat letztes Jahr ein Projekt bei einem Förderfonds eingegeben, wurde als unterstützenswert angesehen und ist jetzt dabei.
Tom hat die Verbindung zu FabAccess hergestellt. Es gibt bestimmt viele Parallelen und Marcio hofft, dass wir uns zusammen tun können.
Etappenförderung - beim Erreichen von Zwischenzielen werden neue Tranchen ausgelöst. Betrag darf nicht genannt werden.
Marcio: Maschinenbau-Studium, BWL-Studium und Projektarbeit / Organisation von Projekten.
Team: Patrick (Prototyping Hardware / Software-Schnittstelle) / Hans (Elektroniker), Rouwen, Livio & Francois arbeiten bei der EFL? und helfen softwareseitig. Viel läuft auf Englisch, die Sprachbarriere existiert schon irgendwie.
Nicolai hilft beim Design, ist aktuell in Sidney und arbeitet von dort aus mit.
Elias? hat/betreibt/entwickelt ein ERP-System.
Aktuell Konzeption des Hardware-Teils.
Schnittstellen und Einbindung des ERP-Systems muss noch geschaut werden. - es gibt eine API, das muss aber eben zusammengebracht werden.
06.03.2020 // Probleme die wir im Backend noch lösen müssen
IdP fuer FabAccess
Was wollen wollen wir allen zu externalisieren erlauben:
optional = nur wenn wir einen Anwendungsfall finden
-
User (zwingend)
- Müssen aber z.B. Authentication Token weiterhin intern speichern
-
Gruppen (optional)
- Wenn überhaupt dann als welche Rollen du dadurch erhältst
- Nur relevant wenn es ein Lab gibt was Gruppen in ihrem exteren IdP hat die explizit auf Permissions mappen (Es gibt eine “NutzerDieFräsenDürfen”-Gruppe)
<TMu;2020-03-04>Ja … Gruppen lowPrio optional, wenn überhaupt. … alles grundsätzlich nur lesend (Passwort-Ändern für HS-Account aus FabAccess brauchen wir tendenziell nicht).
“Eigene” User sollten natürlich ihr Passwort schon bei Gelegenheit mal ändern oder wiederherstellen können.</TMu;2020-03-04>
Problem: Merging
Es gibt tendenziell mehrere Datenquellen für Benutzer. Wie werden Collisions gelöst?
Idee 1: Es gibt eine fixe Policy. (z.B. Intern ist wichtiger)
Idee 2: Uniqueness check beim einfuegen von DB => Einfach wenn AuthToken immer lokal gelagert sind und nicht extern
<TMu;20200304>Jira lässt mehrere Authentication-Quellen zu - kopiert allerdings das komplette LDAP-Verzeichnis beim Einrichten. Find ich weniger schön. Leihs hat das besser gelöst … lässt bedingt auch mehrere Quellen zu (unterschiedliche Quellen haben unterschiedliche Login-Seiten) … holt die Nutzerdaten aber nur beim ersten Zugriff aus LDAP --> Nur Nutzer in der lokalen UserBase, die auch wirklich da waren statt “alle der Hochschule!!”</TMu;2020-03-04>
Inventar aus Leihs
Was sollen die Vorteile sein? Muss Daten live sein oder reicht es mehr oder weniger regelmäßig zu syncen?
<TMu;2020-03-04>Live wär schon schön … es passiert relativ häufig, dass jemand mit ${Ding} vor mir steht, ich es schnell eintrage und ihm wieder nur Nutzung in die Hand drücke.
Aus Leihs fallen als Formular hübsche Leihverträge und die Inventarisierung von (teilweise ausleihbaren) Geräten und Maschinen ist für das Labor echt passend gelöst - besser als alle ERP- oder sonstigen Inventar-Systeme.</TMu;2020-03-04>
06.03.2020 // Diskussion in der Telegram-Gruppe des VoW am 25.02.
Genannte Software-Schnittstellen
ERP
- odoo.com
- collmex.de
- Es gibt eine Python API (https://pypi.org/project/gocept.collmex/)
sonstige
- Nextcloud (als Auth.)
- OSEG arbeitet an einem CRM-Entwurf
Genannte Endgeräte
- Nuki.io scheint relativ häufig vorhanden zu sein.
- https://www.tindie.com/products/nardev/esp-rfid-relay-board-12v-for-esp8266-board/
- Sonoffs (https://www.banggood.com/SONOFF-POW-DIY-WIFI-Long-Distance-Power-Monitor-Current-Tester-Remote-Control-Switch-Socket-For-Smart-Home-p-1123797.html?cur_warehouse=CN)
- Renkforce / Conrad-Zutrittskontrollsystem (https://www.conrad.de/de/p/renkforce-transponder-zutrittkontrolle-mit-ereignisaufzeichnung-leser-7-750782.html)
Sonstiges
- Frage nach einer “standardisierten Qualifikationsmatrix” --> Vorschlag Tasso: Festlegen eines halbwegs sinnvollen Default-Aufbaus, jedoch konfigurierbar lassen.
- 5-stufig wie bei Card2Go, mit vereinzelten interdependenzen (Stufe 1 kann z.B. nur von Stufe 4 oder 5 übernehmen).
- 9-stufig wie bei Perso-net.de - vermutlich zu komplex für unsere Anwendungen.
- Frage nach (Inventar-)Versicherung, wenn Space mit “selbstgebasteltem” Schließsystem ausgeräumt wird.
- Nuki mit zweitem Schloss und Schlüsselsafe ist eine Lösung, aber evtl. nicht Versicherungskonform
- Nuki mit Bridge geht auch gut und scheint konform zu sein.
Hackathon am 17. bis 19.04. in Dortmund wird erwartet.
18.02.2020 // Hackathon, 07.02.20
Strukturiert nach: https://www.mendix.com/de/blog/eine-praktische-anleitung-fur-den-product-canvas/
Product Vision Board
-
Warum erstellen wir die Anwendung?
- Wir wollen ein System haben, das auf die Bedürfnisse offener Werkstätten zugeschnitten ist.
- Veränderbar
- bezahlbar
- Denn bestehende Systeme sind
- … zu teuer
- … passen nicht vollständig zu unseren Bedürfnissen.
- … nicht problemlos in bestehende Strukturen integrierbar
- Wir wollen ein System haben, das auf die Bedürfnisse offener Werkstätten zugeschnitten ist.
-
Wer ist unsere Zielgruppe?
- Offene Räume
- HackerSpaces
- Offene Werkstätten
- FabLabs in/an Hochschulen
- Offene Räume
-
Was sind ihre Bedürfnisse?
- Möglichst autonomes / autarkes Handeln ermöglichen
- selbstbestimmtes Arbeiten und Lernen
- Einfacher niederschwelliger Zugang zu…
- Türen
- Maschinen
- Werkzeuge
- Einfache Administrationsprozesse
- Die Möglichkeit haben, das System an individuelle technische Gegebenheiten anzupassen.
- Möglichkeit zur Abrechnung dieser Vorgänge
- Zugriff auf Monitoring / Protokollierung / Nutzungs-Statistiken
- Granulare Berechtigungen
- Maschinen: Nutzungsberechtigungen
- Türen: Zutrittsberechtigungen
- (Anleitung und Nutzungshilfen)
- Lösen von folgenden Problemen…
- manuelle zugangskontrolle
- manuelles Aushändigen von Werkzeugen
- verschiedene Authentifizierung methoden
- manuelles Abrechnen
- manuelles Buchführen von Nutzung und Verbräuchen
- funktionierende Software/Hardware zu teuer (Fabman)
- Nutzung von selbstgebauter Hardware aus versicherungstechnischen Gründen nicht möglich
- Möglichst autonomes / autarkes Handeln ermöglichen
-
Was sind dabei unsere Ziele?
- Das System soll sich verbreiten, das bedeutet.
- Das System soll auf einer möglichst breiten und agilen Basis entwickelt werden.
- Wir wollen für die User entwickeln, nicht für uns.
- Das System soll Menschen Arbeit abnehmen statt aufbürden.
- Das System soll im Rahmen einer nachhaltigen Struktur entstehen - nicht an einer Person hängen, sondern jederzeit durch andere weiterentwickelt werden können.
- –> strictly OpenSource.
- In Zukunft optional als Föderation funktionieren
- Das System soll sich verbreiten, das bedeutet.
Abgrenzung
Zur Diskussion
- Spaces die sich neu einrichten (Hauptzielgruppe sind bestehende Labs)
- Spaces mit homogenen Geräte/Maschinenpark (Hauptzielgruppe hat eine organisch gewachsenen Gerätepark)
- Spaces ohne Geräte/Maschinen (Hauptzielgruppe haben diese)
- Spaces die Geräte und Werkzeuge verleihen (Hauptzielgruppe hat Werkzeuge immer am Ort)
- Spaces mit viel Geld (Hauptzielgruppe hat knappes Budget)
- Spaces die Service möchten (Hauptzielgruppe kann sich selbst helfen)
- Spaces die eine Einzellösung benötigen
Fragen zur Zielgruppe
- Darf unsere Zielgruppe Veränderungen an Maschinen vornehmen?
- Darf unsere Zielgruppe Veränderungen an Türen vornehmen?
- Darf unsere Zielgruppe virtuelle Guthaben verwalten?
- Hat die Zielgruppe feste ein Buchungsprozess (vorherige Vergabe fester Zeitslots) für Geräte
- Wie hoch ist die Fluktuation von Endnutzer unserer Zielgruppe?
- Wie hoch ist die Fluktuation von Technischen Administratoren unserer Zielgruppe?
- Wie hoch ist die Fluktuation von Supervisor unserer Zielgruppe?
- Kurz wie viel Einarbeitung von allen Personas ist noch zulässig?
- Welche Skills und technischen/nichttechnischen Möglichkeiten stehen der Zielgruppe in welchen Umfang zur Verfügung?
- Techniker (Kabel ziehen, Geräte modifizieren)
- Netzwerker (Netzwerke einrichten, Systeme warten, Backups durchführen und zurückspielen)
- Einweiser für Endnutzer (Karten ausgeben, Ansprechpartner)
- Einrichter (Einrichten des Systems, Probleme beheben)
- Entwickler (Erweiterung und Anpassung des FabAccess) ? welche Sprachen sind zu erwarten?
- Welche Geräte sind zu erwarten?
- 3D Drucker
- CNC Fräsen
- Plotter
- Drucker
- Nähmaschinen
- Lötkolben
- Werkzeugkoffer
- Wie viele und welche Besonderheiten haben die Räume unser Zielgruppe?
- Anzahl von Räumen?
- Sind Räumlichkeiten verteilt auf mehrere Standorte?
- Haben die Türen unterschiedliche Öffnungsmechanismen?
- Können Öffnungsmechanismen getauscht werden?
- Gibt es Sicherheitstüren?
- Gibt es kritische Bereiche?
Product Canvas
Personas
- Wer sind unsere Nutzer?
- Akteure, die sich Zutritt zu Dingen verschaffen (Nutzer*, Mitglieder der Werkstatt / des Raumes)
- Der technischen Administrator (installiert / aktualisiert das System Software/Aktoren/…)
- Supervisor (communitynaher Administrator)
- Finanzadministrator
- Ressourcen-Administrator
- Technischer Maschinen-Betreuer
- Lab-Lead (Ansprechpartner in der Räumlichkeit)
User Journeys
- Was sind Eigenschaften sowie Aufgaben der Nutzer und wie stellen wir uns vor, dass sie diese erfüllen?
- Nutzer / Akteure, die sich Zutritt zu Dingen verschaffen
- Eigenschaften
- sind tendentiell ungeduldig, möchten schnell zu Ergebnissen kommen
- sie sind Laien oder technische Spezialisten - volle Bandbreite
- sie möchten jederzeit in die Räume und darin arbeiten
- Aufgaben
- sollen den Arbeitsschutz beachten (sind daran aber nicht wirklich interessiert)
- sollen auf die Maschinen achten (verschleißarme Anwendung)
- sollten aufräumen (wollen es aber nicht)
- Registrierung: gibt seine Daten selbständig ein und stimmt deren Verwendung zu
- Bedürfnisse
- wollen den Preis der aktuellen Verbrauchszeit wissen
- wollen fehlgebuchte Buchungen stornieren
- wollen eine Monatsübersicht
- Eigenschaften
- Technischer Administrator
- Aufgaben
- Will / soll das System (die Software/Aktoren/…) installieren
- sowie aktiv halten (aktualisieren, Fehler beheben)
- Eigenschaften
- kennt das System, kann Software installieren
- kann nicht zwangsläufig programmieren
- “Semi-Nerd”
- Infrastruktur
- für die Software steht ihm entweder ein eigener Server zur Verfügung oder auch nicht
- Bedürfnisse
- will von bestehenden Geräte-Beständen Eigenschaften importieren / exportieren
- hat ggf. bevorzugte Authentifizierungsmethoden
- moechte moeglichst wenig Administrationsaufwand
- möchte / kann nicht viel Zeit in das Aufsetzen investieren
- Möchte nicht ständig Angriffsvektoren abschneiden oder schließen (müssen).
- will nicht, dass Module bei einem Update kaputt gehen
- Aufgaben
- Supervisor (Nutzer*-Administration)
- Aufgaben
- Vergibt z.B. Berechtigungen nach Workshops oder Einweisungen
- Empfängt neue Mitglieder, vergibt Berechtigungen
- Kann Nutzerdaten eingeben und ändern
- Aufgaben
- Finanz-Administration
- Aufgaben
- rechnet gegenüber den Nutzern ab
- Bedürnisse
- er möchte individuelle Verbrauchswerte erfassen
- es sollte unterschiedliche Typen von “Rechnungen” geben. Nicht jeder Nutzer braucht eine volle Rechnung mit MwSt.
- möchte seine individuelle Abrechnungssoftware nutzen
- Aufgaben
- Ressourcen-Administration
- Aufgaben
- Kauft Material ein
- Legt Material in Lager
- gibt Geld aus
- Bedürnisse
- Brauch Verbrauchsdaten von Material konsumierenden Maschinen (z.B. 3D-Drucker)
- Aufgaben
- Technischer Maschinen-Betreuer
- Aufgaben
- kümmert sich um Maschinen
- Bedürfnisse
- Verschleißdaten / Nutzungsdaten von Maschinen sollten angezeigt werden können: Rohdaten!
- Aufgaben
- Lab-Lead (Ansprechpartner in der Räumlichkeit)
- Aufgaben
- Hat Überblick über den aktuellen Betrieb im Labor
- Können einfache Fragen zur Nutzung beantworten.
- Bedürnisse
- will wissen wer gerade da ist
- wissen welche Maschinen aktiv sind
- will Nutzer* und ihre Eigenschaften recherchieren können
- will einfach Stornierungen vornehmen, wenn Falschbuchungen vorliegen
- Eigenschaften
- sind immer vor Ort am Tresen
- sind freundlich
- haben z.T. geringes technisches Verständnis vom System
- Aufgaben
- Programmierer
- Schreiben den Kern
- Wollen realisierbare Aufgabenpakete lösen
- Hören auf die (anderen!) Nutzer
- Nutzer / Akteure, die sich Zutritt zu Dingen verschaffen
Technische Lösungen
- Codearchitektur (abgeleitet aus den oben stehenden Bedürfnissen)
- Es gibt einen Kern mit Funktionen / Methoden, die den kleinsten gemeinsamen Nenner bilden
- Kontrolliert Zugangsberechtigung
- Von außen kommt eine Anfrage, die wird validiert und die Entscheidung mitgeteilt
- Authentifikation
- Parameter, die die Entscheidung beeinflussen, können vom Administrator über ein externes Interface angepasst werden
- Von außen kommt eine Anfrage, die wird validiert und die Entscheidung mitgeteilt
- Der Kern hat ein integriertes Protokollsystem
- z.B. Zeitspempel der Authentifizierung eines Users / Aktivierung eines Aktors / Grund der Ablehnung von Aktion XY
- gibt Rohdaten (z.B. auf Socket) aus.
- Gibt generisches “an” oder “aus” heraus. Was der “Aktor” oder “Sensor” damit macht, ist ihm überlassen
- Kontrolliert Zugangsberechtigung
- Um den Kern gibt es optionale Frameworks / Plugins, die Zusatzfunktionen ermöglichen, wie:
- konkrete Authentifizierungsmethoden
- Aktoren-Definitionen
- Schnittstellen zu ERP-Systemen
- Rohdaten der Protokollierung werden verarbeitet und abgelegt / ausgewertet / whatever.
- Begründung: Ein komplett offenes Framework bedeutet beim Einrichten sehr viel Arbeit (benötigt technisch versierten Administrator oder ein sehr aufwendiges Admininterface) und da das höchste Ziel die Benutzerfreundlichkeit und geringen Kosten (auch Zeit) sind, leitet sich die Entscheidung daraus ab.
- Es gibt einen Kern mit Funktionen / Methoden, die den kleinsten gemeinsamen Nenner bilden
To-Dos:
- Technische Anforderungen klarer fassen
- Eine Umfrage formulieren mit den folgenden Parametern:
- Wer ist bereit, als Alpha-Tester zur Verfügung zu stehen?
- Verbreitete Authentifizierungsmethoden (RFID/NFC/UserId+Pwd/…?)
- Bereits existierende Nutzerdatenbank (LDAP, SQL, AD, …?)
- Bereits existierende Schliess-/Zugangssysteme
- Verwendete ERP-Systeme
- Verbeitete Aktoren
- 3D-Drucker? Welcher?
- Welche Server werden verwendet?
Zusammenfassung 08.02.
-
Wir wollen agil arbeiten uns aber keine Rituale mit massivem Kommunikations-Overhead aufbürden
- In Vollzeit-Teams ist der Kommunikations-Overhad vernachlässigbar. In unserer Konstellation (4 Stunden pro Woche) eher tödlich.
-
Asynchrone Kommunikation ist wichtig und in unserem Fall hilfreich - das lässt manche Elemente der Agilen Arbeitweise nicht zu.
-
Jira können wir testen und schauen ob es uns hilft oder Mailinglisten bzw. die in Gitlab vorhandenen Möglichkeiten sinnvoller sind.
-
Grobe Vorstellung der Arbeitsweise:
- Es gibt Issues/Tickets in JIRA die das Ziel haben eine konkrete Entscheidung (architekturell) zu treffen
- Diskussionen finden asynchron innheralb dieser Issues/Tickets statt
- Ziel der Diskussion sollte bei architekturellen Entscheidung ein ADR sein (Architectual Decision Record)
- ADR-Template.
- CLI-Tool zur Erstellung und Organisation.
- Erklärender Blog-Beitrag
- Auslieferbare Features definieren wir in Stories
-
Tasso richtet eine Mailingliste ein
- Bis JIRA läuft findet die asynchrone Kommunikation über die Mailingliste statt
-
Architekturskizze muss nochmal diskutiert und als Bild entwickelt werden.
- Hierbei wollen wir auf die Architekturen der bereits im Team vorhandenen Backends eingehen, um zu schauen wo Synthese Sinn macht
18.02.2020 // JitSi Call 18.02.
Teilnehmer:
- Marcus
- Kevin
- Fabi
- Dequbed
- Tasso (listening)
Call
Jira wird eingerichtet (am Donnerstag)
Ziel ist, ADRs “herausfallen” zu lassen.
Sprache: TypeScript und Rust sind noch drin -->
Wenn komplett modular: anders.
Diskussionsbedarf für “anders als NodeJS und Rust”: …
Frage: Was braucht die Zielgruppe??
Antwort: User werden eher nicht an der Infrastruktur-Software bauen. --> Prio, dass Nutzer Anpassungen vornehmen können ist eher klein. Admins wollen nur installieren, haben keine Zeit zum bauen.
Das deutet irgendwie auf einen “Kern” hin, in dem viel fertig (konfigurierbar) vorhanden ist… gerne modular erweiterbar.
Ziel: Waagen sollen z.B. abfragbar sein. --> Modular.
Türen aufmachen usw. --> Monolithisch.
Waagen sind “Verbrauch von Werten” --> kann im “Kern” gebaut werden.
Was sind die ersten 2/3/4/5 UseCases?
<dequbed/Marcus>: Maschinen verwenden - Berechtigungssystem
2 Arten: reservierbar / one-time-use / Berechtigungen
Abrechnung … wurde x min. verwendet - kostet y.
Ansatz für heute:
Was haben wir bisher gemacht --> Wie kommen wir daraus sinnvoll zu einer Architektur?
Sprache klären oder nochmal aufschieben? --> Aufschieben.
Mit welchen Beweggründen haben wir was gemacht? … aufgeteilt in Frontend / Backend.
Fabian: Screensharing.
Backend: TypeScript / Node
Anforderung war: Generell erst mal anfangen, Zugangskontrolle zu automatisieren. Bisher: viele Eigenbaulösungen mit ESP / Reader / Türschlössern / Relays / … FabLab ist aber versichert, daher ist selbstgebaute Hardware nicht gern gesehen. Es gibt aber viel HomeAutomation-Hardware von der Stange, die das Problem an der Stelle lösen kann.
–> Schaltbare Steckdose finden und die anbinden.
Auf ein Protokoll einschränke ist doof --> wie können wir viele Protokolle mit wenig Aufwand einbinden? --> OpenHab2 mit RestAPI, um Aktoren anzusprechen.
Andere FabLabs nutzen odoo als UserBasis und zur Abrechnung. User / Booking / Rechnung / …
–> github.com/faaaaabi/fablab-api-gateway
github.com/faaaaabi/fablab-access-app
App: ReactNative (FaceBook-Frontend-Framework)
Nicht nur WebApp, sondern native.
App fragt Karte, kann Maschinen einschalten die er darf --> gibt Backend bescheid --> das schaltet über OpenHAB.
Räumlichkeiten sind wichtig, weil verschiedene Tablets verschiedene Maschinen schalten können.
Angedacht: 2FA
fabaccess.bian-meyer.de/
React-App. Kann Berechtigungen definieren, odoo hat nur Checkbox für “Hat Sicherungseinweisung”, odoo soll aber nur Stammdaten pflegen.
Berechtigungen sollen ins Backend.
Dependencies: Frameworks, xpress? analog zu Django bei Python. Odoo / OpenHAB / … aber nicht als Dependency, sondern mit abstraktem Interface implementiert.
Kommunikation zwischen Backend / OpenHab: REST; Backend / odoo: XML
RoseGuarden:
vor ca. 3 Jahren angefangen mit V1
Angular-App als Frontend. Backend aus Python, monolithisch.
Primäre Anwendung: Türen. Geräte nicht so wichtig. Viele Vereine, nicht zwingend FabLabs.
Hochschulen / größere MakerSpaces: Geräte … kleinere (haben keine Geräte) daher eher Türen.
Basis: RaspberryPi, liefert FrontEnd. Knoten synchronisieren sich über RestAPI.
Knoten die ausfallen bringen das System nicht durcheinander.
RoseGuarden 2:
ServerAnsatz wäre besser gewesen. Sollte Fernwartung zulassen. Ist gar nicht so viel anders als RG1.
Backend: modular, in Workspaces organisiert. mit 2FA und Pin lässt sich die Tür öffnen.
Neben Türen gab es den Ansatz, dass sich User verwalten lassen müssen.
Viel an der Hardware geschraubt “polling über REST”
FrontEnd: VueJS (React / Angular / Vue)
PythonCode - definiert Actions und Views einfach und modular. Kann evtl. “krachen”, wenn das Interface nicht ausreichend generisch ist.
ESP: RFID, Display&Touch, kann Relay schalten. Focus war darauf.
Frage: Wie löst das Modulsystem Abhängigkeiten zwischen Modulen auf?
Antwort: Bisher nicht notwendig, daher nicht implementiert. “Ich möchte aus View a Action b aufrufen” ist möglich.
Kommunikation über ActionManager ist möglich, bisher keine Kontrolle / FailSafe von Abhängigkeiten.
Wenn Maschinen eingeschaltet werden, soll angezeigt werden: “Kuck, ob der Wiederanlauf-Schutz aktiv ist!” usw. um Verletzungen und Schaden zu vermeiden.
Ergänzung aus dem VoW-Treffen:
Fast jeder hat ein SmartPhone, Tablets sind teuer --> QR-Code an Maschinen. Aktionen über SmartApps.
dequbed: tmate.io
DFBH
cap’n proto als Stichwort …
Rest zugeschaut - Fazit: durchdacht, generisch, ziemlich cool. Kann man nicht so gut verkaufen, ist aber gut gemacht.
Cap’n Proto stellt sicher, dass Schnittstellen zwischen Sprachen funktionieren. Es werden Schemata definiert und zur Verfügung gestellt, die Nachrichten sind sprachübergreifend sichergestellt definiert.
Das Tool generiert sprachspezifischen Code, der die Schnittstellen einbindet.
Vergleichbar mit Protocol-Buffer, aber mächtigere RPC. Einfachere bidirektionale Interfaces.
Marcus: Muss RG1 fixen --> schaltet auf ListenOnly.
Wie bekommen wir hin, dass Fabian & Marcus bei dem coolen Shit, den dequbed “hingeworfen” hat mitkommen? – Busfaktor sollte 3 sein, nicht 1.
Zu klären: Kommunikation Front-/Backend
Varianten: Websockets / Server dazwischen.
Fabi: Für APIs, die wir nach außen zur Verfügung stellen, sollten wir auf REST setzen. Geringe Einstiegshürde.
0815-User kann mit Cap’n Proto jeweils Schnittstellen erstellen, die sie als Start nutzen können.
a) Dokumentation für User, die mit CP dann ihre Schnittstellen erstellen können.
b) Wir maintainen eine Python-Lib, die die Schnittstelle abbildet.
Modul-Implementation:
Bei V1.0: FabLab braucht Hue-Lampen.
MQTT ist im Kern eingebaut. Wir können MQTT sprechen. Du (externer User) schreibst in Python eine Implenentation, die nur Encoding macht … erstellst also eine Message, die von uns über MQTT versendet wird.
Wie können wir mit anderen Sprachen interagieren? - Ruby,C,Python,JS, … Kommunikation mit dem Kern soll möglichst einfach werden.
Aufwand ist “gigantisch” Code soll am Ende nicht mehr von uns geschrieben werden, sondern von Usern. Wir kümmern uns um alles, was im Kern stattfindet. Bieten EINE Schnittstelle an, aber nicht mehr.
Alles was kaputt gehen kann, muss in Rust geschrieben werden, damit ich wenigstens mitbekomme, wenn es kaputt gegangen ist.
Supergute Dokumentation ist extrem wichtig. Evtl. weniger Aufwand, Dokumentation für eine Schnittstelle gut zu machen als 10 Schnittstellen zu maintainen.
dequbed wünscht sich Backend mit 1 Schnittstelle zum FrontEnd.
Gedanken über die API machen.
Testweise, exemplarisch schauen, wie das mit der Anbindung Cap’n Proto funktioniert.
dequbed kann den (rudimentären) Server zum testen ins Netz werfen.
Lizenzen…
MIT - Copyleft … erhöht die Innovativität …
OSI-Lizenz ist Voraussetzung.
Ist (…teilweise …evtl.) von der öffentlichen Hand finanziert.
Gregor: APIs dürfen nicht kommerzialisiert werden. Alles andere … kann und soll diskutiert werden.
Wir machen eine Umfrage - stoßen eine Diskussion an … evtl. MultipleChoice-Umfrage in Telegram.
AGPL-3.0 GPL3/2 EUPL-1.1 LGPL-2.1 MPL-2.0 Apache2.0 BSD3-Clause MIT CC0
04.01.2020 // Materialsammlung 29.12.2019 @36C3
- Vorstellungsrunde der Anwesenden
- Erläuterung der bisherigen Aktivitäten und Hintergründe / Fragerunde
- Materialsammlung für eine Anforderungsliste
Zugang zu Räumen / Maschinen regulieren
-
Falsche Person in die Nähe einer Maschine --> Maschine aus.
- Sinnvoll herunterfahren
- Funktionieren, wenn befugte Personen in der Nähe sind.
-
Türschließmechanismen
-
Schlüsselkasten
-
Öffnung bestimmter Schränke
-
Wer ist wann da? vs. Datenschutz!
-
Sehen, ob jemand da ist, …
- der den Raum geöffnet hält.
- der den Raum nutzt.
- der Maschinen die nicht trivial sind (nicht für jede Maschine geeignet) bedienen kann
-
Notschalter??
-
Globalen Identifikations-Key Studierendenausweis / … verwenden.
-
Qualifikationsmatrix - wer kann das Gerät bedienen?
- Wer ist Ansprechpartner für $Maschine?
- Ist jemand da der die Maschine bedienen oder mich einweisen kann?
-
Reservierungssystem / Status der Maschine
-
sind die Fenster zu?
Strukturierung des Betriebs
- Geräte die kaputt gehen - wer war’s??
- Versicherungen…
- Belohnungssystem - “Willst Du nicht mal den Müll rausbringen?” --> BLE-Tag am Mülleimer --> Punktesystem für Müllrausbringen, Mitgliedsbeitrag sparen, Freigetränke, etc.
- Belohnungssystem für “sauber halten” et al.
- Systeme, die Vibrationen erkennen und damit Maschinenzustand melden.
- Füllstand von Staubsaugern.
- Warnung bei zu starker Staub Entwicklung, zu laut etc.
- Material - Nachbestellungen, wenn Material alle.
- Octoprint integrieren.
Abrechnung von Maschinennutzung und / oder anderen ${Dingen}
-
Raumfahrtagentur: Prepaid
-
Was mache ich, wenn Guthaben aufgebraucht ist? - Lasercutter aus???
-
So einfach wie möglich bauen!
- Billingsystem ist nicht integriert
- Überall verschiedene Billing-Systeme
-
Essen/Getränke abrechnen
-
Geräte leihen
- … und mitnehmen
- … und dem Fablab zur Verfügung stellen
-
Materialbestellungen / Verbrauchsmaterial /Bohrerbruch/Fräserbruch
-
Schrank, der erkennt welche Geräte drin liegen (und welche nicht).
13.12.2019 // Protokoll Jit.si-Konferenz 09.12.19
Teilnehmer
- Micha (Kiel / WSK)
- Fabi (HRW / Düsseldorf / FabAccess)
- Dequbed (Berlin / BF2H)
- Thee (BHT / Bachelorarbeit TI)
- Marcus Drobisch (Dresden / RoseGuard)
- Kevin (Dresden / RoseGuard)
- Maximilian Voigt (Cottbus / VOW)
- Tasso / Knurps (Berlin / BHT)
“Morphologischer Kasten”
- FabAccess ist Semesterprojekt-Arbeit (18SWS) … und noch zusätzlich durch VOW gepusht. Bis März
MLP / MAP: Sinnvoll … nur, vermeiden dass das Skateboard mit dem Endprodukt vermischt wird & den ersten Eindruck “versaut”.
Entscheidungen: Konsens / Systemisches Konsensionieren
Programmiersprache:
- Wollen wir das jetzt entscheiden?
- Frontend ist nicht zwingend Backend.
<Fabian> Klare Empfehlung, Diskussion über Technologie relativ spät. Was sind die UseCases? … Was kann ich aus den UseCases ableiten, sinnvolle Technologien dazu zu finden.</Fabian>
<Marcus>+1 technische Features / Technologien ja … Programmiersprache als Basic früher.</Marcus>
<M V> Vorstellung der bisherigen Systeme … was kann man dort herausziehen? - ergibt sich daraus schon etwas?</M V>
<Fabi>Hilft Sprachwahl auf Meta-Ebene?</Fabi>
[…] Sprachdiskussion.
-
funktionale / typstarke Programmiersprachen: Stabiler. Vermeiden Bugs “aus Versehen” einzubauen. Compiler verbietet mehr Fehler.
-
Ruby / Python / … breitere Basis an potentiellen Programmierern / Community.
-
Sicherheit herstellen durch Testing.
-
Sicherheit herstellen durch typisierte Sprache & Testing.
-
Rust kann’s / würde es gerne lernen / kann’s nicht / kann’s nicht / kann’s nicht / 3x gerne lernen / 1x wofür? / community wird beschnitten / schnell lernbar (viel Doku) /
-
Python halbwegs / kann’s, aber nicht genug für Infrastruktur-Software / nutze es täglich um Messdaten auszuwerten, mittelgut / geht bisschen Datenmanipulation / gut dabei / relativ gerne // ja, gerne / wäre bereit zu lernen / hätte bock, mehr zu machen / kein Bedarf // Doku gibt’s, schnell lernbar, größere Community als Rust, übel viele Libraries. Python2 … ist tot. Python 3.6 hat typechecks, aber so … hmm.
-
Java / kann’s ein bisschen, nicht genug für Infrastruktur / kann’s ein bisschen, auch Infrastruktur damit gemacht. / hab’s ein bisschen, hauptsächlich App-Entwicklung / mal 1 Semester mit AndroidStudio / paar Kurse gehabt // nicht wahnsinnig Bock drauf, würd’s aber machen +1 / ungern --> Kotlin +2 // 9 ist in 2000ern angekommen
-
Kotlin / kann … keiner? / 2x: lieber bei Java bleiben als Kotlin zu lernen / gerne lernen +1 / Java ohne Java-Fehler (NullPointerException / …) schwer zu lernen.
-
Scala IDE aufwärmen / Programmieren lernen / Programmieren lernen / Programmieren lernen / Programmieren lernen // kann / will keiner
-
TypeScript kann ich gut / relativ viel JavaScript, bisschen TypeScript und node.js TypeScript: ein wenig, steile Lernkurve / noch nie verwendet, JavaScript doch öfter, leicht zu lernen / äääh, nein. / nicht so viel damit gemacht // überzeugt mich / gerne lernen // kommt aus dem Node-Umfeld, typisiert, strict-mode verhindert viel Unfug, viele schlechte, aber auch viele gute Bibliotheken, große Community, geringe Einstiegshürden, ProtokollImplementation … will man wohl nicht machen, Bibliotheken (z.B. AMQP) sind aber verwendbar. (Viele) Backend-Tasks müssten abgedeckt sein.
Fragen:
- können wir
- stabil
- wie schnell kann man’s lernen?
- wie viel muss man selber machen?
Bewertung (1: Am liebsten 4: Am wenigst liebsten X: VETO):
-
dequbed (10h - 20h Back):
- Rust: 1
- TypeScript: 2
- Java: 3
- Python: 4
-
mdrobisch (langfristig viel):
- Python: 1
- TypeScript: 2
- Rust: 3
- Java: 4
-
fabi (15 - 20h Front&Back):
- Python: 2
- TypeScript: 1
- Rust: 4
- Java: 3
-
Thee:
- Python: 1
- TypeScript: 3
- Rust: 2
- Java: 4
-
SUM:
- Rust: 1 + 3 + 4 + 2 = 10
- Python: 4 + 1 + 2 + 1 = 8
- TypeScript: 2 + 2 + 1 + 3 = 8
- Java: 3 + 4 + 3 + 4 = 14
Frontend: Kevin / Marcus / Fabian /
Backend: Dequbed / Marcus / Fabian / Thee
Firmware Clients: Tasso / Dequbed / Thee
Ranking: Beliebteste Sprache? … Sprache die am häufigsten verwendet wird? … Was kann wer aktuell? … was machen viele? … was machen “die Guten”?
Kotlin - noch nicht so gewachsen wie Java
Java 9 - kaum Dokumentation, aber gewachsen.
Java 5 - viel Dokumentation aber nicht 2020.
Python Umstieg 2 zu 3 … relativ unproblematisch.
Python: Exceptions, daher potentiell instabil. Evtl. abfangbar mit Lint / CI
TypeScript … ist Javascript mit strikter Typisierung --> fängt viele Fehlermöglichkeiten ab. TypeScript != Node.js
Node kann threaden, erreicht gute Performance, JavaScript ist event-fokussiert, singlethreaded. Node kann zwar threaded, man arbeitet aber ähnlich wie im Browser.
Promises … gibt’s in TypeScript. Alles aus JavaScript + TypSystem. Java: geht, Python: geht (twisted?) … Rust: Standard-Feature
Fragen die noch zu klären sind…
Kuratiertes Framework vs. Erweiterbarer Monolith
Fabian:
-
Paper ist zur SensorNets Link angenommen. Kann in der Endversion auf OAS erweitert werden und Öffentlichkeit für unser Projekt zu generieren.
-
Alex Roussolet? … europäische Ebene aktivieren / Erasmus für MakerSpaces / FabLabs (Belgien, Frankreich, …)
Was soll beim 36C3 geschehen?
- Technische Fragen, die bis da hin vermutlich mehr als weniger werden “live und in Farbe” … klären!
- Nur am Rande … von 3 Core-Leuten sind 1 da!
- Statt dessen den Workshop-Slot nutzen, um Feedback aus der 36C3-Community abholen. Sicht von außen auf Teile unserer bisherigen Diskussionspunkte.
- UseCases sammeln.
Geld beim VoW?!
- Sozialfonds ist gut.
- Hardware auch.
Monolith / Modulsystem / FrameWork??
Monolithic vs. Modular (JavaScript/Node.js)
Simon Brown - Modular Monoliths
nächster Call
Doodle - lockerer, offener Termin noch vor Weihnachten? … ansonsten intensiver im neuen Jahr.
09.12.2019 // Grundlegendes
Zuverlässigkeit ist Hauptziel; wenn BF₂H als Schließsystem für Türen o.ä eingesetzt werden soll kann ein Crash bedeuten das nur noch das Backup-Personal mit Schlüssel in das Labor kommen kann.
Der laufende Wartungsaufwand sollte null sein. Einmal aufgesetzt sollte das System möglichst ohne Unterbrechung laufen können. Datenquellen wie Datenbanken sollten darauf ausgelegt sein nicht korrumpierbar zu sein, Fehlerquellen wie nicht überprüfte dynamische Konfiguration die durch Schreibfehler o.ä. im späteren Betrieb Fehler aufwirft sollte so gut wie möglich im Vorhinein überprüft werden. Upgradepfade von Versionen zu neueren Versionen sollten klar sein. Ein Versionierungsschema wie Semver oder PVP sollte verwendet werden und Integrationstests sollten explizit darauf ausgelegt sein Änderungen in dokumentiertem Verhalten ohne Versionsänderung als Defekt zu deklarieren.
Das System muss erweiterbar sein; insbesondere Anbindung an bereits vorhandene Schließsysteme sollte möglich sein ohne das grosse Änderungen im Kern vorgenommen werden müssen. Hier bietet sich tendenziell ein System mit zur Laufzeit ladbaren Modulen an.
Anbindung an andere externe Systeme — z.b. Authentifizierung/Autorisierung über ActiveDirectory / LDAP / SAML oder Abrechnung über ERP wie Odoo — sollten auch möglich sein, aber die Anzahl der Schnittstellen die benötigt werden ist tendenziell wesentlich geringer also ist hier der Vorteil von anwendergeschriebenen Modulen weniger groß bzw. fehlende Zentralisierung kann die Qualität der Schnittstellen senken; i.e. eine einzelne generische Schnittstelle für LDAP und AD ist wesentlich sinnvoller als mehrere für jeweils die eine Instanz in den jeweiligen offenen Räumen.
Spezifische Technologien
Frontend nicht im Umfang dieses Dokuments.
Design Backend
Sprachwahl: Rust. Bestes Kosten/Nutzen-Verhältnis für stabile Software. Weniger populär als Java/C#/Python/PHP/C++/C, aber das ist nur dann relevant wenn die Software im Basar-Stil von sehr vielen Leuten entwickelt wird die alle nur sehr kleine Änderungen beitragen. Sehe ich hier nicht als gegeben, eher wahrscheinlich ist das 80-90% des Codes von einer Handvoll Entwicklern geschrieben wird und nur Fringe-Code von “Externen” beigetragen wird.
Vorteile von Rust:
- Effiziente Programmiersprache
- Kompiliert zu einer dynamisch oder statisch verlinkten ELF
- Typsystem mit Typinferenz, statisch, stark & linear.
- Extrem gut dokumentiert, vor allem für Anfänger viele Möglichkeiten die Sprache umfassend zu lernen.
- Fehlerbehandlung über Summentypen (Some/None, Ok/Err) anstatt über Exceptions*
- Macht Fehlerbehandlung extrem resilient da alle Behandlung explizit passieren muss.
- Alle Fehler die eine Funktion generieren kann sind im Funktionsprototypen festgelegt
- Probleme der Art eine neu hinzugekommen Exception wird (noch) nicht behandelt können nicht passieren.
- Flexibles Futures-System und von Anfang auf Multithreading ausgelegtes Design machen es sehr einfach hoch-parallelisierte Anwendungen zu schreiben.
- Für uns sehr relevant da wir eine solche schreiben wollen.
- Guter Library-Support für unsere Anwendungsfälle.
- Sollte Bedarf bestehen ist es sehr einfach Support für Skriptsprachen wie Python oder Lua einzubauen
(* Rust hat “Exceptions” in der Form von panics
. Diese sind aber anders zu sehen als Exceptions in z.B. C++ oder Python weil sie nur für schwere und nicht behebbare Fehler gedacht sind und auch nicht innerhalb einen Threads abgefangen werden können)
Kommunikation
Kommunikation zwischen Komponenten:
(P2P steht in diesem Kontext fuer Point-to-Point also Unicast, P2MP steht fuer Point-to-MultiPoint, also Multicast, nicht fuer Peer-to-Peer im Stil von BitTorrent o.ae.)
-
Schliessystem(e) mit Backend
- Stil: P2P & P2MP (Backend->Clients)
- Bidirektionales message passing
- RPC von einzelnen Clients zum zentralen Server
- Statusabfragen vom zentralen Server an Clients
- P2MP für Broadcasts oder Multicast vom Hauptprogramm zu Schliesssystemen
- Notifications vom zentralen Server an mehrere Clients
- Beispiel: Feierabend, bestimme Maschinen in 30min herunterfahren
- Kann als PubSub gebaut werden, evtl allerdings vom Server diktiert
sinnvoller.- Bei PubSub müssen die Clients selber wissen ob diese Art Nachricht
für sie relevant ist. In unserem Fall ist es aber evtl. sinnvoller wenn
der Server das eigenmächtig entscheiden kann.
- Bei PubSub müssen die Clients selber wissen ob diese Art Nachricht
- Auch für Broadcasts bei z.B. Neustart des zentralen Servers
- Notifications vom zentralen Server an mehrere Clients
- Rückwärtskompatibilität im Protokoll sehr wichtig. Hinzufügen eines Feldes für einen neuen Typ Client sollte es nicht erzwingen das auf allen anderen Clients Code-Updates erforderlich werden.
- Schnittstellenbeschreibungssysteme (IDS) wie Google Protocol Buffers, Apache
Thrift, Cap’n’Proto, … legen darauf besonders Augenmerk, ist also in
diesen einfach. - ASN.1 mit PER und BER erlaubt das gleiche, kann aber einen speziell dafür
angepassten Parser benötigen.
- Schnittstellenbeschreibungssysteme (IDS) wie Google Protocol Buffers, Apache
-
Frontend mit Backend
- Stil: p2p
- Bidirektionales Message passing
- Notifications vom Backend zum Frontend
- RPC vom Frontend zum Backend
- Netzwerk-basierte IPC damit auch lokale Frontends (GUI/TUI) verwendet werden
können- Besonders ein CLI ist für Automatisierung sehr wichtig
- Da es sehr wahrscheinlich mehr als ein Frontend geben wird sollte auch hier
ein IDS verwendet werden.
-
Backend mit externen Diensten
- Dienst-spezifische Protokolle & Aufbau (z.B. LDAP, HTTP(S), …)
Sinnvolle Protokolle:
- reines TCP
- ØMQ
- MQTT (v5)
- ?
Netzwerkabstraktion wäre schön, aber HTTP löst die gegebenen Probleme schlechter als reines TCP, sollte also nicht verwendet werden.
Websockify für Web-basierte Frontends?
alt.: https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events
Verschlüsselung / Sicherheit
Backend mit Schliesssystemen
TLS ist ein extrem komplexes Protokoll, kann also vor allem für embedded Plattformen zu schwer werden. Zusätzlich bietet TLS uns keine Vorteile; die wichtigsten Eigenschaften des TLS-Stacks sind Aushandlung von Algorithmen und Zertifikatsvalidierung via PKI. Alternative: Nachrichten werden mit festgelegtem Algorithmus (z.B. Salsa20/Poly1305 oder AES256-GCM) verschluesselt. Beim erstmaligen Einrichten einen embedded Clients wird ein System-Key generiert, dessen public key auch dem Backend-Server bekannt ist und der für Authentifizierung des Clients gegenueber des Backend-Server genutzt wird.
Backend mit Frontends
Frontends werden auf wesentlich leistungsstärkeren Plattformen aufgesetzt sein. Vor allem bei lokalen Frontends ist TLS sehr sinnvoll.
Design Schliesssysteme
Primär Leistungsschwache, auf Kosten optimierte Hardware.
Oft gesehen: ESP8266, Arduino
Vor allem bei ESP8266 ist ein System wie NodeMCU sinnvoll. Das Protokoll zum Server / Crypto kann in C/C++/… implementiert werden, die Maschinen-spezifische Handhabung dann in Lua.
Misc.
- Module wieder upstreamen
- Konfigurationswebinterface
Moduldesign
Spezifisch Kommunikationsmodule mit Schliesssytemen:
- Aus Stabilitätsgründen nicht im selben Prozess wie Server
- Kommunikation über UNIX socket oder named pipe
- Protokoll via IDS
- Support für Python & Rust am sinnvollsten, Lua evtl. auch hilfreich
- Grundsätzlich kann aber jede Sprache verwendet werden die auf UNIX sockets oder named pipes zugreifen kann
- Falls später komplexere Module benötigt werden neuer Modultyp die als .so zur Laufzeit geladen werden
- Haben direkten Zugriff auf alle interen APIs, können aber den Server crashen
- Von anderen geschriebene Module sollten von Anfang an zentral gesammelt werden damit alle davon profitieren können.
- Was spricht dagegen das Protokoll fuer Referenzclients fuer Module zu verwenden?
- Dann zwingend notwendig: Mehrere Clients ueber eine Verbindung. Tendenziell aber eh sinnvoll.
<!- vim: set spelllang=de: ->
09.12.2019 // Vorbereitung Jit.si-Konferenz am 09.12.19
Agenda
Fragen?
- Wie ändert sich die Deadline / wie organisieren wir uns, damit Fabian ins Team zurück kann ohne seine Deadline zu gefährden? (falls Fabian das möchte.)
- Wollen wir ein MLP/MAP (Minimum Loveable/Awesome Product) definieren? Idee: schnell etwas auf die Beine stellen, um Feedback und neue Entwickler zu bekommen
-(siehe: https://de.wikipedia.org/wiki/Minimum_Viable_Product#cite_note-6)
Konsens?
- Für MakerSpaces außerhalb DE muss das FrontEnd (&BackEnd?) generell multilingual gedacht werden (i18l).
- …
Technologiefragen (hinzugefügt von mdrobisch)
Entscheidungsfindung
- gut geklärter Entscheidungsprozess ist sehr wichtig (vorher)
- besonders bei technischen Fragestellungen ist Kompromissfindung meist schwierig und führt zu schlechteren Entscheidungen (persönliche Erfahrung)
- offtmals (persönliche Erfahrung) sind Diskussionen über Werkzeuge schlussendlich nicht wichtig, da mit verschiedenen Werkzeugen gleiche Ziele erreicht werden können
- wichtig ist der Wiederstand einzelner Personen gegenüber getroffenen Entscheidungen besonders auf lange Sicht im Auge zu behalten
- Entscheidungskriterien sollten zusammen erstellt werden, (persönliche Erfahrung: führt zu langen teilweise dogmatischen Diskussion -> macht keinen Spaß)
- danach abstimmen (in kleiner Gruppe) oder von einem Leiter (meist der am meisten Energie aufbringt)
Hauptprogrammiersprache im Backend
- Können/Wollen wir das gerade Entscheiden?
- Rust
- Python
Vorschlag Entscheidungskriterien zur Auswahl der Programmiersprache:
Rangfolge entspricht Priorität (1. Sehr Wichtig … n+1. nicht wichtig)
- Zu Verfügung stehende Manpower (im Moment), d.h. kurzfristig zu erwartender Geschwindigkeit der Entwicklung
- Zu erwartende Manpower/Entwickler, d.h. langfristige Entwicklung / Bestand des Projektes / Geschwindigkeit der Entwicklung
- Niederschwelligkeit für Einsteiger und nicht-Entwickler (Doku, Entwicklungsumgebungen)
- Zur Verfügung stehende relevante Bibliotheken
- Bestehende Projekte auf denen aufgebaut werden kann d.h. starten wir am Anfang oder in der Mitte und gibt es Hilfestellung beim einrichten Programmieren
- Technische Feature der Sprache (ggf. mit Mindestschwälle, Turing-Vollständig)
Bitte weitere ergänzen oder Prio ändern
Schnittstellen
- Können/Wollen wir das gerade Entscheiden?
- P2P (Point-to-Point, MQTT, ZMQ, etc.) über z.B. Broker-Infrastruktur
- HTTPS
Vorschlag Entscheidungskriterien zur Auswahl der Hauptschnittstelle:
Rangfolge entspricht Priorität (1. Sehr Wichtig … n+1. nicht wichtig)
- Erfahrung mit der Schnittstelle (im Moment)
- Interne Integrierbarkeit (nach innen, intern zwischen Komponenten des System bzw. bestehende Systeme, z.B. Bibliotheken, Bestandslösungen)
- Client/Hardware Integrierbarkeit (möglichkeit/aufwand Mikrcontroller und Clients)
- Externe Integrierbarkeit (nach außen, für externe/andere Systeme)
- Niederschweligkeit für Einsteiger (Doku, Verbreitung, Infrastruktur)
- Technische Feature der Schnittstelle
Bitte weitere ergänzen oder Prio ändern
Frontend
- besteht hier schon Konsens?
Angebundene Geräte (Clients/Mikrocontroller)
- wollen wir das überhaupt mit in die Entwicklungsziele aufnehmen?
Fragen zu Rust
- @Gruppe/Devs: Wer hat bereits Erfahrung damit? (gleiche Frage für Python)
- @Gruppe/Devs: Wer könnte sich vorstellen sich darin einzuarbeiten? (gleiche Frage für Python)
- @Gruppe/Devs: Wer kann sich vorstellen Hauptentwickler zu sein (Thematik: Basar-Stil vs Lead-Developers)
- Sind technische Aspekte der Programmiersprache für unsere Entscheidungin der Gruppe überhaupt wichtig? (Exceptions, Typsicherheit, Lineartät, Multitthreading)
- Wie stellt sich ein Kosten/Nutzen-Verhältnis konkret dar? Welche Prios sind dort angenommen?
- Müssten wir bei 0 Anfangen oder gibt es schon einen Prototypen?
- welche Bibliotheken würden wir für konkret nutzen?
- ist ein Plugin-System in Rust schnell umsetzbar? (auch möglich ohne andere Programmier/Skriptsprache)
Fragen zum P2P-Ansatz
- Welche Probleme löst P2P?
- Hat schon jemand Erfahrung mit MQTT, ZMQ, etc. an konkreten produktiven Projekten
- Hat schon jemand Erfahrung mit Websockify in Frontends? (ist das exotisch oder standard)?
- Wollen wir Sicherheitsthemen/Verschlüsselung auf Programmierebene wirklich selber machen? (besonders auf Arduino, ESP und Co), bzw. können wir das überhaupt?
- Wie binden wir mit P2P externe Services/Komponenten (Odoo, Groupware, Hardware) an? Über ein selbst programmiertes Gateway/Protokollwandler?
08.12.2019 // OAS 4 All
Grundidee des bestehenden Fabaccess Systems
- Frontend (Clickdummy): https://fabaccess.bian-meyer.de
- Backend
- Zugriffs-App
Technologieentscheidung
Beruhen zum Großteil auf persönlicen Präferenzen. Daneben:
-
Backend:
- Sprache/Frameworks
- node
- Sehr große und aktive Community
- Sehr große Auswahl an teilweise sehr guten Libraries, Frameworks
- Niedrige Einstiegshürde
- TypeScript
- Mittel der Wahl um im JavaScript Umfeld Typsicherheit zu erhalten
- Kombiniert die flexibilität von JavaScript mit der Typsicherheit anderer Sprachen
- Eignet sich durch Sprachfeatures aus der OOP besonders für größere Projekte
- Sehr große und aktive Community
- Express
- Etabliertes Webframework im node Umfeld
- Breite erweiterbarkeit durch third party libs
- node
- Sprache/Frameworks
-
Frontend
- Typescript: siehe oben
- React:
- Sehr große und aktive Community
- Breites Spektrum an “Addons” (Third-Party Libs, Komponenten-Libs)
-
Zugriffs-App
- JavaScript: Würde gerne TypeScript sein. Sollte zu TypeScript migriert werden
- ReactNative:
- Kleine Lernkurve zwischen Ract und React Native: Sehr viel Code-Sharing zwischen Web und App möglich (nahezu alles bis auf das Markup)
- Native UI-Elemente (kein WebView), dadruch nativer Look and Feel
- Cross-Platform fähig
- Große und aktive Community
- Breite Auswahl an Libs und Framworks
- Geringe Einstiegshürde (Im Vergleich zur App programmierung in Kotlin, Swift)
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
- 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
- CE Zertifizierung
- 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)
- Vairante A: Lokal (z.B. Raspberry Pi Server)
- 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
- 13,56 MHz Mifare favorisiert
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
- Gateway mit Relay 26€
-
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
01.12.2019 // Mumble-Sitzung 26.11.19
Vorstellungsrunde:
- Mario / FabLab Chemnitz: Prozesse/IT-Admin Kram
- Marcus / Dresden Roseguarden: FullStack-Dev
- Kevin / Dresden Roseguarden: Programmieren, Hardware, Löten
- Max / VoW bzw. Open Knowledge Foundation: will die Entwicklung allgemein unterstützen; kann ggf. mit einer Förderung helfen
- dequbed Berlin: entwickelt Software
- Knurps (Tasso), Beuth Hochschule für Technik (BHT): baut Makerspace auf, Spezialgebiet: Mechatronik (d.h. kein Spezialgebiet)
36C3?
- Was soll auf dem Congress passieren? - wo will man hin? - was soll passieren?
- 2h-Slot im Workshop-Bereich von Chaoszone ist erst mal reserviert.
- mehr? weniger?
wer / was / wie viel / welche Perspektive ?
- Max / Leute mitnehmen, Projekt unter die Leute bringen, Ö-Arbeit, evtl. Funding / nebenbei / die ganze Zeit dabei, die nächsten Jahre
- Tasso / Doku, Hardware-Schnittstellen, Überblick behalten, Tagesgeschäfte erledigen, Mädchen für alles / Projekt Prio 2 (neben Aufbau FabLab) / hauptberuflich ins Fablab, da faellt das natuerlich darunter. Nach 3 bis 5 Jahren zurückfahren auf OpenSource-Entwickler.
- Marcus / FullStack / würde Roseguarden tendenziell abgeben / gerne zurückfahren bis zu gg. Deadline (ca. Mitte 2020) reinpowern, dann pro Woche nur 4h … perspektivisch/langfristig ganz normaler OpenSource-Teilnehmer.
- Kevin / Python, FineWire ESP-Mikrocontroller, TouchScreen, RFID, Karte&Pin / 3 Jahre relativ viel
- dequbed / Backend, LDAP, SAML, Repo-Beauftragter / 10h/woche / bis März, folgend normales OpenSource-Projekt (wenn’s Sinn macht)
wer / was fehlt?
- Native App-Entwicklung (iOS / Android)
- 1x Mensch für Backend-Skalierung
- Odoo-Schnittstelle
- 1x Hardware-Entwickler
- 1x System-Integrator?
Geld
- lieber Hardware supporten als Leute
- wäre den anderen ggü. nicht fair - evtl. in Ausnahmefällen.
Weichenstellungen
Projekt
- zusammen laufen lassen, aber Deadlines fallen erst mal weg bzw. werden im Projekt je nach Zielen & Fortschritt definiert.
- externe Deadlines existieren … so weit möglich berücksichtigen, aber nur wenn realistisch möglich für’s Projekt übernehmen.
Technologien
Repo
- GitHub
- GitLab
- …
Core-Sprache
- Python? (ansatzweise spürbarer Konsens?, aber noch offen.)
- Haskell?
- Rust?
Frontend-Sprachen
- separate Sprache
- WebDev
- Nicht dequbed
Hosting
- Self-Hosted sollte/muss einfach möglich sein.
- Evtl. Container?
- Evtl. Ansible-Repos wie bei Leihs (ZHDK)?
- apt-get install…
- pip
- SUPER SAUBER DOKUMENTIEREN!
- wenn mit den gg. Ressourcen stemmbar, evtl. wie das OpenHABian-Image.
Architektur
- vertagt, da für fundierte Entscheidungen jeder Beteiligte einen Überblick über potentielle Lösungen braucht / haben möchte. (s. letzter Punkt, “nächster Termin”)
- grobe Richtung
- Schnittstellen: https-polling vs. AMQP(/MQTT) vs. youNameIt
- sollte in manchen (nicht allen?) Bereichen auch auf Mikrocontrollern implementierbar sein.
- sollte verschlüsselt / verschlüsselbar sein.
- … was noch?
- Backend
- Frontend
- Firmware
- Hardware
- Schnittstellen: https-polling vs. AMQP(/MQTT) vs. youNameIt
Benötigte Infrastruktur
- Repo!
- Domain?
- CI/CD selbst?
Benötigte weitere Ressourcen
- …
Nächster Termin
- vor dem 36C3! - in ca. 10 Tagen (05. bis 10.12.)
- Offener Austausch: “Was gibt es? - Was macht Sinn?”
- Vermutlich schon festlegen essentieller Technologie-Weichenstellungen.
- Ansatz: Alle Beteiligten mit Projekten / Ideen erklären einem “mittelgebildeten WackelDackel” (aka. Tasso) ihre Ideen / ihr Projekt. Danach offener Austausch über die verschiedenen Ansätze und gemeinsame Entscheidungsfindung.
20.11.2019 // Open Access System_Dokument zum Verbundstreffen
Du möchtest Teil des Projektes werden? Melde dich bei Max
Hier geht es zum aktuellen Projekt-Dokuemnt: https://pad.gwdg.de/DsyvzN4TQyyB5M94ZCBihQ?view
Kurzvorstellung des Teilprojektes FabAccess
FabAccess ist ein Zugangssystem, das, basierend auf den verschiedenen Ansätzen und gemachten Erfahrungen der einzelnen Werkstätten, eine möglichst breite Nutzbarkeit ermöglichen soll. Ziel ist die Entwicklung möglichst objektbasierter und generischer Schnittstellen, die die diversen Bedürfnisse der Werkstätten abdecken.
Hier der Link zum aktuellen Clickt-Dummy des Admininterfaces - ein Gitlab-Rep folgt: https://fabaccess.bian-meyer.de/
Authentifizierungsmethoden: 13,56Mhz RFID-Karten und Pin, QR-Code über Nutzer-App
Specs:
- Aktoren werden aktuell angesprochen über openHAB - weitere Schnittstellen sind geplant
- Schnittstelle zu und Datenbankbasis über Odoo
- Odoo ermöglicht die Rechnungstellung / Abrechnungen von Aktionen
- Schaltbar gemacht werden sollen diverse Aktoren, wie Türen, große/kleine Maschinen etc.
- Individuelle und maschinenbaiserte Vergabe von Berechtigungen (Person X hat eine Einführung Y bekommen und damit Zugang zu Z oder als Mitglied Zutritt zu der Tür A)
Doku zum Workshop auf dem Verbundstreffen der Offenen Werkstätten 2019
Das Projekt sowie der aktuelle Stand wurde vorgestellt. Im Anschluss folgt das Feedback der Teilnehmenden:
- individuelle Verbrauchswerte sollten erfasst werden können
- es sollte eine einfache Möglichkeit der Stornierung geben, wenn eine Falschbuchung gemacht wurde
- der Preis der aktuellen Verbrauchszeit sollte dem User angezeigt werden
- es sollte unterschiedliche Typen von “Rechnungen” geben. Nicht jeder Nutzer braucht eine volle Rechnung mit mwst.
- Verschleißdaten / Nutzungsdaten von Maschinen sollten angezeigt werden können: Rohdaten!
- Nutzungsevent wird als Nachricht formuliert, die andere Systeme konsummieren können.
- Stammdaten nicht als Pflichtfelder anlegen
- Berechtigungen suchen
- Benutzergruppen erzeugen? Wäre einfacher, wenn vielen die Berechtigung für etwas erteilt werden soll
- mehrere Zugriffsgeräte für einen Ort, um die dort stehenden Geräte zu schalten
- importieren / exportieren von Geräten
- die Möglichkeit Fotos zu hinterlegen für “Orte”, um dort Geräte wie in “real” anordnen zu können
- die Möglichkeit der “Rückkommunikation” schaffen
- Adminprofil, das die App freischaltet, um sie zu konfigurieren
Folgende Fragen wurden gegen Ende gestellt:
- Könnt ihr damit eure Nutzerfälle abbilden?
- Es kam kein besonderes negatives Feedback
- Welche Authentifizierungsmethoden nutzt ihr?
- nfc
- Welche speziellen Aktoren sollen genutzt werden?
- Drehstromaschinen ermöglichen
Wünsche / To-Dos:
- offenes git erstellen
- Webapp ermöglichen
- Nutzer abmelden auf Tablets
- Zeiträume für Aktoren / Maschinen festlegen
- wenn Signal eines Aktors abbricht, Buchung nach einer Zeit beenden (z.b. im Falle eines Notaus)
- 3 Use-Cases entwickeln, die möglichst breite Anwendungsfälle abbilden
- Boxen für Kleingeräte, statt das Kleingerät selbst zu schalten
- …
- …
Digitalisierung der Klebezettel, die von den Teilnehmern beschrieben wurden
- Anbinding eigener Nutzerdatenbank (anstatt Odoo)
- Tablet: aktives Ausschalten realisieren???
- Rollenprofile
- Admin Zugangskarte
- Einweiser Karte
- Schließfächer, Zigarettenautomato, Vendingmachine???
- Anbindung von Autmationshardware der Firma Pilz (https://www.pilz.com/de-DE/produkte-loesungen/schaltgeraete)
- Vermerken, wann eine und vom wem eine Berechtigung erteilt wurde
- Manuelle Verbrauchserfassung
- Kontextinformationen zur Buchung hinzufügbar machen (frei)
- Anbindung/Monitoring durch Messages & Events
- Ein Zugriffsgerät mehren Orten zuweisen können
- Benutzern gesammelt Berechtigungen erteilen
- Verschiedene Benutzergruppen (mit und ohne Rechnung)
- Korrekturbuchungen möglich machen (Rechnung)
- Anbindung von Codesys
- Verschiedene Admins (1 Admin für Vereine, 1 Adin für Vereine)
Technologien/Tools die Werkstätten verwenden
- Fablab Chemnitz (nacheditiert am 20.11.2019)
- was verstehen wir unter einem Zugangssystem?
- “Hardware as a Service” (HaaS) in Anlehnung zu “Software as a Service” (SaaS)
- Ressourcenverwaltung / Inventarverwaltung
- Nutzerverwaltung / Mitgliederverwaltung
- Problem: für verschiedene Aufgaben haben wir bereits erprobte und gut genutzte Software. Wie verdrahten wir das, was wir bereits haben mit dem, was noch fehlt? Permanente Migration zu anderen Programmen ist zu aufwendig und zu fehleranfällig
- konkret vorhandene Hardware, die wir einbinden wollen und bereits besitzen
- Nuki Smartlock mit Nuki Bridge
- mehrere Devolo Home Control Steckdosen (außerdem Temperatursensor, Rauchmelder, etc. vom gleichen Anbieter)
- Tinkerforge NFC Card Reader Terminal (hier sollen sich unsere Mitglieder später mit einem NFC-Tag an- und abmelden können bzw. weitere Aktionen ausführen)
- NeoCoolCam Power Plugs
- https://www.amazon.de/Coolcam-Z-Wave-Smart-Metering-Packung/dp/B072XSBKJT
- langfristig wollen wir neben Einzelgeräten unsere Hauselektronik über Hutschienenelektronik steuerbar machen, also direkt über die (Unter)verteilerkästen -> erlaubt intelligentes Zuschalten von Werkstattbeleuchtung o.ä.
- Wünsche an "FabAccess"
- Software sollte von Sensoren möglichst viele Daten speichern (z.B. in einer Zeitdatenbank wie InfluxDB) - z.B. Stromverlauf, Einschalten, Ausschalten, Widerstandswerte, etc - “alles, was die Sensoren hergeben” -> Anzeigen + Auswerten von Lastgraphen hilft dabei ein Action-Event-Trigger-basiertes System zu entwickeln
- Einbindung an SingleSignOn (SSO), z.B. LDAP oder Radius (wir wollen irgendwann mal OpenLDAP und PrivacyID3A 2FA verwenden)
- Template-Customizing -> Farben, Banner, Icons anpassbar machen
- Berechtigungen von Benutzern sollten zeitlich konfigurierbar sein (Benutzer darf an Tagen X,Y,Z in den Zeitfenstern A,B,C) -> Zeitfenster schalten für Gäste, mobile Maker, Workshop-Teilnehmer, etc.
- ggf. Plugin-Architektur
- System mit i18n - Basiscs: Deutsch + Englisch
- Import/Export/Backup-Funktionen (ggf. Rollback von Konfigurationen bei fehlerhaften Settings) > XML, JSON
- Installierbarkeit mit oder ohne Containerisierung (Docker) auf wichtigen Systemen wie Linux-Distributionen, Windows, (MAC?)
- ggf. Reservieren/Ausleihen (ausbuchen) von mobilem Equipment
- Custom Property Fields zum Befüllen durch den Admin: bei den Reitern “Maschinen” und “Orte” wäre es schön, wenn man mehrere externe URLs anbinden bzw. Infos anreichern kann, die den Nutzer zu spezifischen Unterseiten verlinkt (z.B. externe Handbücher, Cloud-URLs, Fotos, etc.) oder z.B. diverse Eigenschaften/Kommentare anzeigt
- Infos bezüglich Software, die wir im FabLab Chemnitz verwenden >> Interoperabilität wünschenswert
- Teedy -> Dokumentenmanagement (Langzeitarchivierung Rechnungen, etc.)
- JTL Shop+WaWi -> speichern von Mitgliederstammdaten und Erfassen von Nutzungsgebühren (JTL Shop Anbindung)
- ZDF WISO MeinVerein - Rechnungslegung, Buchhaltung
- Grafana -> Monitoring, grafische Auswertung von Datenbanken (PostgreSQL, MariaDB, MySQL, MSSQL)
- Repetier Server (3D-Druck)
- Octoprint Server (3D-Druck)
- Confluence (Dokumentation zu Inventar, Tutorials, Projekte, IT-Stuff)
- Matrix Synapse (offener Chat-Server m. Bot-Integrationen) -> könnte später mal Statuswerte aus FabAccess anzeigen
- sonstiger Web-Kram im Peripheriebezug: WordPress, Plesk, PicApport, sysPass, Gitea
- diverse (bash-)scripts mit API Calls, die unsere Systeme bereits etwas verdrahtet
- Allgemeine Gedanken/Fragen zu FabAccess
- Ausfallsicherheit bedenken. Wie funktionieren die Vorgänge, wenn mal etwas offline ist? > Flexibilität in der manuellen Nacharbeit notwendig, falls der Server mal ein paar Tage nicht geht!
- welche Lizenz soll das Projekt haben? z.B. MIT, BSD, Apache, GNU GPL?
- unser damiliger Gedanke zu Abrechnung, Zugang, allgemeiner Verwaltung: https://wiki.fablabchemnitz.de/display/FCP/Projekt+Farringdon+ins+Leben+gerufen!+Die+zentrale+Inventar-+und+Buchungsplattform
- was verstehen wir unter einem Zugangssystem?
- Munich Makerlab
- Selbstgebautes System zum öffenen von Türen