Alarm Notification "only" for the First OFF

Hi, is there a smart way how i can manage that only the first alarm (e.g., per day) is sending a notification.
My very basic idea would be that I have one dummy-variable per alarm which is set when alarming so it locks afterwards and every midnight it all gets cleared so a new alarm would work again as every variable is unlocked then…

Guess this is not too smart and Openhab2.3 can do better, really hope so. Thanks for linking me to the right approach. Norbert

You can combine this with the Design Pattern: Associated Items and have a flag for each Item you want to limit the alerts for.

Thanks, just found an older reply from you as well. Will check this Event Limit approach, worst case your other idea sounds feasible…but i would need lots of dummy switches :frowning:

By Rich:
I use restoreOnStartup so my items are almost never NULL. But in this case if I just check to see if the switch is ON, then the case where it is OFF or NULL is already covered.

if(alerting_condition) {
    if(Frontdoor_Notified.state != ON) {
        // Send alert
        Frontdoor_Notifief.sendCommand(ON)
    }
}
else {
    Frontdoor_Notified.sendCommand(OFF)
}

Obviously you need to replace the alerting_condition with what makes sense for your situation and use the Associated
Item DP to get the appropriate Notification Switch.

hm, but isn’t this “event limit” code exactly what you ment with your “old” post…based on switches not boolean variable.

Where do you put this: var boolean alerted = false ??
is this variable definition in the top corner of rules file? never had this, but will such variable definition on top of the file be run once…so initialized with false and never run through this as long as OH2 is not restarted?

My issue is still that i have arround 15 battery driven ESPs that should alarm when battery voltage is below 3,5V. Either is skip inidivdual alerts and the first alert of a battery is notified…or i have to have 15 boolean variables.

Probably. You didn’t provide the link to the old post so I don’t know the context. Look at the Complex Example, which is a link to Generic Is Alive which is probably closer to what you are trying to do.

Right where it is in the example, Above all the Rules.

See https://docs.openhab.org/configuration/rules-dsl.html#the-syntax

A rule file is a text file with the following structure:

Imports
Variable Declarations
Rules

I think this is correct. The global variables are only initialized once when OH reads in the .rules file.

Correct. though if you use Assocaited Items you can create Items for the flag, or even better a DateTime and your Rule can be very simply written.

rule "Battery Alert"
when
    Item gBatteries received update
then
    gBatteries.members.filter[battery| battery.state as Number < 3.5].forEach[battery |
        val lastAlert = gBatteryAlerts.members.findFirst[alertTime | alertTime.name == battery.name + "_LastAlert"]
        if(now.minusDays(1).isAfter((lastAlert.state as DataTimeType).getZonedDateTime.toInstant.toEpochMilli) {
            lastAlert.postUpdate(new DateTimeType)
            // send the alert
        }
    ]
end

See the Associated Items DP for how to define your Items.

If you see multiple alerts you might need to use a reentrant lock. See https://docs.openhab.org/configuration/rules-dsl.html#concurrency-guard

Hi Rich, so the Battery Alert example is already a valid template for my “battery voltage once per day” requirements.
Not all parts are clear, but is there an array of alert timestamps stored per battery filled with every alert +1? How are they cleared at the end of the day? Also my battery updates arrive for some items every 5mins…so lots of values stored…or do i misunderstand the whole concept…i fear.

Cheers,
Norbert

No. You create a DateTime Item for each Battery Item named the same as the Battery Item with “_LastUpdate” appended to is name and placed into a gBatteryAlerts group.

They are never cleared. The code looks to see when the last time an alert was sent and only sends another one if it has been longer than 24 hours.

This.

It works by timestamps and uses names and groups to associate the timestamp with the battery Item as documented in the Associated Items DP I linked to above.