Hallo zusammen,
leider habe ich heute erst davon erfahren, dass DoorPI zu neuem Leben erweckt werden soll.
Wenn in diesen Bereichen Unterstützung hilfreich ist, dann können wir uns gerne unterhalten:
- Web-Frontend-Entwicklung (HTML, CSS, JS)
- NodeJS
- Node-RED
- Eventuell auch Testing
Im Discord Server bin ich bereits (Daxi#9046)
LG,
Daxi
Hallo zusammen,
es freut mich sehr zu hören, dass es hier weiter gehen soll.
Meine Wunschfunktionen des DoorPi in der neuen Version (habe bisher keine Erfahrung mit den bestehenden Versionen / Forks):
* VoIP Calls (Audio, eventuell auch Video, automatischen Auflegen wenn nicht innerhalb X Sekunden angenommen)
* Video-Stream für Smart Home Displays / Home Assistant etc, das Protokoll sollte daher von Chromium nativ unterstützt werden, da dieser meist im Kiosk-Modus läuft bei DIY-Displays.
* Mehrparteien-Unterstützung
* Display (eventuell Nextion am einfachsten, da dort ein Editor existiert und nur Zustände und Seitenwechsel übertragen werden müssten. Idealerweise mit Rückkanal für Buttons am Touch-Display)
* MQTT Unterstützung (damit sind wohl alle möglichen Smart Home Systeme unterstützt wie Home Assistant / IO Broker / Node-RED)
* Modularität (es sollte nur das an Funktionen geladen werden, das benötigt wird - z.B. RFID / Fingerprint, wenn verfügbar)
* Türöffnung durch Tastendruck im VoIP Call, allerdings muss hier die Quelle das Telefon sein, nicht die Außeneinheit (z.B. durch einen Tonfrequenzerzeuger bzw. Ton-Mitschnitt am Telefon)
Um dem Thema Sicherheit ein wenig Rechnung zu tragen:
* Aufsplittung des DoorPIs in eine Innen-Einheit und einen Server möglich machen (würde allerdings bedeuten, dass der DoorPI einen Audiostream entgegennehmen, einen Video/Audio-Stream senden und das Event-Protokoll wie MQTT abgesichert werden sollte)
* Relais / weitere Kommunikation bis auf Video / Audio / MQTT erfolgt nicht aus der Außeneinheit, damit kann ein Relais (Türöffner) nicht durch Manipulation von außen geöffnet werden
* Manipulationserkennung z.B. beim Herausnehmen des Pis aus dem Gehäuse (z.B. Mikrotaster, Reed-Kontakt etc.)
* Sollte eine Manipulation erkannt werden, so wäre es ideal, wenn ein Event per MQTT gesendet werden kann um dann z.B. Sicherheitsschlüssel wie einen Pre-Shared-Key / Salt / API-Key oder was auch immer für die Verschlüsselung der MQTT-Payload unbrauchbar machen zu können und ggf. die Spannungsversorgung eines Switches zu unterbrechen, damit man mit dem Netzwerkkabel keine Verbindung mehr aufbauen kann
Mir ist bewusst, dass auch Doorbird oder Siedle oft auf Relais an der Klingeleinheit setzen, was ich gerade als einen der gravierendsten Design-Fehler halte.
Gerne würde ich das Team auch unterstützen, allerdings bin ich Python nicht wirklich mächtig und müsste mich dort erst einarbeiten.
Beim Testing der Versionen oder der Integration z.B. in Node-RED kann ich allerdings gerne unterstützen.
Gerne kann ich z.B. die Entwicklung eines Node-RED-Nodes übernehmen, damit die MQTT-Integration dann einfacher werden kann bzw. z.B. beim Klingelevent ein Standbild abholen und dann dem folgenden Node zur Verfügung stellen (z.B. Telegram, Pushcat etc).
