# Perspective Alarming work around **URL:** \ **Category:** Ignition Early Access\ **Created:** [January 8, 2019, 3:45pm UTC](https://forum.inductiveautomation.com/t/perspective-alarming-work-around/21742 "2019-01-08T15:45:41Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![mattn1](https://avatars.discourse-cdn.com/v4/letter/m/54ee81/32.png) [@mattn1](https://forum.inductiveautomation.com/u/mattn1)\ **Post date:** [January 8, 2019, 3:45pm UTC](https://forum.inductiveautomation.com/t/perspective-alarming-work-around/21742/1 "2019-01-08T15:45:41Z")
With the lack of Alarm components in perspective I was wondering what others have used for showing alarm status/events. ---
**Author:** ![ggross](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ggross/32/12668_2.png) [@ggross](https://forum.inductiveautomation.com/u/ggross)\ **Post date:** [January 14, 2019, 9:38pm UTC](https://forum.inductiveautomation.com/t/perspective-alarming-work-around/21742/2 "2019-01-14T21:38:16Z")
Until we are able to add Alarm Components, the only way I can think of to do this would be to enable Alarm Journaling and use a query to populate a table component. While this wouldn’t allow you to act on alarms, it would allow you to see the information. To answer the obvious follow up question of when Alarming components will be added. They are high on the list of components to be added, but there are a few larger items that need to be finished that are a higher priority and a timeframe for when these will appear isn’t clear yet. Garth ---
**Author:** ![ASF](https://avatars.discourse-cdn.com/v4/letter/a/c4cdca/32.png) [@ASF](https://forum.inductiveautomation.com/u/ASF)\ **Post date:** [April 11, 2019, 6:43am UTC](https://forum.inductiveautomation.com/t/perspective-alarming-work-around/21742/3 "2019-04-11T06:43:19Z")
Thought I’d best tack onto this post rather than start my own, as the title is exactly what I’d be creating already 🙂 I’m just trying to build a very simple alarm banner - literally just a list of currently active alarms, with the times they were activated. I don’t need to know if/when they were acknowledged/cleared/etc - I just need a very quick heads up of what’s currently wrong. I’ve built a named query that can return exactly that from the alarm\_events database: ```auto select eventtime, displaypath from alarm_events AE where eventtime = (select max(eventtime) from alarm_events TS where AE.source = TS.source) and eventtype != 1 and source not like 'evt:%' order by AE.priority, eventtime desc ``` Basically, I’m leveraging the fact that the `source` column is unique for all individual alarms, then picking only the most recent event for each `source` where the `eventtype` is anything other than 1 (cleared), filtering out system events, and then ordering by priority and then most recent. Seems to work OK, but having had a quick look at the online demo perspective apps, they seem to have some more advanced alarm functionality in them. Is this functionality achieved by just using a similar (more complex) approach to my example above, or are there some better ways of displaying alarms now that I haven’t discovered yet? Again, I can live without all the niceties of acknowledged/cleared/active statuses, tracking of who did what, and so on - I just want to be able to display currently active alarms that require intervention to clear. ---
**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 11, 2019, 1:22pm UTC](https://forum.inductiveautomation.com/t/perspective-alarming-work-around/21742/4 "2019-04-11T13:22:44Z")
You can look for cleared alarms in a subquery and filter those out if that’s what you’re trying to do. You can go a little crazy with it but your limitation as far as I’ve seen is the source field. So far, the methodology that has worked best for me is to derive my alarms from UDTs that consistently put specific things in the types of alarms which I then use as groups. Then my query can grab specific types of alarms (ex. compliance alarms). The queries can get pretty complicated because the data is structured to be displayed by a client side alarm logger but it can be done with subqueries. Alternatively, you can process the data client side and read it in like an alarm logger. Also, it can get a little tricky querying the data from the partition tables. I’ve been doing that with dynamic SQL but there might be a better way to do that. A better solution hasn’t dawned on me yet. ---
**Author:** ![malone46844](https://avatars.discourse-cdn.com/v4/letter/m/b9bd4f/32.png) [@malone46844](https://forum.inductiveautomation.com/u/malone46844)\ **Post date:** [April 12, 2019, 2:58pm UTC](https://forum.inductiveautomation.com/t/perspective-alarming-work-around/21742/5 "2019-04-12T14:58:41Z")
This is what I use for PostgreSQL in a named query. You need the crosstab extension installed and probably need TIMESTAMP instead of TIMESTAMPTZ. Change {FILTER}, {TS1} and {TS2} to suit your needs. ```auto SELECT eventid AS "Event ID", displaypath AS "Display Path", substring(source, ':/tag:(.*):/alm.*') AS "Tag Name", substring(source, ':/alm:(.*)') AS "Alarm Name", time_active AS "Active Time", time_clear AS "Clear Time", time_clear - time_active AS "Duration" FROM crosstab( $$ SELECT eventid, source, displaypath, eventtype, eventtime FROM alarm_events WHERE displaypath LIKE '%{FILTER}%' AND eventtype IN (0,1) AND displaypath NOT LIKE '%evt:%' AND eventtime >= TIMESTAMPTZ '{TS1}' AND eventtime < TIMESTAMPTZ '{TS2}' ORDER BY 1 $$, $$ VALUES (0::integer), (1::integer) $$ ) AS eventtable ( eventid TEXT, source TEXT, displaypath TEXT, time_active TIMESTAMPTZ, time_clear TIMESTAMPTZ ) WHERE time_active IS NOT NULL ORDER BY time_active DESC ``` Cheers.