# Tag Change Scripts and initialChange After Frequent Gateway Reboots **URL:** \ **Category:** Ignition\ **Tags:** scripting\ **Created:** [March 30, 2026, 4:46pm UTC](https://forum.inductiveautomation.com/t/tag-change-scripts-and-initialchange-after-frequent-gateway-reboots/114775 "2026-03-30T16:46:12Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Dmitrii\_Lysenkov](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dmitrii_lysenkov/32/53728_2.png) [@Dmitrii\_Lysenkov](https://forum.inductiveautomation.com/u/Dmitrii_Lysenkov)\ **Post date:** [March 30, 2026, 4:46pm UTC](https://forum.inductiveautomation.com/t/tag-change-scripts-and-initialchange-after-frequent-gateway-reboots/114775/1 "2026-03-30T16:46:12Z")
Hi all, I have a small issue related to `initialChange`. Using `if not initialChange:` works perfectly in normal operation. However, our IT department reboots the Ignition VM about every two weeks for Windows updates or other maintenance. Unfortunately, this is company policy, so I cannot keep the server on a separate VM that they do not touch. After every reboot, the first execution of every Tag Change Script is considered `initialChange == True`, so any script using `if not initialChange:` will not run on that **first real value change**. Right now I see two possible solutions: 1. Manually trigger all required scripts after startup. 2. Add a Gateway Startup Script that performs a first "dry run" or initializes the tags so the next real change is not treated as the first execution. The first option is not really practical because this is a large plant with thousands of Tag Change Scripts. The second option works, but before I implement it everywhere I wanted to ask if there is a better or more standard approach. **Has anyone dealt with this issue in a large system?** Is there a recommended pattern for handling `initialChange` after planned gateway/VM restarts? For example, would it be better to: - Keep using `not initialChange` and add startup initialization logic? - Use `previousValue.value != newValue.value` instead? - Store a separate "GatewayReady" memory tag and ignore `initialChange` completely once the gateway is fully up? - Or something else? I only started noticing this because IT recently began rebooting the VM every two weeks. Before that, when it only happened once a year, it was not really a problem. Thanks! ---
**Author:** ![Aiasa21](https://avatars.discourse-cdn.com/v4/letter/a/aeb1de/32.png) [@Aiasa21](https://forum.inductiveautomation.com/u/Aiasa21)\ **Post date:** [March 31, 2026, 5:10am UTC](https://forum.inductiveautomation.com/t/tag-change-scripts-and-initialchange-after-frequent-gateway-reboots/114775/2 "2026-03-31T05:10:46Z")
> [@Dmitrii\_Lysenkov](#): > > After every reboot, the first execution of every Tag Change Script is considered `initialChange == True`, so any script using `if not initialChange:` will not run on that **first real value change**. Just an idea, have you tried for example with: ```python if previousValue.value != newValue.value and currentValue.value: ``` in this case you should trigger with a new valid value. ---
**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:** [March 31, 2026, 6:19am UTC](https://forum.inductiveautomation.com/t/tag-change-scripts-and-initialchange-after-frequent-gateway-reboots/114775/3 "2026-03-31T06:19:18Z")
You are misunderstanding `initialChange`. It means Ignition **does not know** if the value supplied is an actual change. (It cannot know on startup.) An application that depends on catching all value changes must include code to retrieve prior information from your database or historian when `initialChange` is `True`. And then decide on its own if previousValue != currentValue. There is no magic wand. Also, it is, in my not-so-humble opinion, engineering malpractice to use Windows in a critical plant-floor application. IT breaking your system every so often for forced updates is ridiculous. ---
**Author:** ![nminchin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/nminchin/32/6911_2.png) [@nminchin](https://forum.inductiveautomation.com/u/nminchin)\ **Post date:** [March 31, 2026, 7:08am UTC](https://forum.inductiveautomation.com/t/tag-change-scripts-and-initialchange-after-frequent-gateway-reboots/114775/4 "2026-03-31T07:08:39Z")
> [@Aiasa21](#): > > `previousValue.value` `previousValue` is `None` in some instances and therefore has no `value` prop so this will cause an exception ---
**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:** [March 31, 2026, 10:44am UTC](https://forum.inductiveautomation.com/t/tag-change-scripts-and-initialchange-after-frequent-gateway-reboots/114775/5 "2026-03-31T10:44:04Z")
It is `None` when `initialChange` is true. ---
**Author:** ![Dmitrii\_Lysenkov](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dmitrii_lysenkov/32/53728_2.png) [@Dmitrii\_Lysenkov](https://forum.inductiveautomation.com/u/Dmitrii_Lysenkov)\ **Post date:** [March 31, 2026, 4:00pm UTC](https://forum.inductiveautomation.com/t/tag-change-scripts-and-initialchange-after-frequent-gateway-reboots/114775/6 "2026-03-31T16:00:11Z")
> [@pturmel](#): > > You are misunderstanding `initialChange`. It means Ignition **does not know** if the value supplied is an actual change. (It cannot know on startup.) An application that depends on catching all value changes must include code to retrieve prior information from your database or historian when `initialChange` is `True`. And then decide on its own if previousValue != currentValue. > > There is no magic wand. > > Also, it is, in my not-so-humble opinion, engineering malpractice to use Windows in a critical plant-floor application. IT breaking your system every so often for forced updates is ridiculous. In a 100,000-employee corporation, there are some battles you just can’t win. One of them is stopping IT from pushing “security upgrades” every two weeks. Unfortunately, Automation & Controls already lost that one. And yes, you are right — my idea of forcing execution with a test tag would not actually solve the issue, because it would only reset that test tag. That was my mistake. So the problem remains the same: after every reboot, the first tag change is always received with `initialChange == True`. I tested this several times on my local machine with a very simple script, and the behavior was consistent every time: the first change after restart is always treated as an initial change. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/d/3/d3b6323d62228ff3de211751a3682212c1da18e8.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/3/3/33bbc6f916de30b8a39eadb507f51698ead41df7.png) ---
**Author:** ![Dmitrii\_Lysenkov](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dmitrii_lysenkov/32/53728_2.png) [@Dmitrii\_Lysenkov](https://forum.inductiveautomation.com/u/Dmitrii_Lysenkov)\ **Post date:** [March 31, 2026, 5:32pm UTC](https://forum.inductiveautomation.com/t/tag-change-scripts-and-initialchange-after-frequent-gateway-reboots/114775/7 "2026-03-31T17:32:59Z")
Well, I finally replaced `not initialChange` logic with a check against `previousValue`, and that works much better for me. After a gateway reboot, the first real tag change now runs the script correctly, while after a project/script update it does not run unnecessarily. In my case, checking `previousValue == None` ended up being a more reliable solution than relying on `initialChange`. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/0/0/00a56dd1a0829460cd69a321acaf95f96a88963d.png)