Configuring Ignition 8.3 UA Device Global Settings

The engineer sees target-device settings under Connections > Devices, but no supported place to create, delete, or edit the shared BACnet local-device, hub, and certificate objects needed by every connection. That screen is telling you the configuration does not belong to an ordinary UA target-device form. The tag may be right; the binding is wrong: a connection-scoped editor cannot represent module-global configuration.

Which configuration model fits the driver?

Two configuration models are relevant. Standard UA Device SDK examples cover connection-specific target settings. The Ignition 8.3 BACnet implementation uses a different model: a custom React page calls module-defined backend routes, and the backend saves configuration in the resource system.

Use the custom module configuration model for Ignition 8.3. It matches the required global scope and provides one backend contract for the browser editor, an external application generator, and UA device runtime consumers. Keep target selection and remote-device properties in the normal connection configuration.

Why does the navigation sample stop too early?

The cited Web UI sample demonstrates navigation through getNavigationModel(), but it does not expose a documented hook for inserting an editor specifically at Connections > Devices > Settings. Treat that sample as a starting point for a module-owned page, not proof that a nested device-settings extension point exists.

The built-in BACnet page is fully custom. Its integration is architectural rather than a reusable BACnet editor hook: the module supplies the page, backend routes, payload definitions, validation, and persistence. Reproducing the architecture avoids coupling a third-party driver to an internal BACnet resource type or an undocumented navigation location.

The Ignition release line is a deciding input. The stated React-page and resource-system pattern applies to Ignition 8.3. The approach for Ignition 8.1 is different, so select the target release before committing the Web UI architecture. If the module must support both releases, isolate the configuration service from the version-specific user interface and package a separate UI adapter for each supported line.

How should the backend own shared settings?

Make the gateway-side module the authority for global configuration. The browser and external tools should exchange configuration through module-defined routes; they should not write driver runtime objects directly. The backend then validates the payload, persists the resource, and publishes a usable representation to active device instances.

Give each stored object a stable identifier so a device connection can reference it without duplicating the complete object. Keep display names separate from identifiers; renaming a visible item must not break the connection reference. Reject deletion while an active configuration still references the object, or provide an explicit reassignment workflow.

The runtime should consume configuration through a module service or repository abstraction shared with the route handlers. That boundary prevents UI payload details from leaking into protocol code. On a resource change, validate the new state first, replace the runtime snapshot atomically, and then restart or reconfigure only the affected connections according to the driver lifecycle.

How does the custom editor connect to the runtime?

1. Define separate resource schemas for the BACnet/IP local-device data and the BACnet/SC hub and certificate data. Include only fields the protocol runtime consumes, plus a stable identifier and operator-facing name.
2. Implement gateway-side create, read, update, and delete operations. Validate uniqueness, required references, address and port syntax where applicable, and any certificate-to-hub relationships before persistence.
3. Register module-owned backend routes that return editor payloads and accept validated changes. Use these routes as the integration contract for both the React page and the application generator.
4. Persist accepted configurations in the Ignition 8.3 resource system. Do not reuse BacnetIpLocalDeviceConfig from the built-in BACnet driver as the storage type for the new module.
5. Build the React list editor with create, edit, and delete actions. Surface validation failures returned by the backend beside the affected field rather than accepting a value that the runtime later rejects.
6. Add connection-level selectors that reference one stored local-device or secure-connect configuration. Keep those selectors in the ordinary UA device configuration because the selection belongs to that connection.
7. Resolve the selected identifier through the gateway service when constructing or starting the UA device runtime. Refuse startup with a clear diagnostic when the reference is missing, deleted, or invalid.

What should the OpenAPI boundary expose?

The BACnet-specific resource URL proves that the built-in driver exposes its own resource type; it does not provide a generic extension mechanism for a new local-device class. A new module needs its own backend contract. The application generator should call that contract rather than depend on the built-in BACnet namespace.

Expose the same operations required by the editor: list objects, read one object, create, update, and delete. Return stable identifiers after creation and structured validation errors after rejected writes. For certificate configuration, avoid returning secret material when an identifier, status, or metadata record is sufficient. Apply the gateway's authentication and authorization checks to every modifying route.

If discoverability through the platform's OpenAPI presentation is mandatory, verify the applicable Ignition 8.3 SDK mechanism for publishing module route metadata. Route registration and OpenAPI publication are separate concerns; a working backend route should not be treated as automatically documented.

How do you verify the complete path?

1. Create one BACnet/IP local-device resource through the custom page and confirm that it remains after a gateway restart.
2. Read the same object through the module route and compare its stable identifier and editable fields with the screen.
3. Select that identifier in a UA device connection, start the connection, and confirm through module diagnostics that the runtime resolved the intended resource.
4. Change one non-identity field through the application generator, reload the editor, and confirm that both clients show the same persisted value.
5. Attempt an invalid update and confirm that the backend rejects it without replacing the last valid runtime snapshot.
6. Attempt to delete a referenced object and confirm that the configured reference policy blocks deletion or forces explicit reassignment.
7. Repeat the path for BACnet/SC hub and certificate configuration, including a restart, missing-reference test, and authorization check.

FAQ