# Question about Ignition 8.3 Alarm Properties **URL:** \ **Category:** Ignition\ **Created:** [April 1, 2025, 12:50pm UTC](https://forum.inductiveautomation.com/t/question-about-ignition-8-3-alarm-properties/104511 "2025-04-01T12:50:28Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Steve\_Laubach](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/steve_laubach/32/60900_2.png) [@Steve\_Laubach](https://forum.inductiveautomation.com/u/Steve_Laubach)\ **Post date:** [April 1, 2025, 12:50pm UTC](https://forum.inductiveautomation.com/t/question-about-ignition-8-3-alarm-properties/104511/1 "2025-04-01T12:50:28Z")
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. ---
**Author:** ![mazeyrat](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/mazeyrat/32/10955_2.png) [@mazeyrat](https://forum.inductiveautomation.com/u/mazeyrat)\ **Post date:** [April 1, 2025, 2:48pm UTC](https://forum.inductiveautomation.com/t/question-about-ignition-8-3-alarm-properties/104511/2 "2025-04-01T14:48:25Z")
+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 ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [April 1, 2025, 10:23pm UTC](https://forum.inductiveautomation.com/t/question-about-ignition-8-3-alarm-properties/104511/3 "2025-04-01T22:23:41Z")
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 \[1\]: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/4/c/4caef0fd2e701f277f09e51f3739bc0bebbebaba.png) * * * 1. as of this writing, I don't see a way to do a one-shot read e.g. via scripting; only subscribe via a binding in UI ---
**Author:** ![Steve\_Laubach](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/steve_laubach/32/60900_2.png) [@Steve\_Laubach](https://forum.inductiveautomation.com/u/Steve_Laubach)\ **Post date:** [April 2, 2025, 12:25pm UTC](https://forum.inductiveautomation.com/t/question-about-ignition-8-3-alarm-properties/104511/4 "2025-04-02T12:25:27Z")
Excellent. Thanks for the information. ---
**Author:** ![brandon1](https://avatars.discourse-cdn.com/v4/letter/b/ea666f/32.png) [@brandon1](https://forum.inductiveautomation.com/u/brandon1)\ **Post date:** [April 2, 2025, 12:56pm UTC](https://forum.inductiveautomation.com/t/question-about-ignition-8-3-alarm-properties/104511/5 "2025-04-02T12:56:56Z")
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. ---
**Author:** ![Steve\_Laubach](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/steve_laubach/32/60900_2.png) [@Steve\_Laubach](https://forum.inductiveautomation.com/u/Steve_Laubach)\ **Post date:** [April 2, 2025, 1:01pm UTC](https://forum.inductiveautomation.com/t/question-about-ignition-8-3-alarm-properties/104511/6 "2025-04-02T13:01:20Z")
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? ---
**Author:** ![brandon1](https://avatars.discourse-cdn.com/v4/letter/b/ea666f/32.png) [@brandon1](https://forum.inductiveautomation.com/u/brandon1)\ **Post date:** [April 2, 2025, 1:12pm UTC](https://forum.inductiveautomation.com/t/question-about-ignition-8-3-alarm-properties/104511/7 "2025-04-02T13:12:21Z")
> [@Steve\_Laubach](#): > > 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. I'm fairly sure @paul-griffith is saying you can bind directly to them: > [@paul-griffith](#): > > so that you can subscribe to them via a binding 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: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/9/d/9dcfd0736ec428806e713dcca44fd5165114f92b.png) > [@Steve\_Laubach](#): > > What use case do you have in mind where you want to use system.tag.readBlocking on them? 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? ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [April 2, 2025, 1:54pm UTC](https://forum.inductiveautomation.com/t/question-about-ignition-8-3-alarm-properties/104511/8 "2025-04-02T13:54:18Z")
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. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [April 2, 2025, 2:28pm UTC](https://forum.inductiveautomation.com/t/question-about-ignition-8-3-alarm-properties/104511/9 "2025-04-02T14:28:16Z")
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]` \[1\] * * * 1. some footnote