Ja, das ist klar, denn du hast ja sowohl eine NoticeRule als auch ein NoticeEvent, die per ausgelöstem Ereignis aufgerufen werden. Das geht nicht - entweder / oder. Wenn du sowohl bei Beginn als auch bei Ende eine Meldung bekommen willst, bitte NUR den NoticeEvent aufrufen (und in dem NoticeEvent auch die Meldung bei Wiederherstellung konfigurieren (was du getan hast)), sonst NUR die NoticeRule, dann gibt es nur beim Ergebnis-Eintritt.
im NoticeEvent wird ja eine NoticeRule eingetragen, die bei Meldungen verwendet werden soll (also hier Warnung (Notice Rule)).
Also zusammenfassend: Es will nicht.
Bei Eintritt des Events klappt alles, beim Wiederherstellen bleibt alles stumm.
Ich hab jetzt wie oft drüber geschaut, vielleicht hast Du ja noch ne Idee wo ich das was verbockt haben könnte (Mittlerweile habe ich sogar den Symcon Service mehrfach neu gestartet).
Ich schick noch zwei Screenshots mit, falls Du noch weitere Infos braucht, sag bitte Bescheid.
Leider kann man nicht erkennen, wie die Bedingung vollständig formuliert ist, der Screenshot schneidet ab.
Dann ist nicht zu erkennen, wie die vollständigen Einstellung im „auslösenden Ereignis“ sind. Auch hier ist es abgeschnitten, sowohl die Aktion, als auch eventuelle Bedingungen.
Im Aktionsbereich gibt es ja „Modul-Aktivitäten“ - was steht da nach einem solchen Versuch?
Und dann würde ein Debug der Instanz helfen; unbedingt die Limitierung erhöhen, weil man mit den standardmässigen 100 Zeilen nicht sehr weit kommt. Hierzu unbedingt die Zeiten notieren, wann Änderungen der auslösenden Variablen oder sonstige Aktivitäten erfolgen - nur so kann ich das im Debug zuordnen.
Moin
und nochmal Danke für Deine Geduld.
Einmal Start mit folgendem Stop hat folgendes Ergebnis gebracht
Ich meinte, das du Dokumentierst (sowohl Aktivität als auch Debug), wenn die auslösende Variable geändert wird („es regnet“ =true unf dann wieder =false)
Ich bin mir nicht sicher ob ich verstehe was Du meinst.
Ich ändere die Variable manuell innerhalb von IPS und quasi verzugslos ändert sich die Variable. Zeitgleich erscheinen die Debug-Zeilen zu den dort angebenen Zeiten. (08:51:06 von FALSE auf TRUE und 08.52:24 wieder zurück)
Ok, wir reden aneinander vorbei. In Deinem Post hattes du etwas von Start und Stop geschrieben - was hast Du damit sagen wollen?
Was steht im Panel Start-Verzögerung?
Start = Beginn des Ereignisses (Regen)
Stop = Ende des Ereignisses
Ok, ich richte mal etwas bei mir ein und spiele das mal durhc
Bin auf das Ergebnis gespannt
Es gab eine Bedingung, die hierfür nicht richtig geprüft war: ein NoticeEvent ohne definierte Meldungswiederholung.
Ist nun korrigiert (v1.13), Modulstore/Beta (also im Modulstore bei dem Modul auf den Betakanal wechseln)
Super, es funzt jetzt!
Ich hatte schon Angst, dass ich Dich hier ewig beschäftige und dann hab ich nur irgendwas blödes vergessen/falsch eingetragen.
nö, kein Problem. sind ja diverse Optionen zum Feintuning drin. Und da stösst man mal mit den Hintern was um, während man vorne umbaut.
Habe da leider noch etwas gefunden, von dem ich nicht weiß ob es ein Bug oder ein Feature ist:
In einem Script bereite ich mir den Mail-Content in Abhängigkeit der geöffneten/gekippten Fenster auf, das Ergebnis speichere ich dann in einem String ab und übergebe es dann an Dein Modul (s. Screenshot). Bei der Wiederherstellung werden in dem Fall aber nicht die dort hinterlegten Werte verwendet, sondern es erscheint der identische Text wie beim Auslösen des Ereignisses nochmal.
Ich glaube nicht, dass das so sein soll.
Bei einer zweiten Sache bin ich mir nicht sicher auf welche Weise ich das charmant lösen kann:
Ich habe festgestellt, dass es innerhalb einer kurzen Zeitspanne immer wieder an- und aufhört zu regnen. Dieses „flapping“ löst jeweils eine neue Mai/Telegram/… aus.
Hast Du eine Idee wie man geschickt eine Art Nachlauf definieren kann, in dem dann keine Nachrichten gesendet werden? Momentan löse ich das eher unschön mit einem Script-Timer.
