[BUG] Alarm Journal delayed filters after 30 seconds

In Perspective's Alarm Journal component....when adding an expression binding to the "source" or "displayPath" filter conditions in the designer, the journal filters immediately and quickly. However, at runtime, when arriving to a page/view that has the journal, it shows ALL journal entries at first...then if you simply wait EXACTLY 30 seconds, it will filter appropriately automagically. This does not happen on the alarm status component, just the alarm journal component.
Running Ignition 8.1.4.

The journal props.name property is bound to a session custom property and the filter.conditions.source property is also bound to a session custom property. The source filter has this structure: "prov:PROV:/tag:TagFolderPath/SubFolder/*" where the PROV is the same value as the name property and the SubFolder is based on a session custom property.

This may be related, but wanted to include this older post referencing a crash when adding filters.

Correction. This also happens in the Designer when first opening up the view. All alarms are visible…wait 30 seconds, and then it filters.

Ok, I think I know what’s going on. The Alarm Journal table has a property called refreshRate which is set to 30 seconds by default. The issue is that it should perform the initial load of data with any filters applied (after bindings have been evaluated). The component is probably trying to load default values first, then perform bindings which somehow doesn’t trigger a refresh of data, then 30 seconds later, refreshes properly.

1 Like

I see the same thing.

Interestingly, the Alarm Status Table used to do the same thing. It loaded alarms with the initial value of the source prop lightning fast, then only evaluated the binding and reloaded.

Hoping they fix this too.

After some work I finally landed on a workaround for my application.

  • Add an “onStartup” script to load in the AlarmJournal.props.name ( props.name is actually the name of the alarm journal to query)
  • Before saving the screen delete the props.name value
  • Now when the view is opened, the props.name value is passed in and the filter is applied instantly

It’s obviously not ideal however it didn’t work at all for the screen to show all alarms for the provider for 30 seconds before applying the filters on initial view startup.