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

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

Der Tö-Taster ist an R72 angeschlossen und geht nach GND. Auf dem „Power“-Modul ist ein Relais nicht bestückt. Ein Optokoppler dort hätte dann eine ordentliche Klemme.

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.

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.

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)

• Material organisieren
  • 1 Türschloßantrieb für Hintertür(C2)-Projekt organisieren
  • RaspberryPi für Hintertür(C2) organisieren
  • Neue, Linux-mainline-kompatible WLAN-Sticks organisieren
• Arbeitsgebiet: Fronttüre (B2)
  • Motorschloss-Bluetooth deaktivieren
  • Motorschloss mit Strom versorgen
    • Einfache Lösung: Kabel sauber auf Tür verlegen
    • Fancy Lösung: Kontakte im Türrahmen montieren, sodass Motorschloss mit Strom versorgt wird, wenn Tür geschlossen. Türschließkontakt kann hiermit auch implementiert werden
  • Türbolzen-Lösung in Türschloss integrieren und Anschluss bereitstellen
• Arbeitsgebiet: Hintertüre (C2)
  • Materialorganisation abwarten
• Arbeitsgebiet: Türöffner
  • Hardware mit Optokopplern versorgen
  • ESP32 mit Firmware bespielen (Ethernet, MQTT+Client certificates, IOs) (macht m1k3y)
  • Hardware mit ESP32 verkuppeln
• Arbeitsgebiet: Netzwerk/Infrastruktur
  • Plätze für die Geräte (PI-B2, PI-C2, APU, Türöffner) finden
  • APU aufsetzen (macht m1k3y)