DoorPi-Verhalten bei Sturmklingeln?!

  • Ich würde mir das so vorstellen, dass man für jedes Event eine ignore-Zeit einstellen kann. Dann könnte man sich (vielleicht) zentral innerhalb der FireEvent-Methode sich diese Zeit für das Event holen und wenn es noch nicht erlaubt ist, einfach nichts tun.


    Ich weiß, ist immer leicht gesagt wenn man den Code nicht kenn (habe noch nicht rein geschaut). :D


    Das würde natürlich bedeuten, dass man sich für jedes gefeuerte Event einen Zeitstempel merken müsste, um später entscheiden zu können ob es schon wieder erlaubt ist.

    • Offizieller Beitrag

    Das Problem daran ist die Menge an Events, die DoorPi von sich gibt. OnKeyPressed, OnKeyPressed_gpio und OnKeyPressed_gpio.17 sind drei Events zum gleichen Auslöser.
    Auf der einen Seite sorgt das für Flexibilität, auf der anderen ist es eben schwer die untereinander abzugleichen.


    Wenn es drei Actions gebe, eine "lock_file_write", "lock_file_check" und "lock_file_delete" dann könnte man die Lösung von @han-solo innerhalb von DoorPi abbilden, oder? Das würde auch über Events hinweg funktionieren.


    Fehlt nur noch ein Time-Out des Lock-Files, damit es nach x Sekunden gelöscht wird, falls es in der Abarbeitung zu einem Fehler kam und das Löschen nicht durchgeführt wurde, sowie ein clean_up aller Lock-Files beim Start von DoorPi.


    Also sollten alle Lock-Files in einem definierten Ordner, der von DoorPi selbst auch noch einmal überwacht wird.


    Wie seht Ihr das?

  • Klingt im Prinzip gut, aber iIch glaube ich habe das mit den Lock-Files noch nicht ganz verstanden.
    Wie würde ich festlegen, dass gelockt werden soll, würde ich das quasi in die Liste eintragen, a la:

    Code
    [event_xxx]
    10 = lock
    20 = call_script

    ?


    Oder bin ich auf dem ganz falschen Dampfer?


    Und vor allem wie würde man festlegen dass es nach einer Zeit x automatisch wieder freigegeben werden soll?

    • Offizieller Beitrag

    Eine Lösung, die mir vorschwebt, wäre:



    lock_file_check:event_klingel_1 prüft, ob bereits für event_klingel_1 ein lock vorliegt - wenn nein dann weiter, sonst breche die Verarbeitung vom Event an dieser Stelle ab
    lock_file_write:event_klingel_1 setzt den lock für event_klingel_1
    take_snapshot erstellt Bild per Kamera
    call startet den Anruf
    sleep wartet 1 Sekunde
    mailto sendet eine E-Mail raus (den Platzhalter !LAST_SNAPSHOTS_3! gibt es noch nicht, wäre aber nicht schwer umzusetzen)
    lock_file_delete:event_klingel_1 löst den lock wieder


    Aktuell würde ich die locks vermutlich als Datei umsetzen, aber zukünftig könnte das auch im Speicher oder in einer DB ablaufen.

  • Finde ich prinzipiell nicht schlecht, eine Sache ist meiner Meinung nach aber unschön:


    Normalerweise (=bisher) wird die Action-Liste immer linear abgearbeitet, ohne darauf zu achten was die vorherige Action gemacht hat. Jetzt gäbe es dann eine Ausnahme, das lock_file_check kann die Abarbeitung abbrechen. Das wäre quasi sowas wie eine if-Bedingung, der man das aber nicht ansieht, und ein anderes Verhalten als alle anderen Actions. Also irgendwie nicht so richtig durchgehend.


    Ich denke schon ne Weile über ne Alternative nach, ich hätte auch einen Ansatz, aber der ist noch nicht so ganz rund. Und zwar so eine Art "Condition", die man für ein Event definieren kann (in einem extra Block in der Config). Ich versuche das mal zu Ende zu denken und poste es dann :D

    • Offizieller Beitrag

    @Joker Versuch mich bitte bei dem Gedankengang mitzunehmen - hab schon viel ausprobiert und mir angesehen (von SQL-Syntax bis hin zu BPML) aber noch keine Lösung gefunden, die mir wirklich zusagt...


    // EDIT \\
    Wer die Prüfung nicht nutzen will, kann es ja auch gern weglassen...

  • Also ich denke im Moment an sowas:



    Code
    [CONDITION_OnKeyPressed_gpiotaster.17]
    00 = not_locked

    Quasi eine extra Section wo man Bedingungen hin schreibt, ob ein Event ausgeführt werden soll oder nicht. Aber ich weiß noch nicht wie man das setzen und Rücksetzen der Bedingung sauber formulieren kann. Also wie gesagt, noch nicht durchdacht :D
    Und ich kenne auch den Code nicht, ob das überhaupt sinnvoll machbar wäre.

    • Offizieller Beitrag

    Und ich kenne auch den Code nicht, ob das überhaupt sinnvoll machbar wäre.

    Das ist die beste Voraussetzung um gute und brauchbare Hinweise zu geben - und das ist ernst gemeint...
    Wenn man den Qullcode kennt, ist man im Denken manchmal etwas auf spezielle Lösungen fokussiert...


    Deine Idee beinhaltet aber auch wieder neue Sektionen und die Config wird noch unübersichtlicher.
    Außerdem wäre es dann nicht möglich Aktionen immer auszuführen und weitere nur in Abhängigkeit.

  • Wenn man den Qullcode kennt, ist man im Denken manchmal etwas auf spezielle Lösungen fokussiert...

    Ja, kenne ich :D

    Deine Idee beinhaltet aber auch wieder neue Sektionen und die Config wird noch unübersichtlicher.

    Sagen wir mal so... länger wird sie, aber unübersichtlicher finde ich es nicht. Da es eine separate Sektion ist finde ich es eher übersichtlicher, das eine ist die Liste der Aktionen die ausgeführt werden soll, das andere sind die Bedingungen dafür.

    Außerdem wäre es dann nicht möglich Aktionen immer auszuführen und weitere nur in Abhängigkeit.

    Wie meinst du das, also dass bestimmte Aktionen von einem Event ausgeführt werden und andere nicht? Das stimmt, die Frage wäre ob es dafür einen Use-Case gibt? In deinem Vorschlag ist es auch nur möglich, an einer Stelle komplett abzubrechen...


    Ich denke mal noch ein wenig nach. Wie gesagt ist die Idee von mir bisher eher halbgar. :D