DoorPi als Server-Client System

    • Offizieller Beitrag

    hab gerade diese News gesehen und überlegt:

    • Pi Zero in der Ausenstation (Client)
    • Audio am Pi Zero
    • Cam am Pi Zero
    • Client nutzt Media Streamer für Video und Audio
    • DoorPi auf Pi3 mit LAN im Haus (Server)
    • Kommunikation zwischen zwischen Client und Server per I2C oder SPI oder ähnliches

    Der Pi3 stemmt die eigentliche Last und nutzt den Zero als Vorposten. Auf diese Art wäre es nicht schlimm, wenn der Zero geklaut wird, denn die wichtigsten Daten liegen auf dem Pi3. Außerdem liegt so kein offenes Netzwerkkabel in der Ausenstation.
    Türöffner wäre dann nicht direkt am Zero, sondern am Pi3. Damit kann man auch keine Kabel kurzschließen...


    Was sagt ihr dazu?

  • Mache ich mit dem Arduino. Ich habe noch keinen Zero in der Hand gehabt, , das wäre eine Alternative. Allerdings kann ich den Arduino besser kontrollieren - da läuft nicht im Hintergrund ein potenziell unsicheres Betriebssystem.



    LG


    pah

    • Offizieller Beitrag

    so könnte man Audio und Video auch noch nach vorn ziehen und vom eigentlichen Pi3 entkoppeln...


    Vielleicht sowas :
    http://hackaday.com/2015/12/10…e-cheap-with-an-rpi-zero/


    Aber mit sowas, damit ein mic dabei ist:
    http://m.ti.com/product/tpa2054d4a


    Eventuell auch Ethernet via USB am Zero und dedizierte RJ45 Buchse am Pi3. Der wurde dann auch mitbekommen, wenn das Kabel gezogen wird (Zero geklaut) und kann noch eine Nachricht senden...

  • An sowas bin ich gerade mit meinem Testsystem dran. Nur ein USB-Hub an der Aussentür, Soundkarte,Kamera und Arduino(über USB) am Hub. Quasi 4-Draht-System.
    Display für Arduino ist bestellt, Rest habe ich schon.

  • Zunächst mal muss ich sagen: Super Projekt und super Forum! Respekt!
    Dazu noch die Erlösung von meiner teilweise defekten Anlage des Vorbesitzers mit Baujahr '78 (Siemens Italien). Und ich konnte ohne Geld an die Klingel-Mafia einfach nur das Innenleben ersetzen und das Retro-Gehäuse erhalten. :)


    Da bei mir und vielleicht auch bei Anderen die Distanz zwischen Innen- und Außenstation mehr als 10m Kabellänge beträgt, wird es schwierig für Bild und Ton, egal ob I2C oder SPI, denke ich.


    Ich habe das bei mir so gelöst, dass ich einen "Internen" und einen "Externen" DoorPi installiert habe. Bin gerade in der produktiven Testphase. Der Innere ist praktisch nur ein SIP Phone mit Audio und einem Analog-LCD-TV und zwei Tasten für Gesprächsannahme und Türöffner.


    Dabei arbeite ich teilweise mit den Eventauslösern über das Web-Interface zwischen den beiden, um Anpassungen zu vermeiden, die ein Update behindern. Funktioniert alles prima, wenn man richtig liest & sich nicht vertippt. ;)
    Das Schöne für mich, ist der Umstand, dass ich nicht Python lernen muß und das Trace schnell die Fehler aufzeigt.


    Toll wäre daher für mich, wenn man den "Internen" per ini so konfigurieren könnte, dass er nicht automatisch abhebt bzw. über die ini konfiguriert mit dem anderen Daten, Stati etc. austauschen kann. Man will ja nicht zur Tür rennen, wenn man auf dem Telefon auch abheben kann. ;)


    Da ich den Zero nicht kenne, weiß ich nicht, ob das hier vielleicht eine Option ist: RPi innen und außen mit Zero oder Full-RPi als Konfig-Option.


    Liebe Grüße
    pmike

  • SPI lässt sich ohne besondere Maßnahmen auf 1m ausdehnen, mit einem Extender bis auf 100m. Problem ist eher die Bandbreite.


    Wal: Welche Kamera mit IR-Fähigkeiten am USB ? (Edit: Logitech, ich habs gesehen. Haut mich aber nicht vom Sockel, ich möchte IR )
    Wie Steuerung des I/O von DoorPi -> USB -> Arduino ?


    Die klare Schwäche meines Testsystems ist, dass ich drei Kabel zwischen Innen- und Außenstation benötige: Kamera (das Raspberry Pi Flachkabel habe ich schon durch HDMI ersetzt), USB und ein zweckentfremdetes 8-adriges STP-Netzwerkkabel.


    Umgekehrt ist ein Zero vermutlich nicht die beste Lösung, weil er auf Grund des sehr viel komplexeren Betriebssystems nicht echtzeitfähig sein wird. Damit kann ich kaum eine 1-Wire-Busabfrage alle 150 ms realisieren.


    (Noch'n Edit: Hmmm. Zero spielt mit Kamera, PiFace und USB. Verbindung zum Pi3 nicht über SPI, sondern über eine direkte Ethernet-Verbindung ...)


    (Noch'n Edit: http://elinux.org/RPi_USB_Webcams)


    LG


    pah

  • Wal: Welche Kamera mit IR-Fähigkeiten am USB ? (Edit: Logitech, ich habs gesehen. Haut mich aber nicht vom Sockel, ich möchte IR )


    Wie Steuerung des I/O von DoorPi -> USB -> Arduino

    IR-Fähigkeit war mir jetzt i.M. egal, da ich eine Lampe mit Bewegungsmelder an der Haustüre habe. :)
    Mit dem Arduino uno r3 kann ich über USB mit dem Raspberry seriell kommunizieren.
    Ich werde noch ein Protokoll mit Checksumme einfügen, um die Fehlfunktionen zu minimieren.
    In die dieser Art, habe ich mein Laufband auf Computersteuerung umgebaut(PC<-->Atmel Mega8).
    Wie ich die DoorPi-Software einbinde, weiß ich noch nicht, ich brauche aber auf jeden Fall einen Wrapper der die Befehle umsetzt.

  • Das mit dem Wrapper ist der Punkt...


    Der Nachteil dieser Lösung ist auch ganz klar, dass die schöne Parallelität der DoorPi-Sachen in eine serielle Leitung gepackt wird.


    (Wobei mir gerade noch etwas für den Wunschzettel einfällt - Non-Blocking out-Aktionen).


    LG


    pah

  • Das mit dem Wrapper ist der Punkt...


    Der Nachteil dieser Lösung ist auch ganz klar, dass die schöne Parallelität der DoorPi-Sachen in eine serielle Leitung gepackt wird

    Wobei die Netzwerkfähigkeit des DoorPi nicht's anderes ist, die Daten werden Stückweise über das Kabel gesendet, ich sehe somit kein Nachteil.

  • Moin.


    Ich sehe eigentlich nur einen Grund die CPU nach außen zu bauen, und das wäre die Kamera. Alle anderen Sensoren und Aktoren kann ich über Klingeldraht anschließen (sofern genug Adern vorhanden sind):


    • Klingel: GPIO
    • Display: UART
    • Sensoren: 1-Wire
    • Audio (Mic auf Line-In Pegel verstärkt)

    Eine Kamera werde ich über WLAN einbinden. Ob ich die in das Sprechstellengehäuse einbaue oder separat, muss ich noch sehen. Theoretisch kann man eine fertige Kamera kaufen, ausschlachten und die Antenne nach außen führen. Z.B. eine kleine Dom Kamera. Die Kuppel könnte man dann auf die Frontplatte schrauben.


    Wenn man die CPU nach außen baut stellt sich ja nicht nur die Frage nach Diebstahl / Vandalismus, sondern auch nach der Witterung. Kälte im Winter, je nach Lage sehr hohe Temperaturen im Sommer, Luftfeuchtigkeit etc. All das wird die Zuverlässigkeit einer CPU nicht wirklich erhöhen. Ich versuche genau das zu vermeiden.


    Die Abhängigkeit von einer zweite CPU erhöht auch die Wahrscheinlichkeit eines Ausfalls um 100%. Es erhöht auch die Komplexität des gesamten Systems, was ebenfalls die Wahrscheinlichkeit eines Ausfalls begünstigt. Es braucht ja nur eine Komponente in der Kette auszufallen. Dazu erschwert es die Fehlersuche, insbesondere wenn der Krempel mal eingebaut ist. Ich versuche solche Systeme immer möglichst simpel zu halten.


    Ich habe 8 Aderpaare. Damit komme ich locker aus. Ich kann sogar jedem Signal einen eigenen GND gönnen. Der Pi kommt definitiv nach innen. Ich habe ca. 6m Kabel bis zur Verteilung. Hier hängt auch mein Switch. Sofern UART und / oder 1 Wire nicht extrem in das Audiosignal übertragen sollten die 6m kein Problem sein.

  • Habe den Github von DoorPi mal durchstöbert und fand usb_plain als keyboard.
    Mit

    Code
    [keyboards]
    arduino = usb_plain
    
    
    [arduino_InputPins]
    0123456789 = call:**622

    konnte ich direkt vom Arduino einen Ruf absetzen.
    Arduino auf 9600Baud eingestellt.

    • Offizieller Beitrag

    Ich versuche solche Systeme immer möglichst simpel zu halten.

    beißt sich aus meiner Sicht aber meiner Deiner Aussage hier:

    Wenn sich das Öffnen sicher und sauber mit dem Arduino realisieren lässt, warum nicht? Das System könnte dann völlig unabhängig arbeiten,

    Ich bleibe bei meiner Meinung, wenn die Steuerung / Logik in einem System realisiert ist, dann ist die Anzahl der Clients relativ egal.


    @Wal Dafür war es ja auch gedacht. Aber am Arduiono kann ich eben keine Soundkarte oder eine Camera betreiben. Mir geht es hier in diesem Thema darum, eine Infrastruktur zu schaffen, die Logik und Konnektoren trennt. Logik auf dem Pi3 und alle Aktoren am Zero. Der Pi3 wird somit "stabiler" und kann die Monitoring-Funktion der Endpunkte übernehmen. Außerdem könnte so ein zweiter oder dritter Zero ins Spiel kommen, der sich am DoorPi auf dem Pi3 anmeldet (Stichwort Gartenzaun, Garagentor, ...). Jede dieser Außenstellen kann dann die vollen Funktionen des DoorPi nutzen. So könnte man z.B. durch einen iButton oder RFID-Tag am Gartenzaun die Garage öffnen, das Licht am Hauseingang einschalten und die Rufumleitung für die Klingel von Handy auf Festnetz umstellen.

  • Hi Thomas.


    Die Zitate stamme aus unterschiedlichen Zusammenhängen. :)


    Das reine Öffnen der Türe über den Arduino ist eine SEHR simple Lösung. Nur leider mit begrenztem Mehrwert. Vernetze ich den Arduino/Zero mit dem Pi, nur um die Türe zu öffnen, ist das eine deutliche Erhöhung der Komplexität:


    • Arduino/Zero
    • Software auf den Adruino/Zero
    • Spannungsversorgung Adruino/Zero
    • Verbindung zwischen Arduino/Zero und Pi
    • Kommunikation zwischen Arduino/Zero und Pi
    • Pi
    • Software auf dem Pi
    • Spannungsversorgung Pi
    • ...

    Wenn nur eine Komponente gestört ist, funktioniert das ganze System nicht mehr.


    Dem gegenüber steht die Lösung, alle Funktionen auf dem Pi zu vereinigen. Damit fallen schon mal diverse Fehlerquellen weg. Es mag Gründe geben, die das Trennen notwendig oder empfehlenswert machen. Wenn die nicht vorhanden sind, warum sollte ich das dann machen? 1-Wire unterstützt sehr lange Leitungen. Ich habe das RPI2 Interface gekauft und das funktioniert 1a. Das gibt es auch noch mit 4 Kanälen. So lange ich auf Kabel zurückgreifen kann und einfache Sensoren für Temperatur, Helligkeit, Reed Kontakte oder Schalter per Bus anschließen kann, hat der Pi alle Möglichkeiten an Board.


    Warum also für etwas "Dummes" wie einen Sensor oder Aktor, eine weitere CPU verbauen? Die ich auch noch mit passender Spannung versorgen muss? Die dann auch noch zur Erfüllung ihrer Aufgabe auf eine 2. CPU angewiesen ist?


    Um Daten wie Audio/Video zwischen dem Zero und Pi zu übertragen müsstest Du auch eine entsprechende Verbindung schaffen. UART wird da nicht reichen. I2C auch nicht und selbst wenn es mit SPI klappen sollte, bei den notwendigen Datenraten wird es bei langen Kabeln schnell problematisch. Von EMV spreche ich erst gar nicht. Wenn Du ein par MHz in einen Klingendraht jagst kann das ganz lustige Auswirkungen auf die Nachbarschaft haben.


    Was Du in Deinem Post an Wal beschreibst ist quasi dass gleiche, was diverse Smart Home Systeme machen. Warum also hier das Rad neu erfinden, wenn es FHEM gibt?


    Die grundsätzliche Idee eines Master/Slave Betriebs für z.B. den Einbau in eine Sprechstelle ist gar nicht mal falsch. Analoge Signale möglichst direkt zu digitalisieren wird die Qualität, Stabilität und Sicherheit sehr wahrscheinlich erhöhen. Aber es bleibt die Frage nach der Übertragung. Wen Du Pech hast, musst Du dafür auch noch eigene Protokolle schreiben. Spätestens dann wird es so komplex, das kann niemand mehr Unterstützen.


    Wenn ich geeignete Kabel (Cat5 oder besser) habe, warum nicht ein USB Hub in die Sprechstelle bauen und Audio/Video über USB übertragen? UARTm RFID oder 1-Wire über USB ist auch kein Problem. Diese Idee von PAH ist eigentlich super. Ich würde sie sofort umsetzen wenn ich ein passendes Kabel hätte. Ganz aufgegeben habe ich die Idee noch nicht. Ich hätte die Möglichkeit den Kabelweg (STP) auf knapp 1,5m zu reduzieren. Das könnte für USB reichen, benötigt allerdings eine Aufputzmontage des Pi im Flur, was den WAF etwas senken könnte :) Viel schlimmer wäre aber, dass ich den Pi ins WLAN hängen müsste, da ich an der Stelle kein LAN Kabel habe. :(

  • Wenn ich geeignete Kabel (Cat5 oder besser) habe, warum nicht ein USB Hub in die Sprechstelle bauen und Audio/Video über USB übertragen?

    Genau daran arbeite ich mit meinem Testsystem.
    Usb-Hub in der Sprechstelle :
    Arduino mit Nextion-Display als Namensschild und Pineingabe zum öffnen von der Haustür und Garage (funzt schon)
    Pineingabe mit NFC-Tag und Handy freischalten (noch nicht aufgebaut)
    Webcam (funzt schon)
    Soundstick (funzt schon)
    2 Klingeltaster am Arduino (funzt schon)


    Vorteil nur 4 Leitungen und RPI3 ist nicht an der Sprechstelle.

  • So könnte man z.B. durch einen iButton oder RFID-Tag am Gartenzaun die Garage öffnen, das Licht am Hauseingang einschalten und die Rufumleitung für die Klingel von Handy auf Festnetz umstellen.


    Was Du in Deinem Post an Wal beschreibst ist quasi dass gleiche, was diverse Smart Home Systeme machen. Warum also hier das Rad neu erfinden, wenn es FHEM gibt?


    Das sehe ich auch so. Ich mag die von dir ( motom001_new) beschriebenen Szenarien, aber ich halte es falsch zu viel über den DoorPi laufen zu lassen. FHEM kann das alles und noch viel mehr- ich halte es für sehr viel sinnvoller, dass der DoorPi für solche Szenarien bestimmte Events einfach an FHEM schickt, und dort wird entschieden, was passieren soll. Warum?


    Erstens, weil es das alles schon gibt und es somit unnötige Zeit ist, sowas in DoorPi nochmal zu implementieren.
    Zweitens, weil es DoorPi sehr viel komplexer macht als es jetzt ist, und es ist jetzt schon nicht gerade trivial.
    Und Drittens, weil die von dir beschriebenen Szenarien nur der Anfang sind- spätestens wenn man sowas am laufen hat kommt man auf die Idee, dass man z.B. die Lautstärke des Fernsehers senken könnte, wenn er läuft und es klingelt. Oder dass automatisch eine Rufeinleitung eingerichtet wird, wenn niemand mehr im Haus ist. Oder dass noch irgendwelche anderen Lichter ein- oder ausgeschaltet werden sollen, wenn es klingelt. Geht in FHEM alles, in DoorPi nur ein Teil davon. Und dann hat man einen Teil im einen System realisiert und den Rest im anderen- unschön und unübersichtlich.


    Meine Meinung ist, DoorPi sollte sich auf Funktionalitäten beschränken, die direkt mit dem Gegensprechen und dem Öffnen der Tür zu tun haben. Weitere intelligente Funktionalität können mit anderen Systeme sinnvoller realisiert werden.


    Was nicht heißen soll, dass ich generell gegen die Client-Server Lösung bin. Das kann man sicher machen und es macht für bestimmte Sachen auch Sinn, aber welche das sind sollte man gut überlegen.

  • Eigentlich wollte ich mich ja raus halten hier aus der Konversation aber jetzt muss ich doch auch mal meinen Senf dazu abgeben.


    Also ich finde Thomas Idee genial und würde mich freuen wenn so etwas implementiert wird.


    Begründung:


    Alle reden immer von FHEM als wäre es das non plus ultra doch frage ich mich wofür. Ich brauche keine Stummschaltung am Fernseher wenn es klingelt, warum auch. Aber selbst das liese sich ohne FHEM realisieren. Ich brauche auch nicht eine Anzeige damit ich weiß das die Waschmaschine fertig ist, für was auch oder sind die bei Euch so weit weg? Also bei mir an der Waschmaschine ist ein Timer integriert der mir sagt wann das Waschprogramm beendet ist und eine Uhr besitze ich auch.


    Ich habe in FHEM, für mich, noch keinen Mehrnutzen erkannt auser viel mehr Arbeit. Ich habe zwar einen Server laufen wo alles was Multimedia, Netzwerk und Videoüberwachung darauf läuft aber damit hat es sich auch bei mir.


    Ich finde es toll wenn ich gehe und DoorPi kann mich auf meinem Handy anrufen wenn es klingelt aber das kann DoorPi jetzt auch schon. Zum Thema Fensterkontakte die sind ebenfalls bei mir verbaut diese sind zwar Erschütterungsdetektoren gegen Einbruch aber mehr bräuchte ich nicht denn wer ein Fenster auf macht kann dieses auch wieder schließen und sollte das mal vergessen werden naja was solls.


    Jetzt aber nicht falsch verstehen ich bin jetzt kein Gegner solcher Automationen es ist ne nette Spielerei aber, für mich, auch nicht mehr.


    Deswegen finde ich eigentlich das genau das was Thomas vorgeschlagen hat einen enormen Mehrwert hat. Ich kann überall da wo ich eine direkte Automation oder Überwachung brauche für 4$ einen Einplatinenkomputer hinbauen und habe genau das was ich dann möchte oder benötige. Für 4$ bekomme ich keine FHEM. Ich kann in meinem Pool die Vorlauftemperatur und die Rücklauftemperatur sowie PH Wert, fast, in Echtzeit überwachen genauso auch an meinem Heizsystem (Wärmepumpe). Wenn dann mal etwas defekt ist ist das doch auch schnell lokalisiert und komplexer wird das System auch nicht viel mehr und da wäre nichts was ein Pi3 nicht schaffen würde. Ich habe es doch dann relativ Wartungsfreundlich.


    Gruß Nea