Alarm Journal Table: Label field displays incorrectly

Hi all,
I’m using an Alarm Status Table to show real time alarms and an Alarm Journal Table to show the alarm history.
My alarms are Bit State alarms. The text that is to be displayed to the operator is split between the Label and the Display Path alarm fields.
I’m experiencing the following issue: the alarm shows up correctly in the Alarm Status Table such as in the following screen capture

where you can see the Active Time, Label, Display Path fields, whereas the same alarm shows up as in the following screen capture in the Alarm Journal Table

where AlmBit25 is the alarm Name instead of the Label field.

Any suggestion?

Ignition version: 7.9.8 (b2018060714)

If the Label field is populated with a static value, you will need to ensure that your alarm journal is set to store “Static Config” - see the reference properties here: https://docs.inductiveautomation.com/display/DOC79/Journal+Properties+and+Tables

Basically, because the alarm journal is entirely database driven, if you enter a static alarm label, there’s no way for the journal table to reference a value for the label field - unless you tell the journal to store that static config as well (or, more DB-space efficiently, just make the value “dynamic” with an expression like "[DB1001.DBD56] - NB7_D56").

1 Like

Hi @PGriffith,@pgmo,

Moreover when I call system.alarm.queryJournal function, all event object have ‘Label’ property in AlarmQueryResults except ACKED AlarmEvent.

Ignition version: 7.9.8 (b2018060714)

@PGriffith:

Bringing this up again, the “static config” works for all events except the acked event. The ack event does not store the static text in the journal.

In this example all events are from the same alarm. The ack does not show the static label:

Has this been investigated by Ignition? I’m having the same problem and “Static Config” has been checked. Works great for Alarm Status display. Works well for Alarm Journal except when the alarms are being ack’d!!

Need a fix guys.

Thank you.

I’m running the report on alarm history as well and the problem exists the same way. So I’m assuming the problem comes from when the acknowledge action is written to database!

I’am have the same problem…

A workaround before it was fix in future Ignition delivery …

Make a MySQL NamedQuery Trigger with this params: {“dbName”:“histo”,“tableName”: “alarm_events”,“dataTableName” : “alarm_event_data”} and execute this query on Gateway Startup Script

CREATE TRIGGER `{dbName}`.`{tableName}_AFTER_INSERT` AFTER INSERT ON `{tableName}` FOR EACH ROW
BEGIN

	DECLARE propId INT;
	DECLARE eventid varchar(255);

			
	SET @eventid = NEW.eventid;
	SET @propId = NEW.id;

	IF NEW.eventtype = 2 THEN
				
		INSERT INTO {dataTableName}
				(id,
				propname,
				dtype,
				intvalue,
				floatvalue,
				strvalue)
			SELECT  
				@propid,
				{dataTableName}.propname,
				{dataTableName}.dtype,
				{dataTableName}.intvalue,
				{dataTableName}.floatvalue,
				{dataTableName}.strvalue
			FROM 
				{dataTableName}
			INNER JOIN 
				{tableName} 
			ON 
				{tableName}.id = {dataTableName}.id
			WHERE 
				-- {dataTableName}.propname = 'label' 
				-- and 
				{tableName}.eventid = @eventid;
		
	END IF;


END

HI,

I’ve juste tried on the last version (7.9.12) and the problem is still there.
Displaying the label on the Alarm Journal Table worked, but if you want to get it by scripting with the function system.alarm.queryJournal, all event object still show the Name instead of the Label (Ex : AlarmEvent.label or AlarmEvent.getLabel())

You have to test with new alarms history generated agter 7.9.12 upgrade.
The old alarms have no data associated in alarm_event_data.

This issue still seems to persist with 8.0.4 as well. Setting a static text, or setting an expression containing the static text will still return the ‘name’ when using system.alarm.queryJournal.

1 Like

I’ve tried to make all the labels ‘dynamic’ with static text, but they will still not store the values. Expression like “Test alarm label 1”. Is this what you are saying, or something else?