Projekt: DoorPi mit Arduino verbinden

  • Zeil des Projektes ist es, dass man den RaspberryPi IM Haus einbauen kann, um so die Manipulation ein wenig zu erhöhen. Positiver Nebeneffekt ist, dass die Kabel reduziert werden.


    Hinter der Klingel sitzt dann nur ein Arduino, der mit dem RaspberryPi Bidirektional kommuniziert.


    Ich setze hier einen Arduino Pro Mini mit 8MhZ Taktung ein. Der hat den Vorteil, dass er an den GPIO auch mit 3.3V arbeitet und so direkt an den Raspberry angeschlossen werden kann.


    RaspberryPi und Arduino kummunizieren über eine Serielle Verbindung (RX / TX). Ich nehme hier bewusst keinen USB Port, damit das später über normalen Klingeldraht (so ist die Idee) verdrahten kann.


    Am Arduino hängt bei mir ein Nextion per SoftwareSerial, da der Pro Mini nur einen echten Seriellen Port hat.
    Die Restlichen Eingänge können dann für diverse andere Sachen wie, Klingel, PIR, RFID, iButton, LEDs oder diverse Sensoren benutzt werden. Es gehen immer nur die 2 Seriellen Adern zum Raspberry.


    Auf dem Breadboard klappt das in der Theorie bereits sehr gut. Die Frage ist nun, ob hier sowas gefragt wäre und man daraus möglicherweise ein Community Projekt macht oder es evtl. sogar nativ in DoorPi integriert. Aktuell habe ich nur das angepasste usb_plain keyboard im Einsatz.


    //TO-DO
    - Code Optimieren
    - Programmieren des Arduino über den Seriellen Port des Raspberrys
    - Programmieren vom Nextion TFT über Raspberry -> Arduino (hier müsste über ein Steuerbefehl der Port durchgeschliffen werden - soweit die Theorie)
    - Feature Erweiterungen
    - usw...

  • Längst im Detail beschrieben - irrelevant, ob man lieber den seriellen Port des Arduino nutzt, oder diverse Ein- und Ausgänge zum Schalten. USB (und in meinem Fall HDMI) wird dennoch nötig sein, weil man sonst das Audiosignal und das Kamerasignal ebenfalls über "Klingeldraht" leiten müsste. Würde ich gerne mal sehen...


    http://www.fhemwiki.de/w/index.php?title=DoorPi_und_FHEM


    LG


    pah

  • Das ist aber doch erstens beliebig variabel, und zweitens ist die Verlagerung z.B. der 1-Wire Bussuche auf den Raspberry Pi gar nicht sinnvoll.


    Darüber hinaus steckt in der obigen Beschreibung noch viel Unausgegorenes - etwa das "Durchschleifen" des seriellen Ports an das Nextion. Das beinhaltet nämlich einen lokalen asynchronen Puffer, weil keinerlei Kontrolle über die zeitlichen Abläufe des Nextion besteht. Aus meiner Sicht viel zu kompliziert und fehleranfällig.


    Sehr viel sinnvoller wäre, lokal (in der Türstation) alles auf USB umzusetzen (Audio, Video, Steuerung, Nextion) - das ist DER serielle Bus, der verschiedene Systeme getrennt adressieren kann, ohne solche Klimmzüge wie "Durchschleifen".


    Kabellänge ? Kein Problem, 10m USB-Kabel sind mit 2 kaskadierbaren Extendern hinzubekommen.
    Kabelqualität, etwa "Klingeldraht" ? Kein Problem, USB über STP-Kabel (sagen wir der Kategorie 5) zu verlängern, 150 Meter. Und wer wirklich nur 2 Adern Klingeldraht hat: DSL-Standmodem.


    LG


    pah

    • Offizieller Beitrag

    fhemwiki.de/w/index.php?title=DoorPi_und_FHEM

    8o WTF?
    Wann ist denn die Seite entstanden? Woooowww....


    sogar nativ in DoorPi integriert. Aktuell habe ich nur das angepasste usb_plain keyboard im Einsatz.

    Wie stellst Du Dir eine native Integration vor, sofern nicht die genaue Hardware vorgegeben ist?


    ohne solche Klimmzüge wie "Durchschleifen".

    @NightWatcher Auch wenn ich das ähnliche sehe wie @pahenning, empfehle ich Dir eins - lass Dich nicht entmutigen. Zu DoorPi wurde mir am Anfang auch abgeraten.

  • Ich schließe mich streicher's Frage mal an.


    NightWatcher, hast du schon ein Skript für die Kommunikation geschrieben, bzw. würdest du ein Codebeispiel hier posten?
    Wäre klasse.


    Man tut sich mit Vorlagen immer leichter und das Rad muss nicht immer wieder neu erfunden werden...

  • Hallo,


    also, ich habe auch einen arduino am doorpi laufen für verschiedenste dinge (klingeltaster, rfid-reader/codeschloss per wiegand, relais, led-steuerung). ich habe das per I2C gelöst. Funktioniert so weit recht gut....


    Cheers,
    Pula