• WLAN: Portal-Dev (später: portal)
• Aufschließen (Fronteingang): ssh open-front@portal.shackspace.de
• Aufschließen (Hintereingang): nicht implementiert
• Abschließen: ssh close@portal.shackspace.de
• Statusabfrage: ssh status@portal.shackspace.de
• Statusabfrage (maschinenlesbar): ssh status@portal.shackspace.de simple-status. Die möglichen Antworten stehen unten.
• Alternative mit SSH command: Es kann jeder Benutzer auch als Befehl hinter einen anderen Benutzer geschrieben werden, hiermit können auch Apps wie Trigger bedient werden. Beispiel:
  • ssh status@portal.shackspace.de open-front
• Türen
  • A: Die Holztüre an der Straße
  • B: Die Glastüre an der Straße
  • B2: Die innere Türe zum shackspace, an der Straße
  • C: Die Hintertüre auf dem Hof.
  • C2: Die innere Türe zum shackspace, Richtung Hof
• shack-Zustände
  • open: shack ist aufgeschlossen und open for public
  • locked: Alle Türen sind abgeschlossen, shack ist zu.
  • unlocked via b2: Der shack ist aktuell nur über die Türe B2 betretbar.
  • unlocked via c2: Der shack ist aktuell nur über die Türe C2 betretbar.
  • unobserved: Die Sensoren haben noch keine ausreichenden Informationen für die Zustandserfassung geliefert.

Die folgenden Punkte kommen ursprünglich aus der Liste U300 Haustechnik

• wie viele und wo brauchen wir Motorschlösser?
• Punkte, an die zu denken ist:
  • Türschloßantrieb z.B. Homematic
  • Entkernen, wir brauchen nur den Antrieb
  • Stromversorgung für den Motor und Zuführung zum Motor. Bitte für Türe und Rahmen minimalinvasiv ausführen /!\
  • Raspi mit WLAN, SD-Card & Stromversorgung jeweils für Raspi und Motor - Vorhanden sind: Raspi B+, WLAN-Adapter TL-WN725N, Türschloßantrieb
  • Kontakt für Türblatt und den Schließriegel. Bitte für Türe und Rahmen minimalinvasiv ausführen /!\
  • shack-status mit der Info des Kontakts in der Türfalle füttern
  • wollen wir beide Türen mit dem Portal kontrollieren oder nur eine? Welche?
  • Beide Türen zu den shack-Räumen haben 10..11mm Überstand des Schlisszylinders. Check.
  • Die Eingänge „B“ und „C“ sind über Buzzer zu öffnen. Es bedarf eines Relaiskontakts parallel zum Drücker an der Türsprechanlage.

• In Raum 04 ist die Gegensprechanlage S, um die Tür zu öffnen
• An Türe B ist ein (potentiell KNX-fähiger) Türöffner (ungeklärt, ob er KNX frisst)
• Tür B1 ist nicht verschlossen
• Tür B2 hat einen Schließzylinder
• Türe C (Hintereingang) ist typischerweise abgeschlossen, ohne Türöffner (dürften Schlüssel nachmachen)
• Türe C1 hat keinen Schließzylinder.
• Türe C2 hat einen Schließzylinder.
• Türe A1 ist eine Türe, die von innen immer geöffnet werden kann, aber von außen einen Schlüssel benötigt. Benötigt Hausschlüssel
• Türe B ist eine Türe mit Schließzylinder und dem Hausschlüssel.
• Als Türklingel m. Gegensprechanlage und Türöffner ist an Eingang B eine Busch-Welcome Anlage installiert.

• Die shack-Vordertür (B2) wird wie in 0xFF mit RaspberryPi + Motorschloss geöffnet und geschlossen. Hierfür werden auch Reedkontakte für „Türe ist mechanisch zu“ sowie „Schließbolzen ist im Schloss“ benötigt.
• Die shack-Hintertür (C2) wird wie die Vordertür mit einer Portalschaltung versehen
• Wenn shack-Vordertür (B2) geöffnet wird, muss die Gebäude-Vordertür (B) mit der Buzzer-Schaltung für eine gewisse Zeit geöffnet werden. Dies sollte potentiell erst einige Sekunden nach dem Schließen der SSH-Verbindung enden, damit man Zeit hat, seine Geräte wieder zu verstauen und die Türe aufzudrücken
• Für die Gebäude-Hintertür (C) muss eine technische Lösung etabliert werden, um diese auf/abschließen zu können, um Zugang zur shack-Hintertür (C2) zu erhalten
• Die Klo-Tür (To) sowie die Zwischentüre (A1) müssen mit einem Klo-Button ähnlich dem in der 0xFF gelöst werden. Dies ist aber potentiell ein separates Projekt.

• Hinter- und Vordertür sollten nicht synchron aufgeschlossen werden, aber zugeschlossen
• Hierfür open@ für vorn, backdoor@ für hinten und close@ für „gesamten shack schließen“?
• Portal-Einheiten müssen miteinander reden für synchronen Close-Request

Das Portal der U300 besteht aus mehreren Komponenten, welche über MQTT miteinander kommunizieren:

• MQTT-Broker
  Zentrale für Nachrichtenverteilung. Stellt zudem den WLAN-Zugang sowie DHCP/DNS zur Verfügung.
• 2 Türsteuerung (Für Türen B2 sowie C2)
  Übernehmen die Steuerung einer Türe und überwachen die Sensorik.
• Busch-Interface
  Reagiert auf Klingel-Signale und entsperrt die Türe B2.

Die MQTT-Nachrichten sind nun in der Software an einer zentralen Stelle dokumentiert.

eqiva 142950A0 (Key-BLE)

Für das vollständige zerlegen benötigte Schraubenzieher:

• Sechskant 2.5mm
• Torx T6

• STM8L052C6-Prozessor (`STM8L052`, `C6T6, 99020, 07VG`, `MYS 99 936` )
• CYW20736-Prozessor (`S`, `2007 G 15`, `CYP 604473`, `TWN`)
• 2× Motor
  • Motor 1 dreht das Schloss aktiv auf und zu
  • Motor 2 betätigt eine mechanische Kupplung, welche Motor 1 und Schloss mechanisch trennen kann
• 2× RP752G (`IOSB_`, `F7317`), potentiell HEXFET Power MOSFET für H-Brücke der beiden Motoren
• Manuell implementierter Drehencoder(?) mit 2 Schaltern
• Testpunkte für PRG1 (Proz: ???) und PRG2 (Proz: ???) verfügbar, vermutlich Programmierinterface für STM8L052C6 und CYW20736.
• Versorgung via 3 * Mignon-AA-Zellen, also ca. 4.5V
  • 1mA Stromaufnahme im Standby
  • ~400mA Stromaufnahme bei dauerhafter Motorbewegung (unbelastet)
  • ~900mA Stromaufnahme bei Anfahren (unbelastet)
  • ~1000mA Stromaufnahme bei Blockieren
• Motor fährt beim Anschalten kurzzeitig zurück, und anschließend in die gewünschte Richtung
• Die Motoren werden direkt mit der Batteriespannung versorgt

Das Motorschloss hat im Batteriefach jetzt Schraubklemmen, die die beiden Taster sowie die Stromversorgung (4.5V) bereitstellen.

Die Schalter SW0 und SW1 haben jeweils zwei Anschlüsse, hierbei ist + jeweils der aktive Schalteingang (active low) und - die jeweilige Masse des Schalters. Der Anschluss BAT erwartet zwischen - (GND) und + (VCC) 4.5 Volt. Hier ist zu klären, ob auch 5V Versorgungsspannung gehen.

• Busch-/ABB-Welcome Systemhandbuch
• System controller ABB-Welcome 83300-5..
  • neben Tür B2
  • Türöffner (Tö) wird mit internen 12V~ versorgt. Für direkte Ansteuerung wäre also ein Wechselkontakt zur Vermeidung von Kurzschlüssen nötig.
  • Tö wird für 1s bis 10s (einstellbar an der Zentrale) aktiviert. Die Tür kann geöffnet werden, solange es „summt“.
  • Innenbus OUT1 ist im Rack 1-UG-2-2, AMP-Panel „51-100“, Port 21-25 aufgelegt und nach 1-UG-1-2 B022, B028, B046, und B089 gepatcht.
  • Innenbus OUT2 ist unbeschaltet. Restleistung von ~30W sollte für einen RPi reichen :)
• Außenstation Busch-Jaeger 83101
• Sprechstellen vom Typ 83205-AP-6xx Betriebsanleitung Bedienungsanleitung
  • Vermeintlich teildefekte Geräte (Klingel und Sprechverbindung gehen, Tö und Licht leuchtet lokal aber bewirkt nichts) können wiederbelebt werden: Es findet ein Handshake beim Systemboot statt → Sicherung F52

Verbaut sind:

• PIC16F1946
• Nuvoton I2130SYI Design Guide
  • Klingelton-Speicher mit eingebautem Verstärker für Klingel-Lautsprecher
• JRC NJM4558D: dual 741, siehe RC4558
  • Verstärker (und Filter/Mixer?) für Mikrofon
• Microchip MCP6002
• Jede Menge BC817-25 (NPN, 500mA) und BC807-25 (PNP, 500mA)
  • Vermutlich hauptsächlich Interface zur 2-Draht-Leitung

In einer Audio-Aufzeichnung direkt am Bus kann man etwas verstehen. Die massiven Störungen sind aber im Hörer nicht zu hören. Könnte Telefon-Filter 300-3400Hz sein oder sie nutzen nicht nur PAL-Video sondern auch den Ton-Träger bei 5.5MHz.

Die Kommunikation Terminal → Controller scheinen ~250mA Pulse zu sein. Gegenrichtung sieht in der Aufzeichnung ähnlich aus.

Der Tö-Taster ist an R72 angeschlossen und geht nach GND. Der Taster für die lokale Klingel arbeitet auch so. An der Steckverbindung ist DB_EX das aufbereitete (L, R, TVS-Diode) Signal. Achtung! GND könnte floating sein. Nicht mit a1 oder b1 mixen! → Klingel am Stecker herausgelöst und mit Kabel zu R72 ersetzt.

Auf dem „Power“-Modul war ein Relais nicht bestückt. Q1 schaltet die Versorgung des I2130SYI mit 3.3V solange an, wie die LED in der Tö-Taste blinkt. Die LED selber hat keine zugänglichen Lötpunkte auf der Bestückungsseite. → Ein SFH6156 Optokoppler hat auf den Relais-Pads eine ordentliche Klemme bekommen. Anode an Q1/D6 und Kathode über 270 Ohm an GND

Neue Klemmenbelegung:

• a1
• b1
• Tö-Taster
• GND für Tö-Taster
• Emitter Optokoppler
• Collector Optokoppler

Mit Brücken zwischen 3 und 6 sowie 4 und 5 öffnet Klingeln die Tür. An den ESP32 sollte also ein weiterer Optokoppler als „Taster“.

Es wurde ein ESP32 Board (WT32-ETH01) mit dem Busch-Welcome galvanisch getrennt verbunden. Die Kabelbelegung ist wie folgt:

• Grau: GND
• Orange: 5V
• Gelb: Klingelsignal (Grau ist GND ref)
• Braun: Emitter
• Lila: Collector

Das Klingelsignal ist auf dem ESP als IO15 verfügbar (benötigt internen Pull-Up), die Türe kann via IO39 geschaltet werden.

Die Software wird aktuell auf GitHub entwickelt.

Die Gedanken hinter diesem Prozess sind folgende:

Es ist sinnvoller, immer erst eine Türe aufzuschließen und die zweite Tür nur dann zu öffnen, wenn die erste Türe tatsächlich benutzt wurde (also nicht nur aufgeschlossen ist, sondern auch geöffnet wurde).

Dies ist notwendig, dass der Fehlerfall „Türöffner funktioniert nicht“ abgefangen werden kann, denn niemand wird in dem Moment denken: „Oh, ich hab doch aber grade aufgeschlossen, die Tür im Gebäude ist ja noch offen“. Dies wird noch verstärkt durch das fehlende direkte Feedback (man steht auf der Straße und hört den Türmotor nicht arbeiten). Daher wird die Türe nur für 60 Sekunden aufgeschlossen, anschließend wird wieder abgeschlossen, außer die Türe wird in der Zwischenzeit geöffnet (Bestätigung von „Benutzer hat Gebäude erfolgreich betreteten“).

Beim Schließen können einfach beide Türen abgeschlossen werden, der shack kann aktuell sowieso nur durch die Türen A1, anschließend A zuverlässig verlassen werden. C ist potentiell abgschlossen.

• minimal invasiv im Hinblick auf die Mietsache
• vollständig rückbaufähig
• robust
• mechanisch sachgerechter Aufbau
• ohne Heissklebstoff, Klebeband, fliegende Leitungen o.ä. pfuschige Methoden

• Leitungen werden in Kabelkanälen geführt
• um das Kabel zwischen Türe und Wand zu führen wird ein Kabelübergang verwendet.

Anwesende: xq, map, chris

• Sichtung der vorhandenen Materialien
• Drop von Relaiskarte, SD-Karte, Installationskabel (2- und 3-adrig, jeweils 20m), 8fach-Relaiskarte, 12V-zu-5V-USB-Netzteil
• Reverse-Engineering des Motorschlosses
• Umbau des vorhandenen Motorschlosses von (manuellem) Batteriebetrieb auf externe Stromversorgung+Schalter
• Montage SD-Karte und WLAN-Adapter am RaspberryPi
• Installation eines RaspberryPi OS auf der SD-Karte
  • Statische IP auf wlan0 eingerichtet (/etc/network/interfaces.d/wlan0)
  • ssh-Zugang aktiviert
  • Aktuell Defaultuser shack/shackit sowie root-User
  • Setup-Versuch von HostAPD, scheitert aber an „interface wlan0 not up.“

Anwesende: xq, m1k3y, stefan, chris

• Material wurde von Chris organisiert
  • Ausreichend Reedkontakte für Einbau- und Oberflächenmontage
• APUs wurden auf Funktionsfähigkeit geprüft
  • WLAN: gut
  • Problem: GPIOs: Unbenutzbar, es gibt keine funktionierenden Treiber
  • Lösung: Wir benutzen den RPI als IO-Device, die APU als WLAN-AP
• Es wurde versucht, das WLAN auf dem RPI funktionsfähig zu machen
  • Problem: Unmöglich mit vorhander WLAN-HW, da kein Support in HostAPD sowie Kernel für WLAN-Modul
  • Lösung: APU macht MQTT-Broker, WLAN (ggf. mit Captive Portal), DHCP und DNS im Portal-Netzwerk
• Diskussion über die User-Workflows mit dem Portal sowie die Abläufe in der Software
  • Siehe hier
• Türöffner-Ansteuerung und Türklingel-Auslese wurde erfolgreich gehackt
  • Hierfür wurde von kr4bat ein ESP32 mit Ethernet organisiert
• Motorschloss wurde an Fronttür(B2) montiert
• GPIO-Library wurde in Portal-Software integriert und notwendige GPIOs identifiziert
• Tür-Ersatz wurde gelötet, um Software zu testen (Drei Buttons, zwei LEDs auf kleiner Platine)

Anwesende: xq, stefan

• Die GPIOs vom Pi wurden lauffähig gemacht
• Es wurde die Ablauf-Sequenz für ÖFFNEN und SCHLIESSEN definiert und implementiert
• Der ESP32 wurde erfolgreich mit der Sprechstelle verheiratet

Anwesende: xq, m1k3y

• Die APU wurde vorbereitet
  • WLAN, DHCP, DNS eingerichtet
  • MQTT-Server installiert
  • Experimente mit Captive Portal, es wird leider nicht so einfach, Android von gutem Verhalten zu überzeugen. Apple ist da gemütlicher
• Ein neuer Key-Export-Prozess wurde definiert
• Key-Export aus dem Byro wurde implementiert
• authorized_keys erzeugen wurde implementiert
• Signieren und Verifizieren der Signatur mit openssl wurde getestet
• Neues Konzept für Türsteuerungen: Statt RPI wird nun ein ESP32 benutzt, SSH terminiert nur auf der APU
  • 4 weitere ESP32-Boards wurden bestellt

Anwesende: xq, m1k3y, stefan

• Die Portal-Software wurde auf die APU deployed.
• Es wurde ein Script zum automatischen Import eines Key-Exports entwickelt.
• Umbau der beiden Software-Repositories in ein großes Monorepo.
• Ein ESP wurde erfolgreich in die Busch Welcome-Interface integriert.
• Es wurde eine Platine für die Motorsteuerung gelötet.
• Motor-Steuerung wurde mechanisch reperiert, Freilauf funktioniert jetzt wieder zuverlässig.
• Integrations-Versuch von Motorsteuerung, Busch Welcome-Interface sowie des Daemons.
• Motor-Stromaufnahme wurde noch einmal mit besserem Messgerät verifiziert.

Es wurde folgende Projektziele erreicht:

• Die Fronttüre B kann nun per SSH geöffnet werden!
• Die Fronttüre B kann nun per Klingel geöffnet werden, wenn der shack als aufgeschlossen gilt.

Anwesende: xq, chris, jens, stefan

• Montage des Trägers für die Türelektronik
• Montage des Trägers für den Magneten des Sensors zur Erkennung der Position des Türblatts und des Magneten selbst

Anwesende: xq, stefan, chris

• Einbau von Magneten & Hallsensoren in die Einsteckschlösser zur Erkennung der Position der Schließriegel

• Statemachine der Firmware auf neues Modell umschreiben
• Zweite Hardware fertig stellen
  • Magnetsensor an der Türe anbringen
  • Elektronik bespaßen
  • Verkabelung organisieren
• System-Reset via MQTT implementieren
• Debug-Interface implementieren
• Vorstands-Scripte fertigstellen
• Portal-Box clean aufsetzen
• Neue CA erzeugen und neue Keys deployen