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 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.)?
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.
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.
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.
1 Like
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.
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
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.
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