Neues DoorPi, was soll es können? Ihr Wünscht, wir schauen, was möglich/sinnvoll ist für alle.

    • Offizieller Beitrag

    Weitere Wünsche:


    - gerade für Anfänger ein Einzeiler/Paketinstallation

    - Nach Installation Grundkonfiguration aus dem Web z.B. Auswahl der Soundkarte und weiteren Komponenten

    - die aktuelle "Trace"-Möglichkeit evtl. ins Web integrieren (Debug aktivieren und dann ein Bereich, der das Log im Web anzeigt)

    • Offizieller Beitrag

    Hallo muellerjm,

    LCD für draußen? Text? Farbe? SPI, I2C, UART oder HDMI? Mit/ohne Touch?


    Da wäre das Stichwort Nextion vielleicht keine schlechte Wahl. Sollte bei den Projekten hier im Forum auch beschrieben sein.
    Den Nachteil habe ich darin gesehen, dass man die Bilder mit der SW von denen aufspielen muss. Es geht dann wohl nicht mehr im eingebauten Zustand, wenn das Display mit dem Raspberry verbunden ist..


    Oder weiß da jemand mehr?

    • Offizieller Beitrag

    Lustig - da schließt sich der Kreis für das #Nextion. Wäre ne Idee für ne #Action im DoorPi selbst oder Sgee für die #Weboberfläche als #Config-Möglichkeit


    My small modification to support my nextion display connected on doorpi

  • Wäre das aber nicht ein eigenständiges keyboard? (Man kann natürlich - theoretisch - das vorhandene Serielle aufbohren. Im Sinne des modularen Aufbaus würde ich jedoch zur Eigenständigkeit tendieren).

  • Da mich gestern ein User aus dem ioBroker-Forum angeschrieben hat und ich es schon vergessen hatte, da ich es wegen Fritzbox nicht brauche:


    WebRTC


    Das hatte bei mir mit zwei RPI3 funktioniert und würde mit DoorPI evtl. auch passen.


    edit: Für die Innenstellen

  • Hi,


    prima, dass es weiter geht. Hut ab, für euer Engangement.


    meine Wünsche als fortgeschrittener Laie (kann den RasPi mittlerweile in kurzer Zeit neu aufsetzen ;) )

    - Ich würde mir die Möglichkeit wünschen, GPIO-Eingänge miteinander logisch zu verknüpfen um in Abhängigkeit vom Ergebnis eine Aktion zu triggern. Durch Vorschaltung eines PIR-Bewegungsmelders und eines Helligkeitssensors könnte dann folgendes sehr schnell realisiert werden (Beispiel):

    Wenn Bewegung UND Dunkel dann Hintergrundbeleuchtung an.

    - Genauso denkbar wäre die Möglichkeit, die Ergebnisse anderer Programme (z. B. Sonnenauf- und Sonnenuntergang) zu nutzen. Da habe ich NULL-Ahnung, ob so etwas überhaupt schon jetzt funktioniert.


    Gruß

    Schorsch

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

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

    Das mit MQTT wären meine Worte, DoorPI kümmert sich nur um Audio/Video mit einer offenen MQTT-Schnittstelle.

    Node-Red (MQTTPlugin) kann man für die autarke Nutzung ohne SmartHome von DoorPI einbinden.


    Wenn du Ahnung von html,css u.s.w. hast, schau dir bitte den Link oben WebRTC an ob man das für die Innenstelle nutzen kann.

    Ich hatte das vor einem halben Jahr mal mit 2 RPIs am Laufen und es ging soweit.

  • Da die meisten Türstationen auf dem Markt entweder Cloudzwang haben, sich schwer integrieren lassen oder sehr teuer sind wird das Projekt DoorPi auch für mich immer interessanter.

    Folgende Features sollte die Türstation haben:

    - Klingelknopf, welcher beliebige Events auslöst.

    - Kamera + Micro + Lautsprecher famit sie als Gegensprechanlage verwendet werden kann.

    - Webapplikation für Komunikation. Dadurch kann jedes beliebige Gerät mit halbwegs modernen Browser als Innenstation verwendet werden.

    - Video- und Audiostream unabhängig abfragbar. Dadurch kann die Station auch als Überwachungskamera genutzt werden.

    - Unterstützung für Standards wie SIP, Onvif etc. Für einfachere Integration in SH.


    Da das Ganze auf einem Raspberry Pi mit MicorSD laufen soll, wäre es vllt. auch Sinnvoll einen "read only" Modus einzuführen um die MicroSD zu schonen.

    Sobald das System läuft sollten ja theoretisch keine Schreibzugriffe mehr notwendig sein. Max2Play (Multiroom Audio Lösung für RPi) bietet so etwas z.B. an.

  • Ich habe mir mal die meisten Wünsch durchgelesen und stelle fest. Das alles funktioniert doch jetzt auch schon.

    Ich habe in meiner Doorpi Konfig. einen Großteils von PAHs FHEM Anbindung soweit angepasst um damit mit iobroker zu kommunizieren. Wenn jemand klingelt schickt mir Doorpi ein Foto über Telegram. Auch mqtt ist einfach in die Config einzubinden .

    Auch die damals entwickelte Doorpi Patine läuft bei mit mit Nextion-Display, iButton-Reader und RPI-Kamera seit Jahren.


    Was ich mir von einem Doorpi3 wünschen würde:

    Läuft unter Python3

    Webinterface moderner und übersichtlicher gestalten
    Telegram integriert

    MQTT


    Gruß

    Tom


  • * 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
    * 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:"

    Die Punkte kann nur Begrüßen als "ganz wichtig" ich nur beipflichten,.. :thumbup:


    Zusätzlich würde ich noch vorschlagen:


    • XMPP Server statt unverschlüsselter E-Mail (Wer nutzt noch E-Mail Klienten am Smartphone, ist nicht Verschlüsselt).
    • Unterstützung gängiger Standards Externer Kameras.
    • Abspeichern von Bildern der Kamera bei Bewegung auf SD-Card oder z.B. Nextclud
    • Eigenes Webinterface oder APP
    • Mehrere Anrufbeantworter oder Umleitung
    • Integration von Keycards/RFID W-LAN APPs wie z.B. Trigger oder Bluetooth
    • Standalone
    • zweiter Türöffner z.B: Paketsafe
    • Bus/ Externer Betrieb so das die Hardware und Input/Output zu trennen ist.
    • Smarthome Integration z.B. Licht