Forum Discussion
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?
Related Content
- 18 days ago