I think there is an issue with the loading in 8.1, it seems like bindings aren’t evaluating when the page loads, particularly from within embedded views.
Nice! Although I haven’t had this issue with any other embedded views with other components. Perhaps the alarm status table is one of the ‘lucky’ ones?
My experience so far has been with column containers loading with whack span and height settings for components within it. All of which have bindings set up on them. Another one I had recently is components with an enable binding giving disabled (which it is by default) instead of enabled (what the binding outputs). It doesn’t happen 100% of the time though so I suspect an issue with load order or when bindings are evaluated.
The AST is set to recheck data changes every 5 seconds by default. You can change this if you’d like. Is that what you’re running into?
Or is your expression binding not evaluating as you are expecting? Maybe a combination of both? Try attaching a property change script with some logging to narrow it down.
Not sure what you mean by AST?
However if the alarm filter doesnt apply at the start, then it never applies no matter how long I wait on the page, so it looks like either the binding doesn’t update or the filter just isn’t being applied.
Hey, Nik. AST is just an abbreviation for Alarm Status Table. Can you provide more information about your setup, please. I’ve attempted to replicate, but have had no luck. Thanks!
I suppose you could try setting up a page to look at AlarmPanel directly and see if it still occurs. Also if you have any bindings on your AlarmPanel params, try setting the params
to input/output, I’ve had that cause problems for me.
Can confirm we’ve seen this happen maybe 4 times in the past month on our 8.1.0 instance as well. We have not been able to reproduce the issue intentionally yet. As Nick said, when a browser lands on the view without a filter, it never self-corrects. The user has to hit refresh on the browser to fix it.
Some extra info about our setup: along with the binding on props.filters.active.conditions.source, we also have the Persistent property enabled and a default value that should point to no alarms (prov:MQTT Engine:/tag:Edge Nodes/invalid/none/*). Somehow it looks like both the persistent setting and the binding are ignored when it breaks.
Is there any chance this was improved/fixed in a later 8.1.x release? Knowing so would increase the priority of our upgrade plans. (We plan on upgrading, but other issues are more important right now.)
Still seeing this behavior in 8.1.26. @Support Is there a fix for this? I have props.filters.active.conditions.source bound to a value. Sometimes it works, sometimes it does not. Frustrating.
Interested if we have a solution, we are experiencing a similar behavior on 8.1.31, sometimes alarms show on some clients but they dont on others until you hit refresh.
We have the filtering using filterAlarm on the Extension functions.
I have found that setting the binding on the source filter of the alarm summary component to persistent seems to fix this issue. I do not use the source extension function.
We are filtering using "Associated Data" on the Alarms. In our use case some alarms are applicable to a system(area), but some of them within the same system are applicable to other areas as well for which we are using "areas" defined in the "Associated Data"
I am tying to figure out if there is a way to use conditional filtering, seems that I can only filter based on alarmPath / Display Path / Providers.