Event Source 'Liebert_Condition_Events' concern

[Vitor Santos 71]

Hello,

We've noticed the out of the box event source 'Liebert_Condition_Events' is triggering alarm where the actual date of the event is in the future (example below):

NOTE: Blurred the device name (in order to protect our client information)

I've already accessed the device in question & the system time is correct.

Could this be an issue with the data source 'timestamp' handling? Or there's another thing that I might be missing?

Thank you!

[Stuart Weenig 66]

Ok, the message template for that EventSource looks like this:

The Liebert device ##HOSTNAME## is reporting a condition: ##VALUE##

This condition has been ongoing since ##START##, -- or for ##DURATION##.

Scripted EventSources output json containing one object "events". That events object is a list of events (because the script could uncover more than one event when it runs). In this case, it looks like there's only the one event. The structure of the event output looks like this (from this documentation😞

{
    "events" : [
                  {
                     "happenedOn":"Fri Jun 05 09:17:47 UTC 2015", 
                     "severity":"Warn", 
                     "message":"This is the first event's message", 
                     "Source":"This is the source of the first event"
                   },
                   {
                     "happenedOn":"Fri Jun 07 09:27:37 UTC 2015", 
                     "severity":"critical", 
                     "message":"This is the second event's message", 
                     "Source":"This is the source of the second event"
                   }
               ]
} 

The ##VALUE## token is equivalent to the all four objects in each event (looks like maybe the source isn't included or is optional and not used in this case).

This line in the code is where the timestamp gets converted from the raw data:

def timestamp = sysuptime_string_to_date(current_conditions_table_hash[key]['3']);

I would guess there's a problem converting the timestamp using that "sysuptime_string_to_date" option, or the value in current_conditions_table_hash[key][3] is not right. 

Does that get you started? If you can't get much farther, I'd engage support.

[Vitor Santos 71]

1 hour ago, Stuart Weenig said:

Ok, the message template for that EventSource looks like this:

The Liebert device ##HOSTNAME## is reporting a condition: ##VALUE##

This condition has been ongoing since ##START##, -- or for ##DURATION##.

Scripted EventSources output json containing one object "events". That events object is a list of events (because the script could uncover more than one event when it runs). In this case, it looks like there's only the one event. The structure of the event output looks like this (from this documentation😞

{
    "events" : [
                  {
                     "happenedOn":"Fri Jun 05 09:17:47 UTC 2015", 
                     "severity":"Warn", 
                     "message":"This is the first event's message", 
                     "Source":"This is the source of the first event"
                   },
                   {
                     "happenedOn":"Fri Jun 07 09:27:37 UTC 2015", 
                     "severity":"critical", 
                     "message":"This is the second event's message", 
                     "Source":"This is the source of the second event"
                   }
               ]
} 

The ##VALUE## token is equivalent to the all four objects in each event (looks like maybe the source isn't included or is optional and not used in this case).

This line in the code is where the timestamp gets converted from the raw data:

def timestamp = sysuptime_string_to_date(current_conditions_table_hash[key]['3']);

I would guess there's a problem converting the timestamp using that "sysuptime_string_to_date" option, or the value in current_conditions_table_hash[key][3] is not right. 

Does that get you started? If you can't get much farther, I'd engage support.

 

Ok so I've ran the groovy script in Debug console & tweaked it like this:

It returned this:

I see the first event is good & its no longer getting triggered because it already passed. 
However the second event still display the data wrongly & LM it triggering that alarm every 60 minutes (but duplicated)

The event date I guess it could be a bug at the device (I'm thinking on raise a case with support anyway). However, related with the duplicated alarm, do you have any idea why?

[Vitor Santos 71]

I've further checked the event table on the device itself & the date isn't the same (obviously ).

I've raised a support case #208119 to engage support.

Thank you for the availability!!!