I understand that there will be new properties on folders that tell you information about alarms within a folder.
Does this allow us to totalize active alarms by priority and acknowledge state?
I'm working on a system that animates things yellow if there is a warning in an area and red if there is an alarm. It also makes things blink if the alarm or warning is unacknowledged.
I've organized their tags in a hierarchical way in hopes that a future upgrade to 8.3+ will allow them to optimize their alarm handling (eliminating my global timer script) but I'm not sure what the structure of the alarm meta data for a folder of tags will look like in 8.3.
+1, would be amazing if folder could be able to summuraize alarms with criteria like prioriry, state, but also with condition based on alarms associated data
1 Like
Currently, the implementation in 8.3 for alarm aggregation adds the below "virtual" properties to all (non-root) folders, so that you can subscribe to them via a binding :
4 Likes
Excellent. Thanks for the information.
Why would we not be allowed to read these values via a system.tag.readBlocking? That seems counterintuitive since all other properties under a tag can be read that way. This could block certain use cases where we want to serve out alarm summaries to external systems via WebDev. Or maybe we just want to make use of the summaries inside the system outside of bindings. I would ask that the team reconsider making this an available option.
1 Like
I'm not sure he's saying you won't be able to do that. He was just stating that you'll be able to bind directly to the properties which is a more scalable way to access the information.
What use case do you have in mind where you want to use system.tag.readBlocking on them?
I'm fairly sure @PGriffith is saying you can bind directly to them:
Which is the way we would primarly use this feature. However the text behind the three dots. (don't even know how do to that by the way) says:
One case would be getting the summary of alarm information for an area of the facility by just reading these properties via the readBlocking script. This may be necessary because we need to share this information externally or maybe we want to run through the system and display a snapshot of current alarms per area in a diagnostic window (I realize this should be available via bindings but see no reason why it should not work via a tag read as well)
The only thing I can think of is IA does not want these tags to be written into the JSON file summarizing the tag configs. Hence the statement that it is "virtual" and therefore not available in the same way as other tag properties?
If they're bindable, it may be possible to make your own reference/expression tags to the virtual properties? This way they show up as tags, that you could then call via scripts, but the only use case I see would be something like building an API for the web dev module for external systems to call.
I don't know that you won't ever be able to read them directly; I'm just saying that as of this writing, the current 8.3.0 codebase only allows subscribing to them. My (barely) educated guess is that there's some constant overhead to creating the alarm subscription, which is acceptable for a subscription approach but may make individual reads infeasible. The original "add alarm aggregation" RFC explicitly listed scripting access to these props as a "future goal" - so I'm not saying "never", just "not right away".
As a side note, you can author Discourse footnotes in a couple ways, but I prefer ^[some footnote]
2 Likes
