# Device Config Update Live Edit **URL:** \ **Category:** Ignition 8.3 Early Access\ **Tags:** opcua, ignition83\ **Created:** [August 1, 2025, 8:04pm UTC](https://forum.inductiveautomation.com/t/device-config-update-live-edit/109272 "2025-08-01T20:04:40Z")\ **Posts on this page:** 12\ **Page:** 1
**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:** [August 1, 2025, 8:04pm UTC](https://forum.inductiveautomation.com/t/device-config-update-live-edit/109272/1 "2025-08-01T20:04:40Z")
I've been squashing designer RPC bugs in my EtherNet/IP module and noticed a catch-22: I can't "Save Running XML" without triggering a device restart. In v8.1, this config was gzipped and written to an auxiliary internal DB table that the OPC server doesn't monitor. In v8.3, I've moved this XML to the resource system as another file alongside the normal `config.json` as `Config.xml`. I rewrote my "Save Running XML" function to end with this: ```python Resource asLocal = devContext.getDecodedResource().resource(); ResourceBuilder builder = asLocal.toBuilder(); builder.setResourceCollectionName(asLocal.getDefiningCollectionName()); Resource asDefined = builder.build(); builder = asDefined.toBuilder(); builder.putData("Config.xml", baos.toByteArray()); Resource modified = builder.build(); try { devContext.getGatewayContext().getConfigurationManager().push( List.of(ChangeOperation.newModifyOp(modified, asDefined.getResourceSignature()))); } catch (PushException e) { iLogger.warn("Unable to save Config.xml", e); } ``` This does put the new snapshot into the resource, but immediately restarts the device itself. Which was already running the changes--that's the point of the live editing, it doesn't persist until deliberately saved. Restart isn't instant, so this will disrupt fast data collection processes. ☹ However, I **do** want the new config propagated to the peer in a redundant pair... Ideas/options? ---
**Author:** ![Steve\_Laubach](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/steve_laubach/32/60900_2.png) [@Steve\_Laubach](https://forum.inductiveautomation.com/u/Steve_Laubach)\ **Post date:** [August 1, 2025, 8:09pm UTC](https://forum.inductiveautomation.com/t/device-config-update-live-edit/109272/2 "2025-08-01T20:09:32Z")
Sounds consistent with how the custom SVG libraries are now working. This line in particular... 1. Restart the gateway (or POST the `/data/api/v1/scan/config` endpoint) to pick up the changed resource. > [@Custom Icon Library in 8.3](https://forum.inductiveautomation.com/t/custom-icon-library-in-8-3/109259/2): > > Okay, here's the current steps. Navigate to your install directory, and in the /data/config/resources/core/ folder, create a new folder com.inductiveautomation.perspective/ (if it doesn't already exist). Within that folder create an icons/ folder. Within that folder create a \/ folder. Within that folder, create: The spritesheet of your SVG, at whatever arbitrary filename you want, e.g. icons.svg. A config.json file that contains a single entry, svgFileName, that co… Edit: Although, updating it with a post probably will still trigger the restart you're trying to avoid. ---
**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:** [August 1, 2025, 8:14pm UTC](https://forum.inductiveautomation.com/t/device-config-update-live-edit/109272/3 "2025-08-01T20:14:01Z")
No, when push a list of changes to the config manager, no scanning is required. If I wrote directly to `Config.xml` in the resource folder, that might produce the effect I want on the master system, but I don't think it will propagate without scanning. And any random later scan for other purposes would restart the live device at that point. I suppose I could make an entirely separate resource tree for this, under my own module ID (devices are under the OPC server ID). Blegh. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [August 1, 2025, 8:17pm UTC](https://forum.inductiveautomation.com/t/device-config-update-live-edit/109272/4 "2025-08-01T20:17:00Z")
> [@pturmel](#): > > I suppose I could make an entirely separate resource tree for this, under my own module ID (devices are under the OPC server ID). Blegh. This is in line with my quick/dirty suggestion: use `SystemManager::getModuleConfigDir` for these files. ---
**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:** [August 1, 2025, 8:21pm UTC](https://forum.inductiveautomation.com/t/device-config-update-live-edit/109272/5 "2025-08-01T20:21:07Z")
> [@Kevin.Herron](#): > > This is in line with Yeah. In either case, I would have to maintain a "foreign key" from devices into the module config. How stable is the resource UUID? ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [August 1, 2025, 8:22pm UTC](https://forum.inductiveautomation.com/t/device-config-update-live-edit/109272/6 "2025-08-01T20:22:52Z")
Hmm, not sure what UUID you're talking about. ---
**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:** [August 1, 2025, 8:23pm UTC](https://forum.inductiveautomation.com/t/device-config-update-live-edit/109272/7 "2025-08-01T20:23:09Z")
In resource.json. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [August 1, 2025, 8:25pm UTC](https://forum.inductiveautomation.com/t/device-config-update-live-edit/109272/8 "2025-08-01T20:25:35Z")
Oh jeez... that's not even a part of the _core_ resource system, it's added by `NamedResourceHandler::create`. It does seem stable though... and looks to be used by a couple other things as a FK. ~~Might have been its intent.~~ edit: no I remember now, the intent had something to do with assisting the handlers with renames. ---
**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:** [August 1, 2025, 8:28pm UTC](https://forum.inductiveautomation.com/t/device-config-update-live-edit/109272/9 "2025-08-01T20:28:47Z")
Makes sense. Renames is why I wouldn't want to use the device name. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [August 1, 2025, 8:45pm UTC](https://forum.inductiveautomation.com/t/device-config-update-live-edit/109272/10 "2025-08-01T20:45:42Z")
Yeah, the UUID is added to all "named" resources (as distinct from singletons) by various layers of the system. I wouldn't **assume** it's always present, but the intention is for it to be stable once created, precisely to handle renames. ---
**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:** [August 1, 2025, 8:59pm UTC](https://forum.inductiveautomation.com/t/device-config-update-live-edit/109272/11 "2025-08-01T20:59:33Z")
OK. My plan (not for today): - Divert the write of `Config.xml` when live to the module config dir as `${uuid}.xml`, unconditionally overwriting anything there, creating folders as needed. - Check during device startup if there is a resource uuid, and if there is a module config dir, and it holds an XML file for that uuid. If so: 1. Load the alternate file as the config for the device, and 2. Schedule an independent runnable for a few millis in the future to: - Push the new config into the resource collection, and - Delete the alternate file. That will cause a quick extra restart when a live config is present. My future WebUI will need to unconditionally delete an alternate when directly importing a new `Config.xml`. ---
**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:** [November 17, 2025, 9:39pm UTC](https://forum.inductiveautomation.com/t/device-config-update-live-edit/109272/12 "2025-11-17T21:39:46Z")
I decided to bail out on that plan. The React Config UI now out in beta simply writes to the resource and lets the device restart naturally.