Wunschzettel

  • 1. Konfigurationsparameter für die log-Datei. In /usr/local/etc/Doorpi/log ist die nicht wirklich gut aufgehoben, und ein Umbiegen des Verzeichniseintrags ist nicht jedermanns Sache.


    2. Derzeit werden die Zeitstempel für snapshot-Dateien unabhängig von der Call-Zeit gesetzt. Das bedeutet, dass der Name de snapshot-Datei nicht unmittelbar aus der Zeit des Calls abzulesen ist, weil er z.B. 1 Sekunde später liegt. Das habe ich zwar im FHEM-Modul umgangen, indem history_snapshot abgesucht wird und die eine-sekunde-spätere Datei eingetragen wird. Ist aber etwas hässlich. Alternativ könnte man alle snapshot-Dateien, die während eines calls erstellt worden sind, in additional_infos eintragen.


    LG


    pah

  • Konfigurationsparameter für die log-Datei. In /usr/local/etc/Doorpi/log ist die nicht wirklich gut aufgehoben,

    Gebe ich Dir vollkommen Recht - ist in DoorPi 3 bereits berücksichtigt und umgesetzt - für DoorPi 2.x würde ich das aussitzen, oder besteht so großer Bedarf daran?


    alle snapshot-Dateien, die während eines calls erstellt worden sind, in additional_infos eintragen

    Die beiden Module Keyboard Sipphone und Action take_snapshot haben keine direkte Verbindung zueinander. Deshalb ist es recht schwer, diese gemeinsam abzuspeichern - sei es im Dateisystem oder in einer Variable. Der Zeitpunkt des Snapshots ist ja nicht direkt an den Call gebunden. Theoretisch könnte ja jemand aller 5 Sekunden einen Snapshot erstellen lassen und zufällig ist dann auch ein Call dabei.


    Was ist das Ziel hinter dieser Anforderung? Soll später in einer Oberfläche eine History angezeigt werden, die neben den Records der Anrufe auch die Snapshots zu Beginn und am Ende beinhaltet?

  • Ich höre immer "soll später"...


    "Wird schon" ist richtiger, siehe angehängten Screenshot des FHEM-Moduls. Die angezeigten Namen für door, light (=Beleuchtung der Szene) und dashlight (= Beleuchtung von Namensschild etc) sind übrigens beliebig konfigurierbar. Durch Anklicken der Mini-Bilder wird der Snapshot angezeigt, durch Anklicken des Recording-Names rechts dasselbe abgespielt. Werde ich vielleicht noch durch Icons ersetzen.


    LG


    pah



    pah

  • Ich höre immer "soll später"...

    Naja - hier muß man schon berücksichtigen, daß hier keine Armee von Programmierern am Werk ist sondern Thomas alleine, der nebenbei sicher auch noch Job und Familie hat, finde ich...
    Immerhin ist das hier ein "just-for-fun" Projekt. Im Gegensatz zu fhem, das es inzwischen geschafft hat, daß neben Rudolf eine Vielzahl von Leuten entwickelt, ist Thomas noch alleine - da dauern halt viele Dinge doch länger verständlicherweise....

  • Ich glaube, das war von Ihm nicht als Kritik gemeint, sondern als Hinweis für mich, dass er schon lange soweit ist.
    Ich hab ja kein FHEM und dachte immer er ist noch "weit" von der Realisierung entfernt...


    Nun bin ich ein wenig baff und staune - freue mich aber mindestens genauso viel, dass sich jemand dem Thema professionell annimmt.

  • Nein, das war wirklich nicht als Kritik gemeint... nur als Hinweis darauf, dass es das in der Tat jetzt schon gibt.


    "Flotter Hacker", hm. Eigentlich habe ich bei meinen diversen Aktivitäten genug zu tun, aber hier drängt es wirklich. Meine Siedle-Türstation ist 27 Jahre alt, und meine Auerswald-Telefonanlage 18 Jahre. Die gibt es nur noch, weil sie mit der Siedle-Türstation sprechen kann.


    Also pures Eigeninteresse, und etwas Luft zwischen zwei Forschungsprojekten.


    LG


    pah


    P.S.: Da ich davon ausgehe, dass mein gerade fertiges Buch innerhalb kürzester Zeit eine zweite Auflage bekommt, bastele ich schon ein paar neue Hacks zusammen - und einer davon wird sich mit DoorPi befassen. Also weiteres Eigeninteresse.

  • Noch etwas für den Wunschzettel:


    Die derzeitigen Aktionen z.B. zur Ansteuerung einer Beleuchtung sind blockierend.
    Der Befehl


    10 = out:lighton,1,0,30


    sorgt also dafür, dass die Kiste nicht etwa einen Hintergrundtimer startet, der das Licht nach 30 Sekunden wieder ausschaltet. Sondern 30 Sekunden das Licht anmacht, und dann erst wieder weiter macht.


    LG


    pah

  • Okay - sind aber nur Feststellungen.


    Wie lautet der Wunsch dazu?
    Was soll passieren?
    Wie soll das dann z.B. in der Config hinterlegt werden?
    Bezieht sich dieser Wunsch nur auf die Out-Aktion auf auf jede Aktion?
    Wäre es nicht besser eine neue Aktion hinzuzufügen, die Events abschießen kann? Beispiel:


    Code
    1. [EVENT_OnKeyPressed]
    2. 10 = FireEvent:LichtMitTimer
    3. 20 = ...
    4. [EVENT_LichtMitTimer]
    5. 10 = out:lighton,1
    6. 20 = sleep :30
    7. 30 = out:lighton,0


    Das Abfeuern eines Events ist, sofern ich mich gerade richtig erinnere, nicht blockierend.

  • Wie arbeitet denn die sleep Aktion? Ist während die Sleep Zeit läuft das Event System blockiert oder können währenddessen weitere Events verarbeitet werden?


    Der Sinn von deinem Vorschlag ist mir nicht klar (hängt von der Antwort auf die Frage ab), was wäre der Unterschied zu:

    Code
    1. [EVENT_OnKeyPressed]
    2. 10 = out:lighton,1
    3. 20 = sleep :30
    4. 30 = out:lighton,0

    ?

  • mehrere Events werden parallel abgearbeitet, Aktionen innerhalb eines Events aber seriell...


    In meinen (noch nicht umgesetzten) Beispiel würde das Event LichtMitTimer gestartet, aber nicht auf dessen Ende gewartet werden.


    Technisch gesehen, wird jedes Event von Anfang bis Ende durch ein einzigen Thread verarbeitet. Das feuern eines zweiten Events jedoch ein anderer Thread...


    Anders ausgedrückt - die Aktion 20 vom Event OnKeyPressed würde eher ausgeführt werden, bevor das Licht wieder aus geht.


    Zumindest theoretisch - praktisch ist noch gar nichts davon umgesetzt, sondern ich würde gern wissen, ob das denn Wunsch befriedigt / das eigentliche Problem löst.

  • Technisch gesehen, wird jedes Event von Anfang bis Ende durch ein einzigen Thread verarbeitet. Das feuern eines zweiten Events jedoch ein anderer Thread...

    Ok, verstanden soweit. Das würde nach meinem Verständnis den Wunsch von @pahenning (den ich für sehr gut und wichtig halte) erfüllen.


    Generell finde ich den Vorschlag von dir mit der Aktion für das Feuern eines Events sehr gut, aus folgenden Gründen:


    1. die von dir beschriebene Funktionsweise der Event-Abarbeitung: "Ein Thread pro Event, innerhalb eines Events alles seriell" ist einfach, und daher leicht zu verstehen. Wenn man jetzt etwas einführen würde, was dann durch eine bestimmte Syntax oder eine bestimmte Aktion innerhalb eines Events zu Parallelität führt (ohne dass man das sieht), wird es bei komplexen Aktionsfolgen schnell sehr unübersichtlich.


    2. Wenn man selbst Events feuern kann, kann man sich viel Schreibarbeit ersparen und auch die Wartbarkeit (des ini-Files) erhöhen. Beispiel: Ich habe in meinem System mehrere Events, die den Türsummer auslösen sollen (DTMF-#, virtuelle Taste, mehrere unterschiedliche RFID-Tags). Daher habe ich jetzt mehrere Events, wo überall die (gleiche) Aktionsfolge für das Türöffnen drin steht. Wenn ich mal die Betätigungsdauer oder sonst etwas an der Folge ändern möchte, muss ich schauen dass ich es an allen Stellen ändere. Mit der FireEvent Aktion könnte man einfach an allen Events die den Türsummer betätigen sollen ein "FireEvent:openDoor" eintragen, und nur noch an einer Stelle (beim EVENT_openDoor) die "eigentliche" Aktionsfolge.

  • Bin derzeit im Urlaub, eingeschränkt konnektiv. Die Idee war, innerhalb eines Events erst das Licht für 30 Sekunden anzuschalten und dann während dieser Zeit etwas auszuführen. Also die Timer-Aktion abzufeuern, aber nicht 30 Sekunden auf deren Beendigung zu warten.


    LG


    pah