BM.4803.G Gateway Tag Change Event Scripts not working

Host Ubuntu 9.10 Server x64
Ignition Build 4803
Java 1.6.0u16

When i try the following code

alerts = system.alert.queryAlertStatus(activeAndUnacked=1,clearAndUnacked=1) for row in range(alerts.rowCount): system.alert.acknowledgeAlert(alerts.getValueAt(row,"System"),alerts.getValueAt(row,"Path"),alerts.getValueAt(row,"State Name"))

It nevers executes when I have it as a gateway tag change script. It works if it is a client tag change script.

Is there somethign that needs to be done differently to get it to execute in the gateway. I know its not triggering because I debugged with a “print 1” at the end of the code

Ok, so It looks like the event is firing, but I am getting this error

INFO | jvm 1 | 2010/04/03 10:23:59 | ERROR [TagChangeScriptManager ] [10:23:59,227]: Error executing tag change script: Alarm Acknowledge INFO | jvm 1 | 2010/04/03 10:23:59 | Traceback (innermost last): INFO | jvm 1 | 2010/04/03 10:23:59 | File "<TagChangeScript:Alarm Acknowledge>", line 3, in ? INFO | jvm 1 | 2010/04/03 10:23:59 | AttributeError: instance of 'com.inductiveautomation.ignition.common.script.ScriptPackage' has no attribute 'acknowledgeAlert' INFO | jvm 1 | 2010/04/03 10:23:59 | INFO | jvm 1 | 2010/04/03 10:23:59 | at org.python.core.Py.AttributeError(Py.java) INFO | jvm 1 | 2010/04/03 10:23:59 | at org.python.core.PyObject.__getattr__(PyObject.java) INFO | jvm 1 | 2010/04/03 10:23:59 | at org.python.core.PyObject.invoke(PyObject.java) INFO | jvm 1 | 2010/04/03 10:23:59 | at org.python.pycode._pyx1.f$0(<TagChangeScript:Alarm Acknowledge>:3) INFO | jvm 1 | 2010/04/03 10:23:59 | at org.python.pycode._pyx1.call_function(<TagChangeScript:Alarm Acknowledge>) INFO | jvm 1 | 2010/04/03 10:23:59 | at org.python.core.PyTableCode.call(PyTableCode.java) INFO | jvm 1 | 2010/04/03 10:23:59 | at org.python.core.PyCode.call(PyCode.java) INFO | jvm 1 | 2010/04/03 10:23:59 | at org.python.core.Py.runCode(Py.java) INFO | jvm 1 | 2010/04/03 10:23:59 | at com.inductiveautomation.ignition.common.script.ScriptManager.runCode(ScriptManager.java:391) INFO | jvm 1 | 2010/04/03 10:23:59 | at com.inductiveautomation.ignition.common.script.TagChangeScriptManager$TagChangeScriptHandler.tagChanged(TagChangeScriptManager.java:118) INFO | jvm 1 | 2010/04/03 10:23:59 | at com.inductiveautomation.ignition.gateway.project.ProjectLifecycle$ProjectDefaultTagManagerFacade$DefaultListenerUnWrapper.tagChanged(ProjectLifecycle.java:323) INFO | jvm 1 | 2010/04/03 10:23:59 | at com.inductiveautomation.ignition.gateway.sqltags.TagReference.notifyValueListeners(TagReference.java:158) INFO | jvm 1 | 2010/04/03 10:23:59 | at com.inductiveautomation.ignition.gateway.sqltags.TagReference$1.tagChanged(TagReference.java:46) INFO | jvm 1 | 2010/04/03 10:23:59 | at com.inductiveautomation.ignition.gateway.sqltags.AbstractGatewayTag.fireChangeEvent(AbstractGatewayTag.java:55) INFO | jvm 1 | 2010/04/03 10:23:59 | at com.inductiveautomation.ignition.gateway.sqltags.execution.tags.AbstractExecutableTag.setCurrentValue(AbstractExecutableTag.java:225) INFO | jvm 1 | 2010/04/03 10:23:59 | at com.inductiveautomation.ignition.gateway.sqltags.execution.tags.AbstractSubscribedNodeTag.internalEvaluate(AbstractSubscribedNodeTag.java:143) INFO | jvm 1 | 2010/04/03 10:23:59 | at com.inductiveautomation.ignition.gateway.sqltags.execution.tags.AbstractExecutableTag.evaluate(AbstractExecutableTag.java:274) INFO | jvm 1 | 2010/04/03 10:23:59 | at com.inductiveautomation.ignition.gateway.sqltags.model.BasicScanClassInstance.evaluateTags(BasicScanClassInstance.java:167) INFO | jvm 1 | 2010/04/03 10:23:59 | at com.inductiveautomation.ignition.gateway.sqltags.model.BasicScanClassInstance.runTagEvaluation(BasicScanClassInstance.java:125) INFO | jvm 1 | 2010/04/03 10:23:59 | at com.inductiveautomation.ignition.gateway.sqltags.model.SimpleExecutableScanClass.run(SimpleExecutableScanClass.java:584) INFO | jvm 1 | 2010/04/03 10:23:59 | at com.inductiveautomation.ignition.common.execution.impl.BasicExecutionEngine$TrackedTask.run(BasicExecutionEngine.java:433) INFO | jvm 1 | 2010/04/03 10:23:59 | at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) INFO | jvm 1 | 2010/04/03 10:23:59 | at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) INFO | jvm 1 | 2010/04/03 10:23:59 | at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) INFO | jvm 1 | 2010/04/03 10:23:59 | at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) INFO | jvm 1 | 2010/04/03 10:23:59 | at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181) INFO | jvm 1 | 2010/04/03 10:23:59 | at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205) INFO | jvm 1 | 2010/04/03 10:23:59 | at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) INFO | jvm 1 | 2010/04/03 10:23:59 | at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) INFO | jvm 1 | 2010/04/03 10:23:59 | at java.lang.Thread.run(Thread.java:619) INFO | jvm 1 | 2010/04/03 10:24:04 | ERROR [TagChangeScriptManager ] [10:24:04,247]: Error executing tag change script: Alarm Acknowledge INFO | jvm 1 | 2010/04/03 10:24:04 | Traceback (innermost last):

Looks like the gateway doesnt have access to the same functions. I added import system to the beginning of the script, and it still gave me the same error

Yes that is true - the acknowledgeAlert function is scoped to Client as stated in the User Manual. The reason is that acknowledgement has the notion of a user that acknowledged the alert. I’m willing to entertain the idea that you should be able to do this in the Gateway - what should the username be? Should you be able to simply specify one as a String?

Yeah Im good with that, just specify the user in the variables passed into the function?

And I learned about the scoping. Never thought to check that

yeah, so the two functions will have different signatures for Client and Gateway. Or maybe I’ll allow you to override the username in the Client’s call in case you’ve implemented your own custom notion of authentication/user managament on top of ours…

Sounds good