Page History

Depending on the number of alarm events in the system, this function can be fairly intensive and take a while to finish executing. Which can be problematic if the application is attempting to show the results on a component (such as using this function to retrieve a count of alarms). In these cases it's preferred to call this function in a gateway script of some sort (such as a timer script), and store the results in a tag, which can easily be accessed by a component binding. 

Each item in the resulting list is a combination of each alarm event for the same alarm: details for when the alarm became active, acknowledged, and cleared are combined into a single item. This differs from system.alarm.queryJournal() which splits these events into separate items.

# This example queries the state of all tags named "HiAlarm", and puts the results in a Vision table Component named "Table" (this assumes it's being run from a button on the same screen)
#   Note that this example is simple for the sake of brevity. Normally you'll want to use system.util.invokeAsynchronous to search for alarms in a separate thread, especially so if calling
#   this function from a component based script. See the next example for more information. 
 
table = event.source.parent.getComponent("Table")
 
results = system.alarm.queryStatus(source=["*HiAlarm*"])
table.data = results.getDataset()

# In this example we'll call system.alarm.queryStatus in a separate thread, and return the results to the data property on a Vision Table component. Similar to the example above. 
#   What makes this example different is that it offers better performance when calling from a Vision component. Depending on the number of alarm events in the system, queryStatus 
#   may take a significant amount of time to finish, which would lock up a Vision Client while the script is running in the GUI thread. Thus this example will use
#   system.util.invokeAsynchronous to call queryStatus in a separate thread, and then system.util.invokeLater make any changes to our components. 


# Define a function that will retrieve alarm data in a separate thread
def getAlarms():
	# Call queryStatus to retrieve the alarm data we're looking for, and store the results in a variable. 
	#   In this case, we're looking for alarm events that contain the word "Sensor" in the source path.
	results = system.alarm.queryStatus(source=["*Sensor*"])	
	
	# From this same script, define a separate function that will later interact with the
	#    GUI, allowing us to move our alarm data over to a component
	# We're also using the getDataset() function on the object returned by queryStatus, 
	#   since that will provide a dataset that our table component will expect. 
	def setTheTable(alarms = results.getDataset()):
		
		# Replace the property reference below with a path leading to whichever property
		#    you want to move the alarm data to. 
		event.source.parent.getComponent("Table").data = alarms
	
	# The last thing we'll do in the separate thread is call invokeLater
	#   which will let our setTheTable function run in the GUI thread
	system.util.invokeLater(setTheTable)

		
# Call the getAlarms function in a separate thread, which starts the whole process		
system.util.invokeAsynchronous(getAlarms)

# The any_properties parameter allows you to filter the results for specific properties. This is useful when searching for alarms that contain associated data.

# Build a List of Tuples that represent the properties to search for. In this case, if our alarms have an Associated Data named 'Group', we can use 
# the following to search for potential values
props = [("Group", "=", "value1"), ("Group", "=", "value2")]
state = ["ActiveUnacked", "ActiveAcked"]

alarms = system.alarm.queryStatus(any_properties = props, state = state)

# Here we're printing out the number of alarms that meet our criteria. We could replace this and further examine each individual alarm in a for-loop instead. 
print len(alarms)