parameters SYS_THRESHOLD_REARMED

[DanG]

Documentation states that the SYS_THRESHOLD_REARMED event has 4 parameters which is less than those available for a triggering event.
It would be better if all parameters would be available for the SYS_THRESHOLD_REARMED event as well as these give valuable information.
As an example when monitoring free disk space, when the capacity goes above the threshold it's nice to know what the threshold was and was is the current value. Unless of course this can be achieved in some other way?

[victor]

I agree that making SYS_THRESHOLD_REARMED to have less parameters than threshold violation event was a bad decision. The best option probably could be changing it to have same parameters in same order as SYS_THRESHOLD_REACHED, but this will broke compatibility with existing setups. Compatibility will be retained if we add missing parameters at the end, but as same data will be at different places for reach and rearm events, this may cause additional configuration errors. I'll do something with it in 1.1.4, but I don't decide exact solution yet.

Best regards,
Victor

[DanG]

I'm glad to hear you agree with me  ;D

The points you mentioned about maintaining compatibility are without any doubt very important.

If I may propose a solution, you may want to introduce named parameters instead op %digit notation.
This will solve all the problems as current parameters will remain unchanged and new parameters will have another form. I believe using named parameters present other advantages:

• Easier to read.
• Easier for you to extend over time, no ordering issues and no issue when the number of parameters becomes large.
• Can be made easier to type with a auto-complete (this is I guess me just getting too excited)
  There is some performance penalty when replacing named parameters with there values, but I don’t think  this should be significant.

Dan

[victor]

I have added support for named parameters in events. This functionality will be available in 1.1.4 release. Currently only threashold reached/rearmed events have named parameters. Named parameters can be accessed using %<name> macro and using GetEventParameter function in NXSL scripts. The following parameter names available for threshold violation/rearm events: dciName, dciDescription, dciId, instance, thresholdValue, currentValue, isRepeatedEvent (latter only for threshold violation events).

Best regards,
Victor

[DanG]

Victor,

This is great news! I Look forward to using the next release.

Dan

[DanG]

Hi Victor;

I configured today an event using the new named parameters, it works like a charm. Thanks for this new feature!
A little note to other users, the syntax %<name> does include the inequality signs <>

Parameters list:
    %<dciName>
    %<dciDescription>
    %<dciId>
    %<instance>
    %<thresholdValue>
    %<currentValue>
    %<isRepeatedEvent> (latter only for threshold violation events).

Victor, I think you should update the documentation to reflect this enhancement as I'm sure many will prefer to use it over the "older" way of using parameters.

Regards,

Dan