# "Virtual Alarms"? **URL:** \ **Category:** Ignition\ **Tags:** scripting\ **Created:** [March 23, 2022, 6:52pm UTC](https://forum.inductiveautomation.com/t/virtual-alarms/57555 "2022-03-23T18:52:16Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![kgamble](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kgamble/32/8019_2.png) [@kgamble](https://forum.inductiveautomation.com/u/kgamble)\ **Post date:** [March 23, 2022, 6:52pm UTC](https://forum.inductiveautomation.com/t/virtual-alarms/57555/1 "2022-03-23T18:52:16Z")
With the tag historian, you have the ability to store abstract time series data as a “Virtual Tag” (phrase taken from documentation) via using [system.tag.storeTagHistory](https://docs.inductiveautomation.com/display/DOC81/system.tag.storeTagHistory) directly I have recently started on a project, that will need to unify various datasets coming from MQTT, OPC, REST APIs, etc. into a common format, and using the tag historian sounds like a clean solution for that, since we can use the “virtual tag” concept to bulk insert abstract historical data, while also storing the realtime data normally. Is it possible to do anything similar to this with historical Alarms? I know that I could just use my script to create an instance of some universal alarm UDT, that fires the alarm immediately, deletes the tag, and then updates the record in the database table for the journal directly with the correct timestamps. However that feels kind of hacky. TLDR: Any way to bulk insert historical alarm data (Not coming from another ignition system, meaning no alarm Ids, etc.)? ---
**Author:** ![josborn](https://avatars.discourse-cdn.com/v4/letter/j/4bbf92/32.png) [@josborn](https://forum.inductiveautomation.com/u/josborn)\ **Post date:** [March 23, 2022, 8:02pm UTC](https://forum.inductiveautomation.com/t/virtual-alarms/57555/2 "2022-03-23T20:02:04Z")
> [@kgamble](#): > > However that feels kind of hacky. Yea, it does. Presumably you want to do this so you can view your alarm events that did not come from ignition in the Alarm Journal? You can write queries to insert into the alarm\_events and alarm\_event\_data tablles, but you would need to format your data accordingly. That's pretty sketchy also and may not work at all. ---
**Author:** ![kgamble](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kgamble/32/8019_2.png) [@kgamble](https://forum.inductiveautomation.com/u/kgamble)\ **Post date:** [March 23, 2022, 8:37pm UTC](https://forum.inductiveautomation.com/t/virtual-alarms/57555/3 "2022-03-23T20:37:12Z")
> [@josborn](#): > > Presumably you want to do this so you can view your alarm events that did not come from ignition in the Alarm Journal? Pretty much. With the "Virtual Tag" concept it allows me to use all the other built in functionality for visualization and data manipulation I am aiming for the same thing with alarms, I also considered direct inserts to that table, but if I need to use an internal alarm table it breaks that. ---
**Author:** ![josborn](https://avatars.discourse-cdn.com/v4/letter/j/4bbf92/32.png) [@josborn](https://forum.inductiveautomation.com/u/josborn)\ **Post date:** [March 23, 2022, 8:38pm UTC](https://forum.inductiveautomation.com/t/virtual-alarms/57555/4 "2022-03-23T20:38:23Z")
I just tried, ~~it didn’t break anything, but it also~~ didn’t show up in the Journal. It did break it, forget i even mentioned it, not a good idea. ---
**Author:** ![josborn](https://avatars.discourse-cdn.com/v4/letter/j/4bbf92/32.png) [@josborn](https://forum.inductiveautomation.com/u/josborn)\ **Post date:** [March 23, 2022, 9:34pm UTC](https://forum.inductiveautomation.com/t/virtual-alarms/57555/5 "2022-03-23T21:34:34Z")
What about storing your external alarm data in your own db tables with insert statements, then unioning that db table with your ignition alarm data? You could then use a table component to simulate the Journal. I know that’s not exactly what you are trying to do, but might be an alternative option. ---
**Author:** ![kgamble](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kgamble/32/8019_2.png) [@kgamble](https://forum.inductiveautomation.com/u/kgamble)\ **Post date:** [March 23, 2022, 9:40pm UTC](https://forum.inductiveautomation.com/t/virtual-alarms/57555/6 "2022-03-23T21:40:25Z")
> [@josborn](#): > > What about storing your external alarm data in your own db tables with insert statements, then unioning that db table with your ignition alarm data? Yeah this one, while still possible, avoids the goal of being able to use native components. I would lose the ability to use the native alarm journal component if I was to do this. It would also require adding in my own additional schema content, instead of just the historical data ---
**Author:** ![josborn](https://avatars.discourse-cdn.com/v4/letter/j/4bbf92/32.png) [@josborn](https://forum.inductiveautomation.com/u/josborn)\ **Post date:** [March 23, 2022, 9:45pm UTC](https://forum.inductiveautomation.com/t/virtual-alarms/57555/7 "2022-03-23T21:45:11Z")
All true, but i didn’t see any functions that would allow you add alarm events without actually having the alarm configured. You might try the temp tag option, that might work out, but it might also create a bunch of orphaned records in your database. Not 100% on that. ---
**Author:** ![kgamble](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kgamble/32/8019_2.png) [@kgamble](https://forum.inductiveautomation.com/u/kgamble)\ **Post date:** [March 23, 2022, 10:11pm UTC](https://forum.inductiveautomation.com/t/virtual-alarms/57555/8 "2022-03-23T22:11:29Z")
> [@josborn](#): > > You might try the temp tag option, that might work out, but it might also create a bunch of orphaned records in your database I have actually done this in the past, and while the records are "orphans", they do work similar to the "Virtual tag" concept mentioned above The only annoyance here is the overhead of creating and garbage collecting these tags, I think "system.alarm.storeAlarmHistory" would be a great function lol