Beiträge von AndyGR42

  • Problem beim Mailversand

    Das entfernen der Standardwerte setzt use_ssl auch auf false. Würde es Dir etwas ausmachen die mailto.py noch mal in den ursprünglichen Zustand zu setzen und in der doorpi.cfg use_ssl=false zu testen? Das sollte den gleichen Effekt haben.

  • Problem beim Mailversand

    Vielleicht noch mal kurz was zum Thema SSL/TLS vs STARTTLS


    Historisch ist SMTP nicht als Client Verbindung gedacht, sondern als Server-Server Kommunikation. Ports erwarten entweder keine Verschlüsselung (25) oder SSL/TLS (465). Der Port 578 wurde speziell für Clients eingeführt, damit diese den Servern nicht in die Quere kommen. Auf 578 ist es üblich, eine unverschlüsselte Verbindung zu erwarten, die mit dem Kommando STARTTLS verschlüsselt werden kann. Diese Ports lassen dann oft kein SSL/TLS bei der ersten Verbindung zu. Der Server bietet STARTTLS in seine Antwort auf EHLO an. Der Client kann dann entscheiden, ob er unverschlüsselt weiter macht oder verschlüsselt. Bietet der Server das nicht an, so bricht der Client ab, wenn STARTTLS konfiguriert wurde.

  • Problem beim Mailversand

    OK....


    openssl s_client -host smtp.gmail.com -port 25 -starttls smtp -CApath /etc/ssl/certs/


    eliminiert den Fehler


    verify error:num=20:unable to get local issuer certificate


    Jetzt bleibt zu prüfen wie sich Python verhält.



    in der mailto.py stehen doch nur die default werte welche genommen werden, wenn die Option nicht angegeben ist, oder?


    Setz in der doorpi.ini doch mal bitte use_ssl = false



    Diese Option ist in deiner config nicht gesetzt und könnte, wenn es von Python genutzt wird, genau das Problem verursachen. Gmail erwartet auf dem port 587 TLS!

  • Problem beim Mailversand

    Korrektur:




    depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
    verify error:num=20:unable to get local issuer certificate
    verify return:0
    ---
    Certificate chain
    0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com
    i:/C=US/O=Google Inc/CN=Google Internet Authority G2
    1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
    i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
    2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
    i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority


    ist tatsächlich ein Fehler. Das zeigt auf das GeoTrust Global CA


    Das ist aber vorhanden und augenscheinlich gültig....

  • Problem beim Mailversand

    Also, openssl geht schon, nur mit etwas anderer Formatierung:


    openssl s_client -host smtp.gmail.com -port 25 -starttls smtp


    Das sieht grundsätzlich mal gut aus, bei mir.


  • Problem beim Mailversand

    Hm, das "erfolgreich" hatte ich überlesen. Vielleicht sind die Warnungen zu den Zertifikaten auch irreführend. Du hast wirklich nichts geändert? Oder irgendwas aktualisiert?


    Könnte auch an etwas anderem liegen. Port 587 erwartet STARTTLS, Port 465 SSL/TLS. SSL/TLS geht (laut google) auch auf Port 25. Versuche doch mal Port 25.


    Andererseits nutzt Python an der Stelle STARTTLS. Kann man da noch besser loggen? Am besten wäre der ganze SMTP Handshake in Klartext!



    routines:SSL23_GET_SERVER_HELLO:unknown protocol


    openssl kannst Du hier vermutlich nicht nehmen, das sendet nicht die benötigten Kommandos für SMTP

  • Problem beim Mailversand

    Fehlendes Root- / Zwischenzertifikat?


    Wenn Du TTL nutzt muss der Client dem Server Zertifikat vertrauen. Dazu muss der Kette vollständig vertraut werden (alle Zertifikate lokal installiert sein). Soweit ich weis ist das Root Zertifikat von GeoTrust und sollte somit auf allen System drauf sein. Damit signiert Google eine eigene CA. Dieses Zwischenzertifikat fehlt wahrscheinlich (auf meinem Jessie lite ist keins von Google zu finden). Diese eigene CA stellt dann wiederum das Serverzertifikat aus.

  • Antrieb Türöffner

    Wir haben ein relativ neues Haus mit einem halben Dutzend FI (allein schon wegen Wärmepumpen etc.). In Altbauten ist das aber oft nicht der Fall und auch nicht ganz einfach zu trennen.


    Gigabit bräuchte ich da nicht zwingen. Ich könnte aber problemlos eine 2. LAN Leitung für Power verwenden. Mit Cat 7 war ich beim Bau recht großzügig :) Nur die Haustüre habe ich vergessen :(


    Die meisten Stecker Netzteile haben einen eher schlechten Wirkungsgrad. Klar kann man die alle austauschen. Die Verluste auf der Leitung erhöhen auch nicht den Stromverbrauch. Es ist eine Reihenschaltung, bei der am Widerstand der Leitung eine gewisse Spannung abfällt. So lange das Netzteil diesen Spannungsabfall nicht durch Erhöhen der Speisespannung ausgleicht, erhöht sich auch die Leistung nicht. Irgendwann funktioniert einfach das Gerät nicht mehr, wenn zu wenig Spannung anliegt und / oder nicht ausreichend Strom fließen kann.


    Bei den Outdoor DSLAM ist wohl tatsächlich in den seltensten Fällen eine USV verbaut. Mir fiel gerade ein, dass ich das Thema unlängst mal in einer Diskussion von der anderen Seite (Feuerwehr und Polizei) gelesen hatte. Die haben das Problem auch. Eine kurze Zeit können die Outdoor DSLAM wohl über Batterie puffern, das ist aber eher als Schutz vor Über-/Unterspannung gedacht und nicht zur Überbrückung mehrerer Minuten. GSM Netze sind bei Stromausfall dann auch gerne mal überlastet... Und auch nicht unbegrenzt gepuffert.

  • Antrieb Türöffner

    Die FB wäre auch nur für die Kommunikation mit außen wichtig. Bei Stromausfall kann ich eh kein Licht einschalten :) In wie weit der nächste Standverteiler der Telekom bei einem Stromausfall auch betroffen wäre, keine Ahnung. Ich denke / hoffe aber mal, dass die Dinger auch per USV gepuffert sind. Immerhin geht es hier auch um Themen wie Notrufe etc. Es muss ja auch nicht immer ein Stromausfall aus dem Netz sein. Es gab durchaus Fälle wo Einbrecher über Außensteckdosen den FI ausgelöst haben, in der Hoffnung damit Sicherheitssysteme auszuhebeln.


    Ein Ex-Kollege hat auch mal eine FB per PoE betrieben, den muss ich noch mal nach den Details fragen. Insgesamt ist es auch durchaus ein Thema mit dem Stromverbrauch. Ein zentrales, effektives Netzteil ist durchaus sparsamer als ein halbes dutzend Stecker Netzteile.


    Der Passiv Adapter ist da sehr interessant. Auch für die FB. Das ist zwar kein klassisches PoE, dafür aber eine sehr simple Lösung.


    Mir reicht der Telegram Dienst für Nachrichten aus. Der ist end-to-end verschlüsselt und wirklich vertrauliche Informationen werde ich da nicht übertragen.

  • Welche Kamera außer PiCam für DoorPi?

    Hast Du versucht das USB Signal durch einen normalen Klingeldraht zu leiten? Das könnte die Ursache für das Problem sein. Ein normales Installationskabel hat ganz anderem elektrische Eigenschaften. PAH hat hier neulich Beispiele für Adapter gepostet. Vielleicht würde es damit funktionieren. Entsprechende USB Kabel sind auch anders aufgebaut. Das Betrifft die Schirmung, die Verseilung (welche Adern verlaufen wie lange parallel zu anderen), eventuell die Schirmung einzelner Adern oder Aderpaare, etc. Damit bekommt man auch sehr lange Kabel hin.


    Ich habe eine ähnliche Herausforderung und werden vermutlich eine WLAN Kamera nehmen. Da besteht das Problem hauptsächlich bei der Antenne. Die muss irgendwie herausgeführt werden, was entweder doof aussieht und/oder einen Angriffspunkt für Vandalismus darstellt. Da meine Sprechstelle auch etwas ungünstig hinsichtlich der Sonneneinstrahlung angebracht werden muss, werde ich die Kamera vermutlich gar nicht einbauen sondern anders platzieren (müssen).

  • Antrieb Türöffner

    Hallo Robert.


    Danke für die Info. Jetzt habe ich das mit AES verstanden. Das hätte mich auch gewundert, wenn man es auf der Funkstrecke hätte deaktivieren müssen. Im LAN ist das kein Thema, das VLAN kann ich entsprechend absichern.


    Ich sehe keinen Grund beim mir Sicherheit und Komfort zu verknüpfen. Einzig der Zustand An-/Abwesend wäre für beide Systeme interessant. Das könnte man zur Not noch über GPIO übermitteln. Der Komfort Teil wird sich auf Licht, ggf. ein par Steckdosen und vielleicht noch die Rollläden beschränken. Gerade für Licht und Steckdosen sehe ich keine Notwendigkeit für HM, hier würde es auch ein günstigeres System tun. Wobei die HM Schaltaktoren für die entsprechenden Schalterserien auch ihren Charm haben :) Weitere Gebäudeautomation entfällt bei uns. Wir haben keine klassische Heizung mehr, das System läuft nahezu ohne Eingriff von außen. Schnittstellen sind eh nicht vorhanden. Der Verbrauch wird schon detailliert aufgezeichnet, allerdings auch hier ohne Schnittstelle.


    Ich werde auf jeden Fall erst mal mit dem Teil "Sicherheit" starten, da es hier akuten Bedarf gibt. Ob ich das dann auf den Rest ausweite oder ein zweites System einrichte werde ich später entscheiden. Das hängt auch ein bisschen davon ab, in wie weit ich die Zugriffe, z.B. über WLAN, darauf absichern kann.


    Zum Thema USV. Ich habe eine zentrale USV für meinen Server (Windows, der hat aber ganz andere Aufgaben) und den Switch. Die FritzBox ist da leider nicht dran. Und hier ist auch schon das Problem. Was nutzt es den Pi (oder Cubietruck) per Lipo abzusichern, wenn die anderen Komponenten nicht entsprechend abgesichert sind? Der HMLAN z.B.? Das Teil hat leider kein PoE (was echt doof ist). Dann läuft die Zentrale weiter, kann aber nichts mehr steuern. Mein Pi kommt in den Keller zum Server und Switch. Damit ist er per USV für rund 30-40 Minuten abgesichert. Ich weis nur noch nicht so genau wie ich HMLAN versorgen soll, der muss wegen der Funkverbindung ja nach oben ins EG. LAN ist kein Thema, Power schon.

  • Welche Kamera außer PiCam für DoorPi?

    Also, auf 10m habe ich auch noch keine USB Kamera verlängert. 5-6m schon (am PC). Das hat mit diversen Modellen funktioniert. Allerdings waren das eher die besseren Modelle wie eine Logitech HD Pro oder die Microsoft Cinema HD. Und auch nicht die günstigsten Kabel.

  • Antrieb Türöffner

    Hallo,


    Kabel würde bei mir (noch) gehen. Den Aufwand würde ich aber nur bei einem in der Türe eingebauten Systeme treiben. HM arbeitet mir AES Verschlüsselung, was erst mal als sicher angesehen werden kann. Allerdings habe ich in verschiedenen Anleitungen gelesen, dass für KeyMatic an FHEM AES deaktiviert werden soll. Das wäre ein absolutes No-Go...


    Robert: Wie hast Du das Anlernen gemacht? Mit oder ohne AES?


    Ich würde FHEM (1) zu einer Art Sicherheitszentrale ausbauen. Mit entsprechenden Kontakten an Türen und Fenstern, Anwesend/Abwesend Schaltung, Alarm, etc. Ggf. noch die Rollläden. Aber das wäre mir schon wieder fast zu viel, müsste ich das System dafür öffnen um z.B. mit dem Tablet drauf zugreifen zu können. Da baue ich lieber später noch einen 2. der mir den ganzen, weniger wichtigen Firlefanz steuert.

  • Echo Problematik

    Es dürfte mehr Aufwand sein den Lautspreche zu dämmen als wie das Micro. Ich hatte mir überlegt, von hinten ein Stück Kunststoff Rohr an die Frontplatte zu Kleben und die Micro Kapsel dort mit einem passenden Material wie Kork oder Gummi einzusetzen. Das dichtet das Gehäuse nach hinten ab und sollte auch ordentlich dämmen.


    Den Lautsprecher würde ich, ähnlich wie bei deine Konstruktion, nicht an der Frontplatte befestigen, damit er entkoppelt ist. Andererseits dichtet ein Lautsprecher mit Kunststoff Membran die Sprechstelle nach hinten ab. Ggf. wäre hier eine Entkopplung durch eine Dichtung aus Neopren sinnvoll.

  • Antrieb Türöffner

    Moin.


    Nach dem ich soweit alle Komponenten einzeln getestet habe fehlt mir im Puzzle genau noch ein Teil. Das wäre der Antrieb für den Türöffner. Ich bin mittlerweile zum Schluss gekommen, dass der KeyMatic für die Nachrüstung auf normalen Schließzylindern die "sinnvollste" Variante ist. Eine Nachrüstung der Türe mit Motorschlössen ist oft nicht möglich und / oder exorbitant teuer. Außerdem stellt sich dann immer noch die Frage nach der Integration in das Projekt, da die Systeme meist proprietär sind.


    Ich habe mich soweit eingelesen und eine Nutzung von KeyMatic in FHEM ist möglich. Ich würde HMLan nutzen wollen, da der Pi in den Keller soll und ich den HMLan dank passender LAN Verkabelung quasi überall im Haus platzieren kann. Obwohl ich FHEM zu diesem Zeitpunkt noch nicht nutzen wollte, scheint dies aber die praktikabelste Lösung zu sein. Mein Plan wäre nun, einen Pi für alle "sicherheitsrelevanten" Systeme wie Türöffnung und Alarm (Kontakte) zu nutzen, und später vielleicht einen zweiten für die ganzen Spielereien. Den ersten Pi kann ich mit VLAN/Firewall im LAN sehr gut gegen Zugriff von außen absichern. Der wäre auch nicht per WLAN erreichbar. Ich kann die Kommunikation mit der Fritzbox auf SIP und RTP einschränken. Das Gleich gilt für den Zugriff auf die Webcam. Ein Zugriff von LAN/WLAN auf FHEM ist nicht vorgesehen. Hier würde ich gerne ein 2. Nextion Display innen anbringen welches alle relevanten Informationen (Fenster auf, etc.) und Funktionen (Scharfschalten, Türe verriegekn etc.) bereitstellt.


    Dazu hätte ich mal ein par grundsätzlich Fragen, die ich gerne diskutieren möchte:


    • Gibt es doch Alternativen zu KeyMatic?
    • FHEM und DoorPi auf einer Hardware?
    • Brauche ich außer Pi + FHEM + HMLan noch weitere HM Komponenten (außer natürlich KeyMatic und die Kontakte)

  • Echo Problematik

    Moin.


    Akustische Signale dämpft man am besten mit Masse. Leichte Materialien sind da eher ungeeignet.


    Ich habe die Sprechstelle noch nicht gebaut, werde aber bei der Planung genau das berücksichtigen und das Micro so weit wie möglich vom Lautspreche einbauen und gut wie möglich von innen dämpfen.


    Bei deiner Sprechstelle ist das Micro ja quasi frei im Gehäuse der Sprechstelle angebracht. Die Plexiglas verschließt das Gehäuse auch ohne Frontplatte. Das ist wie ein Lautsprechergehäuse. Außerdem sind Lautsprecher und Micro an der gleichen Platte befestigt. Darüber kann sich Schall prima übertragen.


    Ich würde das Micro mal testweise vor die Platte herausführen. Einfach um mal zu sehen was dann passiert.

  • DoorPi als Server-Client System

    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.

  • Nextion Display als interaktives Namensschild

    Also, es funktioniert erstaunlich gut. Bei bedecktem Himmel in SSW Lage und um die Mittagszeit ist das Display problemlos lesbar. Kommt die Sonne raus wird es grenzwertig, aber nach wie vor lesbar. Hier wäre ein kleines Überdach gegen Regen und hoch stehende Sonne durchaus zu empfehlen. Der Winkel muss natürlich stimmen. Sowohl der Blickwinkel (das Display baut an Kontrast ab, wen man seitlich rein schaut) als auch der Winkel zu Lichtquelle. Es ist nicht glossy, was die Sache deutlich vereinfacht.


    Interessanterweise ist weiß auf schwarz besser zu lesen wie schwarz auf weiß. Viel hängt aber auch vom Font ab. Ich nutze den Font Generator hier, das macht die Sache einfacher:


    http://support.iteadstudio.com…/topics/1000066083/page/1


    Fonts sind insgesamt etwas unschön, da teilweise sehr grob gerendert. Für zur Laufzeit unveränderliche Anzeigen wie Namen, Button, etc. würde ich die Schrift als Grafik einblenden. Das sieht erheblich besser aus.


    Mit dem angehängten File kann man Helligkeit, verschiedene Schriftgrößen sowie eine invertierte Ansicht einfach testet.