Luftschleuse 2

Die Räume in der Aktueller Stand. 90 haben drei Außentüren: Haupteingang (Front), Hinterhof, Notausgang Keller.

Zu diesem Zweck war eine neue Architektur für die alte Luftschleuse1 notwendig, die wir Luftschleuse2 getauft haben.

• DOWN Kapsel zu, Strom aus –> Niemand da
• CLOSED Kapsel zu, Strom an –> Jemand da, aber nur kurz, oder im Keller, oder schläft o.Ä
• MEMBER Kapsel besetzt, Auch für Nicht-Keyholder-Member mit Token/Klingelcode betretbar. Oder halt klingeln oder klopfen und hoffen, dass jemand aufmacht.
• PUBLIC Kapsel besetzt. Auch Externe/Gäste etc. sollen kommen (Public Tuesday, Lockpicker, Vorträge…). Tür vorne: daueroffen.

muCCC-Mitglieder bekommen den Klingelcode beim Beitritt mit der Willkommensmail von Mailman.

Unter http://uberbus.club.muc.ccc.de/spaceapi.json bietet wir einen Space-API-Endpoint an. Status-Mapping:

• open: Status MEMBER oder PUBLIC
• closed: Status CLOSED oder DOWN

Unter http://spaceapi-stats.n39.eu/#muccc gibt es eine automatische Statistik, mit welcher Wahrscheinlichkeit um eine gewisse Uhrzeit offen ist. In der Regel ist fast jeden Abend ab 19-21 Uhr jemand im Club. Wir speichern aktuell nicht wie viele Leute gerade im Club sind. Entsprechende Live-Statistiken sind aktuell nur innerhalb des Club-Netzes zugänglich, z.B. mit dem Tablet das im Hauptraum auf dem Tisch liegt.

Zentraler Knotenpunkt ist ein Carambola, das über den Mastercontroller (MC) per RS485 mit den einzelnen Schlössern verbunden ist.
Die Schlösser haben eigene Elektronik (Lockcontroller bzw. im Diagram Controller und Benutzerschnittstelle in Form von einem Knopf.

Schematischer Aufbau:

Code und Hardware: https://github.com/muccc/luftschleuse2

Carambola, Mastercontroller und Lockcontroller Hintertür

Lockcontroller Vordertür

Taster Vordertür

IP: 192.168.2.2
Fingerprint: md5 8b:80:b3:e1:d4:38:86:87:42:75:d0:44:a6:81:46:96
User: open

• Anforderungen besser definieren
  • Funktion
    • Was soll ein Nutzer an den Schlosscontrollern einstellen koennen?
    • Welche Informationen werden an den Schlosscontrollern angezeigt?
  • Gehäuse
    • Wo werden sie montiert?
    • Wie sicher müssen sie sein?
  • Netzteil
    • Intern oder extern?
    • Fernspeisung über Busleitung
      • Lockcontroller werden ueber Bus versorgt, Hauptcontroller versorgt Bus ueber Netzteil
  • Benutzerinterface
    • LEDs oder Display in den Schlosscontrollern?
    • z.B. 1 7-Segment LED, das Codes ausgibt.
  • Komponenten
    • Wichtig fuer Layout, Vorschlaege weiter unten.
  • Akku
    • Wielange muss er halten?
    • * Solange wie eine Netzstörung dauert
    • * 48h wäre gut, Akkus werden ueber Zeit schlechter.
    • Was verbaucht das System im Ruhezustand?
    • * Sleepmode an Schlosscontrollern haben.
    • * Schlosscontroller über BUS oder Nutzerinteraktion wecken
    • Intern oder extern?
  • Software
    • Protokoll fuer RS485 festlegen

Das Carambola kontaktiert ueber den MC zyklisch alle Schlosscontroller.
Die Controller haben einen Hardware-Watchdog, der sie neustartet, wenn keine Aktivitaet auf dem Bus mehr erkennbar ist. Sollte ein
Schlosscontroller den Bus blockieren oder der MC bzw. Carambola sich aufhaengen startet das komplette System neu.

Alternativ: Hauptcontroller schaltet bei Problemen komplette Vesorgungsspannung des Bus.

Die Verbindung der Module erfolgt ueber Ethernetkabel. Zwei Aderpaare sind fuer die 12 V Versorgungsspannung reserviert. Ein Aderpaar
wird von jedem Schlosscontroller mit einem Widerstand belastet. Der MC wertet dieses Paar aus, um abgesteckte Schlosscontroller schnell zu erkennen.

Der MC leitet die Datenuebertragung transparent durch. Zwischen Carambola und Schlosscontrollern wird verschluesselt kommuniziert.

Ein Bleiakku stellt eine Notstromversorgung. Die Ladung erfolgt direkt aus dem Netzteil des Hauptcontrollers.

Serienwiderstaende 10 Ohm + Brueckengleichrichter mit Suppressordiode parallel.
“Kapazitaetsarme Schutzbeschaltung”

Wechselbare Feinsicherung von Netzteil zum Akku
Polyfuse vom Akku zum Bus

Wechselbare Feinsicherung, ueberdimensioniert in Serie mit Polyfuse.

Besser H-Bruecke aus Automotive mit Fehlerüberwachung z.B. Kurzschluß, Kabelbruch

Alternativ: Motorstrom mit A/D-Wandler abgreifen.

Vorteile: Kann Motorposition und Bewegung abschaetzen.

Vorschlag:

MC und Schlosscontroller: ATMEL ATMega644A-AU o.ae. (5 V, extended temperature, 2x UART)
RS485 Treiber: MAX487EESA (slew rate limited, extended temperature, esd protected)
Vorschlag: Potentialgetrennter RS485-Treiber-IC von LTC oder MAX, weil es immer Potentialdifferenzen gibt wegen anderer Speisung etc. Einfach zuverlaessiger.
Gehause: ? (Metall? Kunststoff? Wo und wie werden die Schlosscontroller angebracht? Wie gross werden Display und Schalter? Steckverbinder intern oder am Gehaeuserand? Netzteil und Akku intern?)
Display: ? Farbige LEDS wohl besser auf Entfernung ablesbar. Gut wäre 7Segment LED, rot
Taster: Reichelt TASTER 1104 GN Serie
Netzteil: z.B.: Reichelt SNT MW25-12 (zum Einbau in das Gehaeuse)
Akku: z.B.: Reichelt LCR-12V 2,2P (2.2 Ah), besser 5,7Ah

Schaltplan soweit mal erstellt, werde den nachher noch von zuhause mal hochladen.

Atmel ATMega 324A, lagen noch 3 im Labor, wenn es der 644A werden soll, ist ja Pinkompatibel.
Schaltregler 5 V LM2594 0,5 A
Reset/Watchdog MAX705, überwacht RS485, wenn kein Datenverkehr, löst er Reset aus, außerdem Manueller Reset über die protection Loop möglich.
MAX48x als RS485
Eine SOT23 Referenz als Option (REF3040 etc.)
L6201 als H-Brücke für den Schlossmotor ()
2 Relais als potentialfreier Wechsler, 230V geeignet
2 digitale Ausgänge
8 Analoge oder digitale Eingänge (Port A, so das auch der ADC genutzt werden kann) Magnetkontakte, Steuerkontakte vom Schloss etc.

Display soll eigentlich am Carambola Interface angeschlossen werden, evtl. 2. serieller Port noch rausgeführt für Display/lokale Bedienung

1x Dorma SVP2719
1x Dorma SVP3XXX
1x CES IES Beschlag Drücker Kupplung

Der Club muss wie bisher auch per SSH durch designierte Keyholder “aufgeschlossen” werden; die Verwaltung der Keys wäre wohl wieder per git.

Zusätzlich dazu erhält jeder Türcontroller auch ein oder mehrere alternative Zugangsmedien, bspw. für RFID-Chips. Entsprechende Chips können dann an Members ausgegeben werden, sodass diese sich Zutritt zum Club verschaffen können, sofern per SSH von einem Keyholder der Club aufgeschlossen wurde. Alternativ können natürlich auch bereits vorhandene Zugangsmedien der zutrittswilligen Members erfasst werden anstatt noch etwas mehr Plastik zu verteilen (Firmenausweise, Handys mit NFC, Studentenausweise, etc. pp.). Da es sich bei diesen Zugangsmedien nur um einen besseren Türöffnerknopf handelt, ist die Sicherheit als solches eher nachrangig und man könnte sich bspw. auf die Prüfung der UID des Mediums beschränken. Verwaltung der UIDs wäre dann u.U. auch ein Job fürs git.
Was für Hardware braucht es dafür noch extra?
Ich habe noch ein paar alte Elektroniken aus CES Legic Zylindern, die werden für Studentenausweise in MUC benötigt, verwaltung erst mal mit der Progkarte.
ISO Tag (Mifare und OK) evtl. mit einem OpenPCD, später wäre auch eine all in one Lösung denkbar, wir brauchen ja nur die UID abfragen und die könnten später auch über Lockbus vom Carambola zum Leser geschrieben werden.

Meiner Meinung nach koennen wir an die Hintertuer auch einfach ne Klinke bauen und sie offen lassen — schneider 2012/12/07 22:08
Bin fuer OpenPCD, denn wir haben die Macht darueber, und muessen nichts reversen etc. (luja)

BTW: Ist das nicht etwas over-engineered? (luja)

Vordertuer:
Zustaende: Abgesperrt (man kommt immer raus), Public (jeder kommt von draussen rein), Offen (Mitglieder kommen mit zusaetzlicher RFID-Karte oder Klingelcode rein)
Sensoren: Klinke gedrueckt, Tuer offen

Hintertuer:
Zustaende: (siehe oben) Abgesperrt, Public, irgendwie auch Offen
Sensoren: Klinke gedrueckt, Tuer offen

Beide Schlösser können jederzeit von innen geöffnet werden, verriegeln aber und fallen nicht nur in den Schnapper.

SSH auf open@, die Hintertuer oeffnet einmal.
An der Steuerung kann eine Taste gedrueckt werden um alle Tueren auf Offen zu schalten. Einzelne Tueren koennen danach direkt an der jeweiligen Tuer auf Public geschaltet werden.
Hinweise fuer Stromausschalten werden aktiviert.

Wollen wir erstmal nicht, aus Komplexitaetsgruenden und anderem.

Knopf an der Steuerung an der Hintertuer sperrt alle Tueren. Eine Anzeige zeigt an, dass alle Tueren geschlossen haben.
Der Strom wird falls moeglich automatisch abgeschaltet.

Einzelne Tueren: Taster fuer Offen/Public fuer die einzelne Tuer
SSH: Einmal oeffnen der Hintertuer
Zentrale-Steuerung: Taster fuer Offen (wirkt auf alle Tueren) und Taster fuer Closed (wirkt auf alle Tueren)
Zentrale-Steuerung Anzeigen: Zustand des Systems, rote LED falls der Befehl Close nicht ausgefuehrt werden konnte (Warnton, falls die Tuer dennoch geöffnet wird)

An der Luftschleusenhauptsteuereinheit gibt es Taster, um den Zustand der Kapsel explizit zu setzten. Dies löst entsprechende Türzustände aus, setzt das Topic entsprechend und kann auch anderweitig ausgenutzt werden (Statuslampen, …).

• Damit man nicht aus versehen “public” auslöst müssen 2 Taster gleichzeitig gedrückt werden (Vorne + Hinten), wahlweise mit ssh- (public@luftschleuse)

Schaltplan vom EVVA EMZY: evva-emzy-emz02.3.pdf

Stecker Frontpanel:

1: LED Down
2: LED Closed
3: LED Member
4: NC
5: GND
6: Switch Public
7: Button Member
8: Button Closed
9: Button Down

Buchse Frontpanel:
1: Brown
2: Orange
3: Green
5: Blue
6: Blue-White
7: Green-White
8: Orange-White
9: Brown-White

Kabel Frontpanel:

Brown-White: Button Down
Orange-White: Button Closed
Green- White: Button Member
Blue-White: Switch Public

Brown: LED Down
Orange: LED Closed
Green: LED Member

Blue: Gnd

Schaltplan Schloss: svp2719_schematic.pdf

Stecker 65239-007LF - Wire-To-Board-Steckverbinder, 2.54 mm, 14 Kontakt(e), Buchse, DUBOX 65239