For a driver we have a table where each row is a Converter and then columns for its state (Status, Mute Status, etc).
I'm trying to create an alarm template that generates an alarm when all converters are muted and when all converters are not muted.
However, I'm already blocked on the first case (all converters muted). I setup the following alarm template but still see an alarm when a single row has "Mute" value.
(condition in alarm template looking to all rows in the table with value different than "Mute" > this would turn off monitoring therefore no alarms should be raised)
(alarm still there with one row with "Mute" value)
Hi Bruno, to clarify, the "all rows" in the condition editor does not mean that the value of all rows will be joined, but rather that the condition will be applied to all rows. This means that for each individual row, the condition will check the value of the referenced parameter in the same row if the parameter is in the same table, or a row with the same key if the reference parameter is in a different linked table (from DataMiner 10.0.5 onward).
The other option, "Single row" means that for each row matching the filter, the condition will always be validated against the parameter value of a fixed row, for which you will be able to select the key in the dialog.
Could a driver modification help to fit your needs? As you indicate "generate an alarm when all are muted or when all are not muted". So you want to see one alarm. This feels like the need for one monitored parameter, else if the conditional monitoring would be possible then all rows will be in alarm (15 converters that are muted = 15 alarms, one of 15 that is not muted = no alarm). Also if you want to see one alarm then on what row or where should the single alarm be placed on? If you would have a driver modification and add one single parameter that represents the % of converters that are muted then you can put monitoring on that parameter and alarm when 0% or 100% .
If you don't want to modify the driver, then a workaround could be to use an aggregation rule in a surveyor view, but then the alarm will be on the view instead of the element, and you would kind of need to have a view per element to separate the elements from each other. So not ideal and my personal preference would be to simply add a parameter to the driver.