Query journal alarm, no millisecond, sorting issue

Ignition
1

I query historical alarm from the journal with system.alarm.queryJournal.
In my case data are stored in MYSQL.

if the alarm is active and cleared in the same second when I sort my result with event time, the chronological order can be wrong because the event timetamp has no millisecond.

The alarm journal table seem to have an incremental id which could be perhaps used to give the chronological order of event but this id is not returned by the system.alarm.queryJournal result ???

system.alarm.queryJournal. return a list of event, but is there a sort order ?

Since mysql 5.6+, DATAETIME(3) enable to store datetime with milliseconds. It will be usefull to update alarm journal creating script for support of millisecond.

1 Like
2

Heh, I knew I dodged a lot of bullets over the past twelve years by choosing PostgreSQL. I just didn’t know about all of them (probably still don’t).

3

@KathyApplebaum,
It would be usefull that the system.alarm.queryJournal return the id (AutoIncremental PK of the alarm_events table) for sorting the data according the insert order, if a datetime with millisecond is not possible.
(getId return the eventid).

system.alarm.queryJournal Returns :
List - A list of matching AlarmEvent objects. AlarmEvent objects can be examined with getAckData, getActiveData, getClearedData, getCount, getDisplayPath, getDisplayPathOrSource, getId, getLastEventState, getName, getNotes, getOrDefault, getOrElse, getPriority, getProperties, getRawValueMap, getSource, getState, getValues, isAcked, isCleared, isExtended, isInherited, and isShelved.

4

I think they’re reworking some of the alarm journal stuff in Ignition 8? If so, hopefully something like that would get in. I’m not on that team, so I have no idea.

1 Like
5

I'm having this same issue in v8.1.28. When listing events in the Alarm Journal component in Vision, ordering by Event Time isn't precise enough to show the exact order in which events happened. When an alarm is raised in the same second it's cleared, like I just encountered, the raised event is sometimes ordered after the cleared event, making it look like the alarm is still active, leading to confusion. I'm using MySQL v8.0 and millisecond precision DATETIME columns are supported (since v5.6+ it looks like).

Has there been any movement on this? This is an issue I'd prefer not to have to develop a workaround for, if that's even possible.

6

I was working on something about alarming and hit that same issue. I figured out that the problem come from the fact that Ignition create the column as DATETIME. But to be able to see the fractional part it has to be a DATETIME(3).

Running this querry:
ALTER TABLE alarm_events MODIFY eventtime DATETIME(3)
fixed the problem

2 Likes