Beiträge von pahenning

    Das Problem ist, dass man einen HDMI-Stecker erstens nicht durch eine enge Bohrung bekommt - und zweitens eine Steckverbindung hat, die wieder korrosionsanfällig ist. Da es am Markt echt nichts anderes gibt, lasse ich mir das Teil allerdings auch mal kommen und werde sehen, was sich vielleicht als Lötverbindung auf der Kameraseite etablieren lässt.


    LG


    pah

    Nu ja, Geschmackssache. Ich bevorzuge ein größeres Design mit integriertem Namensschild.


    LG


    pah


    Nachtrag: ich habe große Zweifel, dass diese kapazitiven Tasten mit Handschuhen bedienbar sind. Umgekehrt halte ich es für unschön, neben meine Klingel ein Schild "Bitte Handschuhe ausziehen" hängen zu müssen.

    Tja, wer lesen kann, ist klar im Vorteil. Oben habe ich geschrieben, dass zum Auslesen eines iButton ein elektrischer Kontakt nötig ist, RFID hingegen aus der Distanz ausgelesen werden können - das ist der wesentliche Unterschied, nicht die ID. Zum Thema Sicherheit von 1-Wire empfehle ich darüber hinaus nicht ein "Wikki", sondern eines meiner eigenen Bücher als Quelle...


    LG


    pah

    Icinga ist sehr mächtig - und damit ist die Wahrscheinlichkeit hoch, dass Fehlkonfigurationen genau den Alarm verhindern, den man möchte.


    Für ein SmartHome ist eine leicht einzurichtende Sache wie das Modul "Alarm" unter FHEM sehr viel besser geeignet.


    LG


    pah

    Schon richtig - es macht aber keinen Sinn, zwei Threads zum gleichen Thema zu haben - und Nea hat in den alten Thread einfach einen Hinweis auf diesen hier gepackt. Vielleicht hat ihn der Auszug aus meinem Buch gestört ? Egal, Anleitungen zum Watchdog gibt es wie Sand am Meer.


    Der "eingebaute Minicomputer" ist ein ein ziemlich trivialer Zähler, der bis auf Null herunter zählt, dann gewisse Tests macht und ggf. Aktionen bis zum reboot ausführt, wenn diese nicht erfolgreich sind. Dazu zählt eben auch, dass ein Test auf das Laufen eines bestimmten Programms ausgeführt werden kann, oder der letzte Dateizugriff festgestellt wird.


    Ich denke, dass man das o.a. Skript in etwas modifizierter Form auch mit dem eingebauten watchdog verwenden kann.


    LG


    pah

    Hm, der UVP liegt eher bei 300 €, Angebote gibt es für ca. 235 €.


    Macht für mich nichts aus - aber die Fläche gibt es nur in Edelstahl. Das lässt sich in ein kupferfarbenes Alublech optisch nur sehr schlecht integrieren - im Gegensatz zu Einzeltasten, die durch maßgefertigte Löcher zu sehen sind.


    Außerdem stört mich am Design das fette "GIRA".


    Nächster Punkt: Ich will verschiedene Sicherheitsstufen integrieren, bis hin zum Verschießen mit "Besitz" und "Kenntnis". Das bedeutet, dass man bei wirklich verriegeltem Haus außer dem iButton am Schlüsselbund auch noch eine PIN benötigt - alternativ dazu eine Fernbedienung im Auto, oder ein Handy mit Bluetooth in der Tasche. Mit anderen Worten: Die Tastatur muss wirklich klein und unauffällig sein - mal sehen, was man so hinbekommt, wie dick auch das Blech über den kapazitiven Tasten sein darf.


    Da helfen einem die Maxwell-Gleichungen wirklich - denn eine leitende Schicht verhindert nicht notwendigerweise das Funktionieren der kapazitiven Tasten.


    LG


    pah

    Zitat von Fraeggle

    Das mit dem Auslesen der RFid TAGS sehe ich auch nicht gerade als kritisch an. Bei der geringen Reichweite..... So gesehen dürfte man gar nichts in dieser Art nehme

    Unsinn, das ist eines der wichtigsten Probleme bei RFID-basierten Zugangssystemen. Die Transponder kann man nämlich im Vorbeigehen auslesen - mit einigem Aufwand sogar ganz unauffällig aus Entfernungen von mehreren Metern. Bei iButtons muss hingegen ein echter elektrischer Kontakt hergestellt werden, das ist wesentlich schwieriger.


    Ich bin auch der Meinung, wenn jemand rein will findet er sicherlich einen Weg

    Das ist ein so naives Pauschalstatement gegen jede Art der Absicherung , dass man es eigentlich gar nicht diskutieren sollte. Vlt. einfach mal nachlesen, was die Kriminalstatistik über Einbrüche und Einbruchsprävention enthält.



    Zitat von Joker

    Man sieht die Schrauben nicht, OK, aber sie sind ja trotzdem da. Ein Einbrecher würde also sinnvollerweise die Schrauben ausfindig machen und sie herausschrauben, das geht sicher schneller und unauffälliger als die gewaltsame Entfernung der Frontplatte


    "Verdeckt" heißt, dass ein Schraubbolzen fest auf der Rückseite einer 4 mm dicken Aluminiumplatte angebracht ist und von innen festgezogen wird. Das kann man eben nicht von außen herausschrauben.



    Zitat von Joker

    Ja mein Plan wäre, eine klare Plexiglasplatte zu nehmen, und diese von hinten schwarz anzusprühen

    Hm. Verkratzt leicht, eine maßgefertigte Glasplatte für ein paar Euro macht da mehr her.


    LG


    pah

    Noch eine Inkonsistenz, die mir ebenfalls nach einem echten Fehler aussieht.


    Bei der Statusabfrage wird als


    "additional_infos": "{'last_record_filename': '/usr/local/etc/DoorPi/records/2016-04-22_12-14-59.wav'}",



    angegeben. Der tatsächliche Filename lautet aber


    /usr/local/etc/DoorPi/records/2016-04-22_12-14-48.wav.
    Der Unterschied beträgt nicht immer 11 Sekunden - vielmehr stimmt der Filename mit dem Startzeit des Calls überein.


    LG


    pah

    Stimmt nicht. Denn rund um den String bei den "additional_infos tauchen" noch doppelte Anführungszeichen auf. DoorPi gibt aus


    "additional_infos": "{'call_state': 13, 'state': 'Call terminated', 'remote_uri': 'sip:722622@192.168.0.254'}",


    JSON-konform wäre


    "additional_infos": {'call_state': 13, 'state': 'Call terminated', 'remote_uri': 'sip:722622@192.168.0.254'},


    ohne die zusätzlichen Anführungszeichen. Das ist also ein echter Fehler.



    Bei der "start_time" ist das zwar eine Ermessensfrage. An anderer Stelle habt ihr das aber eben mit Anführungszeichen gelöst, z.B. als


    "bouncetime": "2000",


    Das ist also nicht ganz konsistent.


    LG


    pah

    Liebe DoorPi-Entwickler,


    während der fortschreitenden Integration von DoorPi mit FHEM bin ich auf folgende Inkonsistenzen bei der Statusabfrage gestoßen:


    1. Im Feld "additional_infos" der einzelnen Einträge von "history_event" wurden einzelne Apostrophe statt doppelter Anführungszeichen verwendet. Als Folge davon wird der nachfolgende Inhalt (fett in der folgenden Zeile) nicht als strukturiertes JSON erkannt, sondern nur als String. Sollte sich leicht beheben lassen.


    "additional_infos": "{'call_state': 13, 'state': 'Call terminated', 'remote_uri': 'sip:722622@192.168.0.254'}",


    2. Im Feld "start_time" der einzelnen Einträge von "history_event" wurden die doppelten Anführungszeichen vergessen, dort steht jetzt z.B.


    "start_time": 1461076523.81


    statt - wie es richtig wäre


    "start_time": "1461076523.81"


    Beides lässt sich natürlich bei einer Statusabfrage via FHEM leicht beheben - ist aber m.E. als Bug auf der DoorPi-Seite zu behandeln.


    Möglicherweise sind in dem JSON noch weitere Fehler. Ist aber m.E. für einen "Status" mit mehr als 4000 Zeilen sowieso etwas lang, z.B. tauchen darin auch die ganzen Hilfetexte auf. Könnte man die nicht herauslassen ?


    LG


    pah