Beispiel einer umfänglichen doorpi.ini

    Hi zusammen,


    ich habe hier aufgrund der oft aufkommenden Fragen mal eine doorpi.ini zusammengestellt, in der die meisten Punkte auskonfiguriert.


    Könnten die Experten mal drüberschauen ob Fehler drin sind? Testen kann ich das im Moment nämlich nicht.



    Danke

    Bash
    --vorerst entfernt bis eine einheitliche Meinung besteht----
    • Offizieller Beitrag
    Zitat von MarcusS

    aufgrund der oft aufkommenden Fragen mal eine doorpi.ini zusammengestellt, in der die meisten Punkte auskonfiguriert.

    Das halte ich für eine schlechte Idee - lasse mich aber gern vom Gegenteil überzeugen. Der letzte Versuch eine solche Beispiel-INI mitzugeben führte zu einem rasanten Anstieg von Support-Anfragen mit wenig Hintergrundwissen der Fragesteller bezüglich, was überhaupt in der INI alles enthalten ist.


    Ich denke, da man ein solches System nicht aller 3 Tage aufbaut, kann man sich auch die Zeit nehmen seine eigene INI zu bauen. Aber das ist vermutlich nur meine Meinung...


    In Deinem Fall (PS: Config sieht nicht schlecht aus) wird es Anfragen geben:
    - ich erreiche die Weboberfläche nicht (Port geändert)
    - meine Records sind nicht da (Verzeichnis im Standard nicht enthalten)
    - ich kann keine SIP-Verbindung zu DoorPi aufbauen (Port geändert)
    - ...


    Das kann und will ich auf Dauer nicht leisten. Wenn jemand anderes diese Support-Fälle übernimmt kann ich diese Beispiel-INI auch gern auf github übernehmen und im default installieren.
    Aber jedem sollte dann bewusst sein, dass es GANZ GANZ viele Anfragen auf unterstem Anfänger-Niveau geben wird, die sich immer wieder und wieder und wieder und wieder wiederholen werden.


    Außerdem sollten dann alle Dokus angepasst werden (z.B. Wo und wofür gibt es die Weboberfläche? )

    Ich verstehe deine Einwände. Allerdings gibt es hier ja auch heute schon viele Threads mit solchen Anfängerfragen und wir erklären auch hier immer wieder Grundlegendes. Ich weiß also nicht ob sich das mit einem Sample zum Vorteil oder Nachteil drehen wird. Ggf. packen wir in die ini noch mehr Kommentare rein um z.B. auf Ports, fehlende Verzeichnisse usw. hinzuweisen.


    Wie wäre es alternativ mit einem anderen Ansatz. In der Wiki Doku pflegen wir mehr und umfänglichere Infos ein. Es fehlen immer noch Abschnitte (z. B. AdminNumbers oder die Events) Auch mit mehr Samples pro Schlüssel aber eben keine vollständige und zusammenhängende ini. Somit muss man sich zwangläufig damit beschäftigen. Ich bin gerne aktiv dabei und fülle das WIKI soweit ich es kann.


    Bis dahin habe ich die ini erst mal entfernt

    • Offizieller Beitrag
    Zitat von MarcusS

    Bis dahin habe ich die ini erst mal entfernt

    Vorab - das wollte ich nicht erreichen - zumindest nicht bewusst.


    Eine ähnliche Diskussion haben / hatten wir aktuell hier:
    Wiki DE/EN nicht gleich


    Ich sehe das immer noch so wie schon hier beschrieben:

    Eventuell wäre es gut, wenn die Grobstruktur nicht von mir als Entwickler kommt, sondern von Benutzern / Anwendern.

    Hallo ihr Zwei,
    ich sehe das so dass ihr Beiden berechtigte Gründe habt. Wenn Marcus sich hier bereit erklärt die doorpi.ini zu pflegen und auch mit hilft hier Support zu leisten denke ich dass es zu schaffen ist.


    Aber wie gesagt ich verstehe hier beide sehr gut.

    Ein neues Wiki macht aus meiner Sicht keinen Sinn. Deine Doku auf Github ist doch vom Format her ausreichend. Ich würde sie nur gerne vollständiger sehen und ein paar mehr Beispiele haben. Daran kann ich gerne mitarbeiten.


    Support leiste ich ja eh schon wo ich kann, indem ich immer wieder in Threads auf Fragen antworte. Ich kann aber noch nicht einschätzen wir es bei mir ab Juli/August aussieht. Neue berufliche Aufgaben könnten mich ziemlich binden, so dass auch auch Abends und am Wochenende weniger Zeit haben werde. Kann ich noch nicht abschätzen, aber es wird schon ein wirklich großes Thema sein. Deswegen will ich nichts neues anleiern, was ich in ein paar Monaten nicht mehr in vollem Umfang betreuen kann

    • Offizieller Beitrag
    Zitat von realrob

    seine doorpi.ini auf priv. Kanal

    Schade...

    Zitat von realrob

    die Konversation tw. sehr lehrreich und unterhaltsam ist

    @MarcusS @realrob
    Schön für Euch und schade für alle anderen...




    Ich habe nichts gegen eine veröffentlichte doorpi.ini - aber die muss auch gepflegt werden. Wenn das allerdings jetzt in eine Richtung der selektiven Verteilung geht, dann macht das doch eher öffentlich. Es geht hier um ein OpenSource Projekt und nicht um "Wer kennt wen gut, damit ..."


    Das Thema #Wiki gehe ich gerade Stück für Stück an und migriere es hier in #Lexikon.

    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

    Hi, also kann ich bestätigen, dass Marcus und ich keine Konversation hinter dem Forum führten. Er war nur so freundlich und hat mir seine ini geschickt, die für mich sehr brauchbar war, da mein setup durchwegs seinem ähnelt. Den Ansatz, keine unsupporteten Halblinge ins Forum zu stellen, kann ich sehr gut nachvollziehen und ist sinnvoll. Daher wollte ich das Forum nicht beanspruchen und habe ihn per pn angeschrieben. Er war trotz zeitknappheit so nett und hat es mir geschickt. Unter dieser Prämisse "lesen und nicht fragen" würde es hier dennoch gut reinpassen, da man von einem durchdachtem Stück ausgehen kann.
    @Thomas:Danke wg. Nextion Display eigener Thread. Habe prompt eine gute Antwort erhalten, die meine Entscheidung erleichtert hat.
    lg an alle
    Robert

    Das Problem ist ja, dass es DIE doorpi.ini einfach nicht geben wird. Dazu sind die Möglichkeiten und Anforderungen einfach zu vielfältig. Mein Vorschlag wäre daher eine Ideensammlung bzw. Mustersammlung mit den entsprechend in der doorpi.ini benötigten Codezeilen. Also z.B. nach dem Muster, was muss ich in die doorpi.ini wo eintragen, wenn ich mittels FRITZ!Fon einen Türöffner realisieren will. Oder wie kann ich es erwirken, dass mich der DoorPi per Push-Nachricht über ein Klingeln an der Haustür informiert.


    Ich persönlich mag es, aus der doorpi.ini heraus verschiedene Shellscripte aufzurufen, die dann entsprechende Programmzeilen enthalten. Für mich hat das den großen Vorteil, dass ich Änderungen on the fly vornehmen kann, ohne den DoorPi neu starten zu müssen. Zudem hält es die doorpi.ini übersichtlich und blockiert den DoorPi nicht so lange für andere Aufgaben. Daher stellt sich mir die Frage, ob es nicht evtl. auch sinnvoll ist, derartige Shellscripte zu sammeln?


    Gruß,


    Thorsten

    es wird 2 unterschiedliche usertypen geben.
    die Profis die den Code direkt durchschauen und eine höchst individuelle Anlage wollen und auhc in der Lage sind das zu realisieren
    und
    die Anfänger die sich durchaus mit Standard begnügen. die einfach ihre schit Klingel durch was mordernes mit Bild ersetzen wollen, mag sein das langfristig dann neue Wünsche dann entstehen


    Ich selbst bin über eine ESA2000 und ein paar FS20 Teile zu fhem gelangt und habe mich nach 35 Jahren Windows zum ersten Mal mit linux beschäftigen müssen, Nach und nach wuchs die Installation.
    Wir haben nur eine Klingel an der Haustür und seitdem die neue Hautürd drin ist kann ich nciht mehr rausschauen wer da steht. Dann bei fhem von doorpi gelesen.


    Problem nun, dass die Anleitung die hier angeboten wird nicht funktionierte, der patch ging nicht . Dann angefangen zu lesen... Der Raspi3 war neu mit Jessy_Pixel, alles Standard. Ein user hat dann einen anderen patch bereitgestellt und es lief dann, nun hänge ich an der Klingel , lesen lesen lesen


    Sehr viele werden eine Fritzbox haben, mit entsprechenden Telefongeräten.
    Schritt 1 damit Anfänger nicht überfordert werden, wäre eine Standardinstallation Rasp mit piface ( solle einem Wert sein ) ein Klingelknopf und eine Kamera.
    Besucher klingel Event wird ausgelöst Fritzhandy wird angerufen. damit sind doch sicher 80% der user erst mal zufrieden.
    Ich protokolliere immer alles damit ich auch noch Monate danach mich zurechtfinde, das kann man parallel zur Installation machen weährend der Raspi rödelt, das kostet eigentlich kaum Zeit und ein Bild sagt mehr als 1000 Worte


    auf dieser Standarinstallation aufbauend käme dann der nächste Schritt
    Türöffnung oder auch Push Nachricht.


    ich mache das mit den Protokollen immer so
    https://forum.fhem.de/index.ph….msg632484.html#msg632484

    Hallo,


    würde dieses Thema noch einmal aufgreifen. Ich halte es für sehr Sinnvoll eine umfangreiche doorpi.ini bereit zu stellen - am besten noch mit Erläuterung dahinter.
    Denn das macht es unterm Strich einfacher so ein System nach zu bauen und zu konfigurieren.
    Ich habe bis jetzt sehr viel Zeit damit verbracht das ganze Forum zu durchstöbern und nach etlichen Seiten kommt man zu keiner Lösung.


    Natürlich wird es die Freaks und die leihen geben aber das ist doch egal oder? jeder muss sich die doorpi.ini so zusammen bauen wie er sie braucht.
    Ich habe natürlich auch mit einer Beispiel ini angefangen. Wenn man sich dem Projekt widmet dann hat man davon doch erst einmal null Ahnung und wenn man dann mit einem Beispiel anfangen kann wäre doch super.


    Vielen Dank
    Dennis