# Gateway events and tag browser initialChange

**URL:** <https://forum.inductiveautomation.com/t/gateway-events-and-tag-browser-initialchange/115991>\
**Category:** Ignition\
**Created:** [June 15, 2026, 8:43pm UTC](https://forum.inductiveautomation.com/t/gateway-events-and-tag-browser-initialchange/115991 "2026-06-15T20:43:01Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Andrew\_Lin](https://avatars.discourse-cdn.com/v4/letter/a/3be4f8/32.png) [@Andrew\_Lin](https://forum.inductiveautomation.com/u/Andrew_Lin)\
**Post date:** [June 15, 2026, 8:43pm UTC](https://forum.inductiveautomation.com/t/gateway-events-and-tag-browser-initialchange/115991/1 "2026-06-15T20:43:01Z")

</div>

I have a couple hundred of on change scripts within my tag browser and a couple hundred (some overlapping with tag browser but different scripts) on my gateway events, these scripts only fire off when the tag changes. However, I am noticing that whenever we do redundancy testing and master node gets restarted, when master becomes active again the first value change does not execute but the second onwards executes.

On my gateway event scripts I have

> `if not initialChange and event.currentValue.value:`

On tag browser scripts I have

> `if not initialChange and currentValue.value:`

this prevents scripts from firing right away when we switch between master and backup nodes.

however there are times when my scripts still fire off because the tags goes from NULL to True so I updated to become

> `if not initialChange and event.previousValue and event.currentValue.value:`

> `if not initialChange and previousValue and currentValue.value:`

now whenever we switch from backup to master or restart master the very first tag change the script does not execute but the second time it changes it does.

I cant figure out how to get the redundancy to work correctly, what I am trying to do is whenever we switch to a different node regardless of restarts/which node is active, the script does not fire only until the tag changes values.

So far, the only thing I can think of which might work is to remove any tag browser scripts and move them all to the gateway, then create a new 'lastknownvalue' tag for each tag that requires an onchange and store the last value to this tag and when my scripts fires off regardless on restarts/saves/node switches it will check the 'lastknownvalue' tag value and compare with the current tag

> `tag changes:`  
> ` a = get value of lastknowvalue tag`  
> ` if currentValue.value and currentValue.value != a:`  
> ` run code`  
> ` if currentValue.value != a:`  
> ` lastknowvalue tag = currentValue.value`

would this be a working case and is there any other cases that might work. Im running on version 8.3

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [June 15, 2026, 9:39pm UTC](https://forum.inductiveautomation.com/t/gateway-events-and-tag-browser-initialchange/115991/2 "2026-06-15T21:39:12Z")

</div>

There's two problems here that you are struggling with:

- The `initialChange` flag does **NOT** mean you can ignore the current value. It means the tag subsystem **does not know** what the previous value might be. The current value **might** be a change, and **you** are responsible for coding what you need to figure it out, include some external storage for the most recently processed value. **IF** it matters. (In many application, it doesn't matter.)

- Redundancy fail-over is **lossy**. A synchronized pair will **try** to keep tag current values synchronized (memory tags), but the most recent might be missed if a gateway crashes hard. Ergo, you need **external** knowledge, outside the pair of gateways, to hold last values. This would typically be a high-availability database cluster. You would use the `initialChange` flag to look in your DB or historian to find the most recent value needed.

Further:

- Tag change events defined on the tag are **not safe** for potentially time-consuming `system.*` calls, particularly anything to do with databases, network APIs, direct OPC calls, and blocking writes to tags. You can easily stall all tag event processing with any network hiccups.

- Ignition's historian can be configured to hold activity on the backup gateway pending restoration of the master. This eventual correctness can be relied on for any reporting and other tasks requiring analysis of past events. You should try to avoid using tag events to drive analysis on the fly, unless the analysis is self-correcting as more data arrives.