Beiträge von Marcuss

    Sorry für die späte Antwort.


    Eine Empfehlung kann ich dir nicht wirklich aussprechen, da ich keine Erfahrungen habe. Grundsätzlich aber würde ich mir mal die PiNoir Kamera anschauen und dann entweder selber eine Beleuchtung mit starken IR Dioden herstellen oder auf einen fertigen Ring zurückgreifen. So was von der Bauart her
    https://www.amazon.de/gp/product/B0057DPXI4/



    Oder so was: http://www.avc-shop.de/NoIR-Ka…em-Fokus-und-Infrarot-LED
    und dann das dazu: http://www.avc-shop.de/epages/…/de_DE/?ObjectID=65348737



    Schau dir mal die Projekte anderer Mitglieder an. Dort gibt es entsprechende Aufbauten

    ast du zu deinem genannten ein paar Links? Transistorvorstufe, Eigenbau, kleine Relaiskarte?

    Also der Eigenbau ist die Transistorvorstufe und das findest du im ersten Beitrag dieses Threads. Der GPIO steuert einen Transistor an und der Transistor schaltet dann das Relais. Das ist eine saubere Lösung.


    Mit Relaiskarten meine ich sowas https://www.amazon.de/s/ref=nb…x=relaiskarte%2Caps%2C214. Dazu benötigt man aber noch einen Arduino, da der Raspi auch hier per GPIO direkt die Relais schalten würde. Da hat man also nichts gewonnen und könnte auch im Grunde direkt ein Relais auf den GPIO legen, was aber weiter oben schon als ungünstig dargestellt wurde.

    Ich bin da kein Experte, aber versuche mich mal. Manmöge mich korrigieren, aber Du könntest vermutlich kleine Relais steuern. Aber so ein GPIO ist nicht zum Schalten größerer Lasten geeignet. Dazu gehört auch schone eine Relais Spule, die gern mal >20mA ziehen kann.


    Siehe hier: http://www.mosaic-industries.c…utput-current-limitations


    Von daher die klare Empfehlung das mit einer Transistorvorstufe abzusichern. Es gibt neben dem PiFace und Eigenbauten auch noch kleine Relaiskarten für um die 5 Euro zu kaufen.

    Nein, ich verwende nur die normale CAM. Kein IR. Im Nachhinein wäre IR mit passendem IR Strahler besser gewesen, da die Eingangsbeleuchtung zu schwach ist

    Die meisten Settings haben nichts mit dem von dir verwendeten Video Stream zu tun. Die Settings beziehen sich auf auf den Video Support-Teil von Linphone (meines Wissens nach), den der doorPi als SIP Client verwendet. Der mjpg-streamer ist aber eine separate Software, die parallel zum DoorPi und damit zu Linphone läuft. Die Settings in der ELCOM App habe ich dir ja weiter oben verlinkt. Wenn du da rein schaust, werden deine Fragen zum Betriebsmodus usw. beantwortet. Auch die richtige Adresse zum Stream ist dort zu sehen. Sie endet mit ?action=stream". Das "9000/stream_simple.html" ist falsch, denn das ist die Webseite, die den Stream einbettet und nicht der stream selber.


    Nichtsdestotrotz anbei die doorPi setting.

    Ich denke du brauchst für die App auf jeden Fall einen Kamera-Stream. Ob das nun per mjpeg Streamer umgesetzt wird oder mit einer anderen Software ist egal. Take Snapshot legt ja nur Pi Intern ein Bild ab. Das ist ja völlig entkoppelt zur ELCOM APP und da gibt es demzufolge erstmal keine Video URL...
    ch kann mir die ELCOm App gerade nicht ansehen. Eventuell gibt es noch einen "Standbild/Einzelbild"-Betriebsmodus, der keinen Stream verlangt sondern nur den Pfad zu einem Bild. Das könntest du dann per Freigabe (UNC Pfad, Samba Server,...) oder per Webserver auf dem PI zur Verfügung stellen.

    Ne, die Unterhaltung existiert irgendwie gar nicht und ich habe auf die Mail hin reagiert. Eine spätere Unterhaltung konnte und kann ich aber sehen. Daher schreibe ich das mal als sporadischen Fehler ab und ich denke du kannst es ignorieren.
    Danke
    Marcus

    Hi Thomas,
    ich bin dem Wunsch gefolgt, eine doorpi.ini nur zu veröffentlichen, wenn ich sie auch supporte/pfelge. Das geht, wie angekündigt, aus beruflichen Gründen bei mir zurzeit nicht,. Zeit ist absolute Mangelware und alle privaten Bastelprojekte liegen auf Eis. Daher habe ich meine ini geteilt, ohne das weiter zu erläutern oder supporten. Eine private Konversation mit realrob gab es aus oben genannten Gründen auch nicht.


    Grüße
    Marcus

    Also. Du legst ein File namens "LoxoneNotify.py" in einem für den User zugänglichen Verzeichnis an und machst dieses ausführbar. Z.B. in einem Ordner namens "scripts" innerhalb des DoorPi Stammverzeichnisses. Diese Datei enthält folgende Zeilen:

    Python
    #!/usr/bin/env python
    # -*- coding: utf-8 -*-
    
    
    import socket
    s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    s.sendto("? #50 ?", ("192.168.2.100", 7000))


    Die IP ist die des entsprechenden Loxone Miniservers


    In der doorpi.ini legst du dann im Eventhandler einen Eintrag für dieses Mini-Script an




    Code
    [keyboards]
    prodsystem = piface
    
    
    [prodsystem_InputPins]
    0 = sleep:0.1
    
    
    [EVENT_OnKeyPressed_prodsystem.0]
    10=os_execute:/usr/local/etc/DoorPi/scripts/LoxoneNotify.py


    Damit ist ist der Pi Teil fertig.


    In der Loxone legst du dann einen einen Virtuellen UDP EIngang für den Port 7000an (siehe oben im script) und darunter einen Eingangsbefehl mit der Befehlserkennung \.\.#50\w


    Das wars


    doorpi.org/attachment/499/

    Sorry Nea und alle Anderen. Du kannst meinen Post jetzt gerne verschieben,löschen oder sonst was damit machen, aber ich will den
    Quatsch hier nicht unkommentiert lassen.


    Und nein, kein Pardon für den dürftigen Beitrag. Das ist mal wieder so eintypischer "pah Post". Viel Krach, gepaart mit derUnterstellung, dass alle anderen völlig verblödet oder gehingewaschen sind, nurweil sie die eigene engstirnige Sichtweise und voreingenommene Meinung nichtteilen. Fehlt eigentlich nur noch der obligatorische Bluescreen-Witz aus den 90ern.


    Wo genau ist den neben dem ganzen Rumgemotze jetzt der fachliche Bezug zu dem Fakt und dem Hauptproblem, dass der OEMHersteller keinen Treiber mehr zur Verfügung stellt?


    Jedenfalls wird mir langsam auch klar, warum wir unsere Abholvenen einweiteres Mal ausbilden müssen damit sie in der Lage sind ergebnisoffen, neutralund kreativ an Themen heranzugehenund alle Möglichkeiten auszuloten anstatt irgend einer Liebhabereinachzurennen und andere Optionen auszublenden.


    P.S: @Nea nur x64 Bit Treiber müssen signiert sein undmit einem "Windows 10 Treiber" wird vereinfacht gesagt sichergestellt,dass der Treiber auf allen Geräteplattformen läuft, alsoPC/Tablet/Handy/XBox/Hololens usw. Somit könnte man theoretisch oben genanntenChip auch an einem Handy betreiben. Stichwort Universal Windows Driver. Das ist eine Option, bedingt aber eine neue Architektur

    Verständnisfrage: Was hat den das Betriebssystem bzw. dessen ach so böser Hersteller damit zu tun, wenn der OEM seinen Treiber nicht für aktuelle BS Versionen anbieten? Windows 10 ist an dieser Stelle nur konsequent und lädt einen uralten Treiber nicht, der nicht den aktuellen Anforderungen entspricht bzw. nicht signiert wurde. Ich finde das Verhalten eher förderlich für Sicherheit und Stabilität und nicht "Beta"

    Stimme zu. Das geht nicht. denn sobald man ein True definiert (True=snapshot beifügen), versucht die Mailto Action das zuletzt geschossene Bild anzuhängen. Siehe Code
    https://github.com/motom001/Do…n/SingleActions/mailto.py

    Python
    #Funktions-Definition
    def fire_action_mail(smtp_to, smtp_subject, smtp_text, smtp_snapshot):
    
    
    #korrespondierende passage
    if smtp_snapshot:
                smtp_snapshot = doorpi.DoorPi().parse_string(smtp_snapshot)
                if not os.path.exists(smtp_snapshot):
    smtp_snapshot = get_last_snapshot()


    Du wirst das also entweder per Telegram machen müssen (ist recht simpel) oder dir ein eigenes Script schreiben, was eine Mail mit deinem wav File als Attachment verschickt.

    Zu Nuki gibt es noch eine ergänzende Aussage von einem Anwender zur Fernsteuerungs-Option des Herstellers. Die Frage war, ob die Fernöffnung ins Produkt integriert oder optional ist.


    Ja, die Hotline (bzw. wird's ein Webinterface sein) ist optional. Muss gesondert aktiviert und ein Passwort dafür festgelegt werden. Es wird dann am Nuki Server ein mit diesem Passwort verschlüsselter Schlüssel hinterlegt. Gibt man das Passwort und eine Kennung für's eigene Nuki ein, kann man damit den Schlüssel entschlüsseln und verwenden um mit dem Webinterface sein Nuki zu steuern. Ohne korrektes Passwort ist der Schlüssel nicht verwendbar - sprich die Hotline oder der Server können nicht jedes Nuki einfach so steuern

    Muss man halt glauben oder nicht. Ich bin nach wie skeptisch bez. einer Backdoor. Das betrifft aber im Grunde alle App gesteuerten Schlösser eines (Achtung Wortwitz) geschlossenen Systems


    Hier noch ein anderes Schloss auf Bluetooth und Z Wave Technik, was aber natürlich auch mit derselben Problematik daherkommt (App, Bedienung aus der Ferne möglich). Das wird aufgrund der Kopplung mit der App aber wohl nicht an den DoorPi anzubinden sein.
    http://smartlock.de

    Willkommen erst mal und ja, das ist der falsche Thread :) Vielleicht verschiebt uns ein Mod ja?


    Ich sehe keine grundsätzlichen Probleme die von dir beschriebene Konfiguration umzusetzen. Dein Motorschloss kann laut Doku mit einem externen Impuls arbeiten, den du über einen (Relais)-Ausgang des Raspis umsetzen kannst. Das Display haben hier einige Leute schon am Laufen (auch wenn es noch in der Experimentierphase ist). Zu RFID gibt es bez. der Sicherheit verschiedene Meinungen. Schau dir auch mal iButtons an. Die Kamera stellt kein Problem dar. Du musst halt nur überlegen wie die sie aufbaust. Also fertige Webcam ins Gehäuse, externe IP Kamara einbinden, Raspi Board Kamara, welches Objektiv, unter einem Dome mit Nachtsicht oder ohne usw. Hängt von deinen Gegebenheiten ab


    Sei dir nur bewusst, dass du da eine Herkules-Aufgabe vor der Brust hast. Da du ein Newbi auf den Gebieten bist, wirst du sicherlich an der einen oder anderen Hürde arg zu knabbern haben und zwischenzeitlich mal alles in die Ecke werfen wollen. Das soll dir aber keine Angst machen. Im Gegenteil. "Setting Expectations" würde ich es nennen. Du solltest eben von Anfang an wissen, dass es nicht in einer Woche durch ist und du dich da ein großes Stück selber durchwühlen muss.


    Du solltest also zunächst einmal folgendes angehen:

    • Grundlegendes Verständnis des Raspis, inkl. der IO-Hardware-Erweiterungen wie dem PiFace
    • Grundlegende Linux Kenntnis aufbauen (Filesystem, Rechte, Einfache Shell-Befehle usw)
    • Setz dich mit dem DoorPi auseinander. Mit dem WIki, mit der doorpi.ini, mit anderen Projekten (fertige Projekte Bereich im Forum) und lies dir die Threads zu deinen Themen hier am besten mehrfach durch
    • Erst dann setz dich mit dem Gehäuse auseinander

    Viel Erfolg!

    In /etc/timezone steht Europe/Berlin


    und ein
    pi@DoorPi:~ $ date


    ergibt


    Di 21. Jun 21:44:17 CEST 2016


    Ich denke also es ist alles so wie es sein sollte. Sobald ich aber eine mailto: Action auslöse (gerade noch mal frisch gemacht um den aktuellen Header zu bekommen) dann sieht der Date Eintrag im Header so aus.
    Date: Tue, 21 Jun 2016 12:44:37 -0700 (PDT)


    Hier stimmt also was nicht