Die folgenden Punkte kommen ursprünglich aus der Liste U300 Haustechnik
Das Portal der U300 besteht aus mehreren Komponenten, welche über MQTT miteinander kommunizieren:
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:
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.
Verbaut sind:
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:
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:
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.
Anwesende: xq, map, chris
Anwesende: xq, m1k3y, stefan, chris
Anwesende: xq, stefan
Anwesende: xq, m1k3y
authorized_keys
erzeugen wurde implementiertopenssl
wurde getestetAnwesende: xq, m1k3y, stefan
Es wurde folgende Projektziele erreicht:
Tasks, welche fett markiert sind, haben Priorität.
udev