Alarm rules configuration

hello
I have the following bucket “fault” , but I can’t understand how to configure the ALARM rules to ensure that when a write to a row on bucket fault occurs, a recorded alarm is generated.

Hello @secur_lab

Currently the alarms are limited for what you are trying to achieve. The alarm rules are not yet able to execute a condition for each new data item, and are also not able to perform string comparisons.

However, there are some ways you can circumvent some of this limitations by setting up a low check interval, 1 minute for example, and check for the value of err, which is numeric. Lastly, I believe this would only give you the last error that occurred for each device.

Here is an example configuration:


screen.20240421-133240

thank you , ok now it works, i 've just changed the condition err_code.err IS ABOVE 0 , to activate notification for all alams

so i’ve now this instances :

but there is mode to show Values the field def on bucket (instead of the err_code.err 35) ,
on this field def (on buket ) there is description of error ?

I tried that when a second alarm occurs on the specific device, the first one is overwritten. Is it possible to keep both?

when I go to a user (user project with alarm * * rules activated) the alarm list is empty. How can I generate a specific alarm related to the project, so that project users only see the alarms of their specific devices?

best regards

Hi @secur_lab,

To address your issue with alarms being overwritten, you should create a unique rule for each alarm. This involves giving each rule a distinct name and description. This approach ensures that each alarm is tracked separately and they do not overwrite each other. This will also display the correct Alarm Name on the Alarm Instances list. For example, instead of the generic “alarmLift,” you can create a “High Temperature” rule that only monitors for this error code.

Regarding the alarm instances and their visibility on projects, ensure the origin device is inside the required projects. The alarm instances will be created automatically inside the device projects.

Hope this helps.

thank you very much, it’s actually a good idea,
we have around 85 alarms for the lift,

some are blocking and require the intervention of the technician,
others are only send and the elevator can re-start working properly again.

i 've try to insert Normalization rules with err_code.err == 24 that is send when the technician enters maintenance mode.
(and the alarm status changes from activated —> cleared)

everything seems ok, the only problem is how to manage the alarms list of the blocking or non-blocking alarm
over 48 hours or 72 hours, so that you have a list of the systems that have created problems in the last 48/72 hours.

there is a timed normalization rule?

best regards
Dante

Hi @secur_lab,

To manage the list of blocking and non-blocking alarms over 48 or 72 hours, you can use the “Normalization Confirmation” feature based on a timespan. This will help you track systems that have created problems within the specified time frame.

For example, you can configure the normalization rule to clear an alarm only if it is not re-triggered within 48 hours. Here’s a sample configuration for a 48-hour timespan. Note that this example does not include specific normalization conditions, so the normalization will default to being the opposite of the activation condition.

This configuration ensures that an alarm will be marked as cleared if it remains inactive for 48 hours. You can adjust the timespan to 72 hours if needed.

I hope this meets your requirements. Let me know if you need any further assistance.