Modulares Smarthome Zugangssystem - Konzeptentwicklung

[Masifi]

Auf der Suche nach einem passenden Zugangssystem für unser kleines Häuschen, bin ich bei dem auf dem Markt vorhandenen Systemen nicht fündig/glücklich geworden. Zusammen mit einem Freund, der gerade auch sein Haus errichtet, haben wir die Idee ins Leben gerufen, doch selber mal so ein System zu entwickeln.

Dabei war uns wichtig:

• Einfache Einbindung ins Smarthome
• Modular aufgebaut
• Einfach erweiterbar
• Austauschbar -> HW-Upgrade, erfordert keinen kompletten Austausch aller Komponenten

Dazu gab es schon eine Vorstellungsrunde, wo wir den aktuellen Stand und unsere Ideen vorgestellt haben. Die Folien der Präsentation liegen hier ab: Vortrag_AccessControl.pptx (link einfach draufklicken)

Die Architektur des Aufbaues ist hier zu sehen
image.png

Der gesamte Aufbau ist in zwei Phasen aufgeteilt.

Phase1:
Definition des Grundaufbaus mit einem Controller im Hutschienengehäuse der Über RS485 mit seinen Modulen/Slaves kommuniziert. Die Module/Slaves besitzen wieder einen eigenen µC an dem dann die Eingabegeräte (FP,RFID, NFC, Wiegand, Homekey, ...) angebunden sind.

Phase2:
Ist Stand heute nur eine Idee. Das könnte ein modulares Videotürkommunikationsmodul werden ala Doorbird und Co.


Hier in diesem Beitrag werden wir immer wieder den aktuellen Stand berichten und Ihr dürft gerne euer(e) Feedback, Kritik, Verbesserungen, Ideen äußern.

Falls jemand hier aktiv mitarbeiten will, der darf sich gerne bei uns melden.



Unser aktueller Testaufbau
IMG_1164.jpg

[Masifi]

block

[Masifi]

block

[Masifi]

block

[LostWolf]

Sieht wirklich hoch interessant aus
vermutlich aber leider für mich zu spät :/

Was ich wichtig finden würde für die Slaves:
-Binäreingänge für Klingeltaster
-zwei/drei RGB-LEDs für Statusanzeigen (Alarmanlage scharf etc.)
-Option mit unterschiedlichen Fingern unterschiedliche Optionen auszuführen (wieder die Alarmanlage als Beispiel)
-evtl. ein Summer/Lautsprecher als Feedback (Pieptöne reichen)

Was ich wichtig finde für den zentralen Controller:
-Anbindung an KNX (SOM-UP Garagentor usw.)
-Konfigurierbar wie lange die Relais anziehen bei z.B. der Türöffnung

Was ich für die KNX Anbindung wichtig finde:
-Senden welcher Finger gerade an welchem Slave erkannt wurde
-Binärein-/ausgänge von den Slaves und Controller durchleiten

Aber gerade die Modularität und Erweiterbarkeit spricht mich ungemein an.
(vielleicht wäre da ja sogar ein Packet/Postkasten mit anbindbar)
Bei einer eventuellen Gegensprechfunktion muss man halt schauen wie das modern umsetzbar ist. So das man auch extern "telefonieren" und sehen könnte.
Hatte mich vor vielen Jahren mal in das doorPi Projekt eingelesen, aber aufgrund der schlechten Zugänglichkeit für Einsteiger (Linux...) das Interesse wieder verloren gehabt.

[Masifi]

Was ich wichtig finden würde für die Slaves:
-Binäreingänge für Klingeltaster
-zwei/drei RGB-LEDs für Statusanzeigen (Alarmanlage scharf etc.)
-Option mit unterschiedlichen Fingern unterschiedliche Optionen auszuführen (wieder die Alarmanlage als Beispiel)
-evtl. ein Summer/Lautsprecher als Feedback (Pieptöne reichen)

Das haben wir alles schon auf dem Plan, die zusätzlichen LEDs könnte man noch als Option aufnehmen.

Was ich wichtig finde für den zentralen Controller:
-Anbindung an KNX (SOM-UP Garagentor usw.)
-Konfigurierbar wie lange die Relais anziehen bei z.B. der Türöffnung

KNX wird auf jeden Fall kommen, wie es umgesetzt wird, ist noch nicht ganz klar. Im Moment sieht es so aus, als ob es dann wie bei Ekey ein Zusatzmodul gibt, das man an den RS485 anbinden kann.
Die ganze Konfiguration soll dann auf einem Webserver stattfinden mit einer passenden API dazu.

Was ich für die KNX Anbindung wichtig finde:
-Senden welcher Finger gerade an welchem Slave erkannt wurde
-Binärein-/ausgänge von den Slaves und Controller durchleiten

Das sollte später alles möglich sein.


Aber wir sind gerade noch in der Konzeptphase und schauen, wie man hier ein gutes Fundament schafft, damit man später das auch alles umsetzen und "einfach" erweitern kann.

Im Moment arbeiten wir

• an der Kommunikation zwischen Controller und den Slaves. Alleine hier gibt es schon etliche Fallstrike. Was passiert wenn sich ein Slave nicht mehr meldet, oder es einen Kurzschluss auf der PWR / RS485 Leitung gibt (das soll alles in der HW vom Controller überwacht und ausgelesen werden können). Wie verhält sich das ganze System und wie kommt es zum Normalbetrieb wieder zurück.
• am Webinterface: Erste Schritte zum Testen und Ausprobieren mit dem ESPUI als webbasiertes User Interface war nicht zielführend, da es im Hintergrund von ESPUI noch den ein oder anderen bekannten BUG gibt, der nicht behoben wird/wurde. Jetzt geht es den klassischen Weg mit REST-API und custom Webseite.

Wir wollen hier noch nicht zu viel versprechen, dafür ist es gerade noch zu früh. Erst wenn wir ein gutes Grundkonzept gefunden haben und einen lösbaren Weg sehen, wird sich zeigen, ob daraus was gutes werden kann.

[BadSmiley]

Für wiegand gibt es schon einiges. Wie wäre ein wiegand, knx Kontroller? Die Verwaltung der Zugänge im Kontroller. Ob den wiegand Geräten kommt nur die Eingabe.

[fsl]

die zusätzlichen LEDs könnte man noch als Option aufnehmen

Dem Vorschlag von LostWolf will ich unbedingt zustimmen. Es wäre schon praktisch, wenn man die Möglichkeit hätte, ein-zwei Sachen optisch zu signalisieren ohne zusätzliche Drähte zu legen.

Für mich relevant wäre vor allem auch eine einfache Einbaumöglichkeit in gängige TK-Systeme, z.B. Gira 106. Das scheint mir aufgrund der Größe der FP-Leser eher schwierig zu sein. Idealerweise wäre die Platine auch schon "draußen" und damit eher kompakter, so dass man eben dort weitere Sachen wie LEDs anschließen kann.

[Masifi]

Für mich relevant wäre vor allem auch eine einfache Einbaumöglichkeit in gängige TK-Systeme, z.B. Gira 106. Das scheint mir aufgrund der Größe der FP-Leser eher schwierig zu sein. Idealerweise wäre die Platine auch schon "draußen" und damit eher kompakter, so dass man eben dort weitere Sachen wie LEDs anschließen kann.

Das verstehe ich noch nicht, warum scheint das schwierig zu sein? Wo liegt das Problem beim Gira 106?
Die Slave-Platine ist schon für draußen gedacht. Kompakter ist noch etwas möglich, aber nur sehr minimal. Auf die Platine muss halt, uC, RS485, DC/DC, Ansteuerungen für FP, NFC, …

[fsl]

Da ist im Aufputzgehäuse kaum Platz nach hinten, zumal wenn man da auch noch die Zuleitung einführen will.

[Masifi]

Wieviel Platz hat man denn?

Aber daran werden wir nichts ändern können. Wir werden keinen FP bauen, wir nehmen das was es gibt 😉

[Noschvie]

Am Controller ist ein ESP32 ETH zu erkennen, welcher µC ist bei den "Eingabegeräten" / Remote (statt Slave) im Einsatz?

Wie sieht das Software / Firmware Konzept aus?

Es ist ein R503-Fingerabdrucksensor im Einsatz, oder? Wie erfolgt die Anbindung software-seitig, werden RX/TX/Touch direkt an den Controller weitergegeben oder läuft da zumindest ein Teil / die Library am Remote ?

Hat das "Eingabe" / Remote Device 12V für eine Wiegand Anbindung und werden D0 und D1 am Remote verarbeitet oder direkt an den Controller weitergegeben?

[fsl]

Wieviel Platz hat man denn?

Das kann ich Dir nicht genau sagen, da verbaut und ich das nicht aufmachen will. Vielleicht findet sich jemand, der das noch unverbaut liegen hat.

[Masifi]

Am Controller ist ein ESP32 ETH zu erkennen, welcher µC ist bei den "Eingabegeräten" / Remote (statt Slave) im Einsatz?

Im aktuellen Konzept ist der Controller ein ESP32 und die Module/Slaves sind RP2040. Das kann sich aber alles noch ändern.

Wie sieht das Software / Firmware Konzept aus?

Das ist eine Eigenentwicklung auf PlatformIO im ARDUINO Framework.

Es ist ein R503-Fingerabdrucksensor im Einsatz, oder? Wie erfolgt die Anbindung software-seitig, werden RX/TX/Touch direkt an den Controller weitergegeben oder läuft da zumindest ein Teil / die Library am Remote ?

Ja es ist ein R503 und nein die Daten geht nicht direkt zum Controller. Jeder Slave besitzt seine eigene Recheneinheit. D.h. beim RP2040 arbeitet ein CORE nur an der Kommunikation mit dem Controller und der zweite CORE ist frei für die Anbindung der Eingangsstufen (FP, RFID, NFC, ...)
Wir wollen das bewusst getrennt halten, so das die Kommunikation zum Controller nicht durch externe Einflüsse gestört werden kann.

Hat das "Eingabe" / Remote Device 12V für eine Wiegand Anbindung und werden D0 und D1 am Remote verarbeitet oder direkt an den Controller weitergegeben?

Auch hier das gleiche. Die Wiegand Schnittstell hängt direkt mit D0 und D1 am Slave und der Slave verarbeitet die Daten vom Wiegand Device auf einem CORE und Kommuniziert wird mit dem Controller auf dem anderen CORE.

Zwischen Controller und den Slaves erarbeiten wir gerade ein Protokoll, dass das später alles abdecken wird. Das Protokoll soll so ausgelegt werden, das es später egal ist, ob ein R503 oder R502, oder ... FP angeschlossen ist. Ausnahme ist das Synchronisieren der FP-IDs mit anderen FPs. Hier muss die HW dann natürlich schon passen.
Oder wenn man ein LED schalten will am Slave. Dann sagt das Protokoll nur, schalte an/aus. Im Slave selber wird dann entschieden wie man das ausführt. Damit kann man später auch die Slave HW austauschen, solange sie sich an das Protokoll hält, funktioniert alles ganz normal.

Das steckt aber alles noch in den Kinderschuhen, mal schauen was daraus wird.

[Noschvie]

Wenn ich das so lese und es "sickern" lasse, denke ich, dass ich die Phase 1 überspringen würde und gleich auf ETH gehen würde, mit oder ohne PoE.

Habe mir mal einen R503 und einen PN532 bestellt, mal sehen wie ich damit zurecht kommen.

Spannend wäre sicherlich ein NFC Reader für die MIFARE DESFire Serie und Cryptography ...