The flag definition has to do with how to deal with the low and high setpoints. It is an integer field where each bit represents a different flag. There are 7 possible flags right now:
bit 0 - low exclusive
bit 1 - low infinite
bit 2 - high exclusive
bit 3 - high infiinite
bit 4 - any change
bit 5 - low driven (by tag)
bit 6 - high driven (by tag)
So if you want the alert to be in alarm if the value is negative infinity and <= 10, the flag would be 2. If the 10 is replaced by a tag the flag would be 66. Hope this helps.
Added getAlarmStates and getTagAttribute to tag functions
Fixed module to allow key=value argument for gateway side scripts
Fixed NPE system.device.listDevices()
system.tag.getAlarmStates(String tagPath)states = system.tag.getAlarmStates("Path/To/Tag")
for state in states:
print state.name, state.severity, state.timeDeadband, state.timeDeadbandUnits, state.flags, state.loLimit, state.hiLimit, state.loTagPath, state.hiTagPath
system.tag.getAttribute(String tagPath, String attribute)print system.tag.getAttribute("Path/To/Tag", "AlertMode")The same attributes used for editTag and addTag apply.
Is there a trick for using the [color=#BF0000]w[/color][color=#BF4000]o[/color][color=#FFBF00]n[/color][color=#40FF40]d[/color][color=#008080]e[/color][color=#0080BF]r[/color][color=#0040BF]f[/color][color=#8000FF]u[/color][color=#8000BF]l [/color]addTag() function to make Client tags too?
Thanks!
Found a workaround. I can create my tags (Expression and SQL) programatically as normal tags first, then export them and change the tagType from a ‘1’ to a ‘2’, and then re-import them as Client tags. I’m sure there is a much better way; by using the proper tagType enumeration perhaps?
The new version is 1.6.0 and includes the following changes:
Added ability to override UDT instances in addTag and editTag.
Added recursion, filtering, and sorting to browseTags.
The function getAlarmStates now returns an array of TagAlarmDefinition.
Works with the new alarming configurations.
Fixed the bug where alarm states get removed when editing tag.
Added ability to get data type from the browseTags function.
Documentation is included in the module. Once you install the module you will see a “View Documentation” link to the right of the module.
Support will still be handled through this forum.
[quote=“Dustin.Schroll”]Found a workaround. I can create my tags (Expression and SQL) programatically as normal tags first, then export them and change the tagType from a ‘1’ to a ‘2’, and then re-import them as Client tags. I’m sure there is a much better way; by using the proper tagType enumeration perhaps?[/quote]You can’t make client tags with this module so that is best workaround.
[quote] Traceback (most recent call last):
File “event:actionPerformed”, line 6, in
com.inductiveautomation.ignition.client.gateway_interface.GatewayException: com.inductiveautomation.ignition.client.gateway_interface.GatewayException: TagFunctionsImpl.browseTags does not have the @KeywordArgs annotation.
caused by GatewayException: TagFunctionsImpl.browseTags does not have the @KeywordArgs annotation.
caused by IllegalArgumentException: TagFunctionsImpl.browseTags does not have the @KeywordArgs annotation.