Notify nach einmal auslösen erst wieder bei Änderung eines Readings ausführen

[TomLee]

Hallo,

kann mir vorstellen das ich auch auf dem Holzweg bin und nicht an alle Szenarien denke die eintreten können.

Mein altes IPhone meldet sich ab und an auch während der Anwesenheit zwischendurch mal vom WLAN ab.

Dann löst mein notify aus und schickt mir meine Einkaufsliste:

Code Auswählen Erweitern

defmod not_sp_Thomas_pushek_isday notify sp_Thomas:presence:.absent {if(isday()) {fhem('pushek')}}
attr not_sp_Thomas_pushek_isday group Einkaufsliste
attr not_sp_Thomas_pushek_isday room Fernando

setstate not_sp_Thomas_pushek_isday 2021-09-28 11:06:23
setstate not_sp_Thomas_pushek_isday 2021-09-25 19:23:48 state active

Würde gerne verhindern das dies mehrmals am Tag passiert, die Liste nur einmal am Tag gesendet wird wenn sich an der Liste  nichts geändert hat.

Wie könnt ich das umsetzen daß das notify nach einmal auslösen erst wieder bei einem weiteren Event/Änderung des Einkaufsliste-Reading auslöst.

Mein erster Gedanke war disabledafterTrigger dort kann man ja aber nur Sekunden angeben, dort einfach nur das Reading anzugeben wär ja zu schön gewesen. Und sonst komm ich auch nach zwei Tagen darüber nachdenken immer noch auf keine Lösung, evtl. in ein paar weiteren Tagen, darum frag ich jetzt einfach mal nach.

Gruß

Thomas


edit:

klar kenn ich mittlerweile das Eventbasierte sleep, mir kommt aber nicht wie ich es damit umsetzen kann.

[Beta-User]

Wie wäre es mit einem watchdog?

Also erst ein wenig warten, ob das Handy sich nicht zurückmeldet => weniger "action".

Dann: watchdog nicht gleich wieder aktivieren, sondern nur, wenn entweder "neuer Tag" ist, oder sich die EK-Liste geändert hat?

[TomLee]

Bevorzugen würde ich gerne eine Lösung die in dem notify umzusetzen, ohne zusätzliches Device, hätt ich vlt. oben gleich erwähnen sollen.

Schön und gut mit dem watchdog, aber innerlich wehrt sich schon beim lesen alles in mir 

[Beta-User]

Nun ja, dann wirst du wohl ein paar Rahmenbedingungen abspeichern müssen, die dann erst mal bei jedem neuen Trigger gegengecheckt werden müssen und dann vermutlich erst mal ein "sleep/InternalTimer" einbauen dürfen, damit der "bin weg"-Event nicht direkt immer durchschlägt... Ob das einfacher ist (wobei es sich sowieso anbieten würde, den "gone"-Event anders zu ermitteln)?

[Otto123]

Du kannst es im Ausführungsteil mit einem benannten sleep versuchen, welches auf deinen Reading Event wartet. Durch die Benennung werden nicht immer wieder neue sleeps erzeugt wenn Dein Handy "wackelt"

[Wernieman]

Im Notify könntest Du Prüfen, ob sich die Einkaufliste geädert hast und nur dann senden. Müsstest Du aber programmieren ... für weitere Tipps müsste man wissen, wie denn die Einkaufliste bei Dir vorliegt ....

[TomLee]

Ob das einfacher ist ?

Sag mal so, beim lesen des letzten Vorschlag hat sich bei mir nix gewehrt, Interesse wurde geweckt, Hirnzellen etwas benutzt und ich denke dich dann zumindest ansatzweise verstanden zu haben, bis auf das

wobei es sich sowieso anbieten würde, den "gone"-Event anders zu ermitteln

Ich arbeite jetzt was, lass mir das den Nachmittag noch weiter durch den Kopf gehen und zeige später, Morgen, die Tage mein Ergebnis.

Danke.

[TomLee]

wie denn die Einkaufliste bei Dir vorliegt

Das ist die Einkaufsliste aus echodevice:

Code Auswählen Erweitern

setstate Echo 2021-09-28 12:57:17 list_SHOPPING_ITEM kleine_batterien,honig,eis,ahornsirup,pizzagewürz

(Ja, ich sehe gerade selbst das dort mal timestamp-on-change gesetzt gehört)

[TomLee]

Im Notify könntest Du Prüfen, ob sich die Einkaufliste geädert hast und nur dann senden.

Ich denke es so umzusetzen (schüttel mir das zwar nicht aus dem Ärmel, aber ich weiß das ich es irgendwo im Hinterkopf habe/bereits gelernt hatte, wie der Vergleich zu machen wäre) ist kürzer und einfacher wie Beta-Users Vorschlag.

[Otto123]

Ich würde es mal so versuchen?

Code Auswählen Erweitern

defmod not_sp_Thomas_pushek_isday notify sp_Thomas:presence:.absent {if(isday()) {fhem('sleep Echo:list_SHOPPING_ITEM:.* LSI;;pushek')}}

[Wernieman]

Weiß jetzt nicht genau, aber eine Idee währe:
Ein Hash der Einkaufliste in ein Dummy schreiben. Beim Auslösen des Notify prüfen:
- Hat sich der Hash geändert, wenn ja
-> Mail senden
-> Neuen Hash ermitteln und Abspeichern

... Wobei, geht natürlich auch ohne hash, sondern mit dem aktuellen Inhalt. Du brauchst eben nur ein Dummy, wo Du nach dem senden den Wert speichern kannst ....

[TomLee]

Ich würde es mal so versuchen?

Erst dacht ich Otto hatts noch nicht genau verstanden, zwei-drei Minuten hab ich erst verstanden das es sehr wsl. die Lösung ist, ich probiers später.

... Wobei, geht natürlich auch ohne hash, sondern mit dem aktuellen Inhalt. Du brauchst eben nur ein Dummy, wo Du nach dem senden den Wert speichern kannst ....

Dummy setzt dem watchdog jetzt aber noch eins drauf , warum, wenn in die Richtung, nicht OldReadingsVal verwenden oder hab ich was nicht verstanden.

[Wernieman]

Stimmt ... OldReadingsVal ... vergesse ich immer, da ich in den Anfängen von fhem damit Probleme hatte .....

[Beta-User]

...vermutlich habe ich den zeitlichen Verlauf nicht verstanden...
Ottos Vorschlag mit dem "notify-sleep" setzt voraus, dass erst das Handy weg ist, und sich dann die EKL ändert? Ist das so gewollt? Sonst könnte man die Events umdrehen.

Wenn tatsächlich nur auf Handy-"absent" getriggert werden soll: Warum nicht ReadingsAge() von der Liste abfragen? Nur raus, wenn heute (oder <24h?) geändert.

[Otto123]

ich habe den Fall betrachtet: Handy "flattert" und nur wenn sich die Liste ändert soll gesendet werden. Der Fall Handy flattert nicht und die Liste ändert sich und soll gesendet werden geht so natürlich nicht. Events tauschen ist da vielleicht die Lösung - überblick es noch nicht ganz.