Resolving system.opc.readValue Nulls in Version 8.0

After applying the 8.0.5 nightly build uploaded on 9/3, synchronous system.opc.readValue calls can again retrieve device diagnostic values that returned null in 8.0. First confirm the script targets the correct OPC server connection, particularly after a fresh 8.0 installation, and then distinguish this defect from an addressing or communications failure.

Which path does the diagnostic read follow?

Follow the request from the script to the value. The script calls system.opc.getServers(), selects each returned OPC server connection, browses the Devices node, builds a diagnostic item path from the device display name, and submits a synchronous read. The selected connection then carries the request to the device diagnostics branch.

Hop	Input	Successful observation	Failure indication
Script to OPC subsystem	system.opc.getServers()	Expected server connection appears	Missing or unexpected connection name
Server connection to namespace	Devices	system.opc.browseServer returns devices	No device entries
Device to diagnostic node	_Meta:[Diagnostics]	Quick Client displays the target value	Item absent or incorrectly addressed
Synchronous scripting read	system.opc.readValue	Value returned	getValue() returns null

The reported failure occurs at the final hop: server discovery and device browsing work, and the Gateway Quick Client can subscribe to the diagnostic item, but the scripting read returns null. Confirm that sequence before changing device or network settings.

Does the script select the correct OPC server connection?

Start with the connection identity. On a fresh 8.0 installation, the name of the connection to the built-in OPC UA server changed. A script that relies on a name retained from 7.10 can therefore select the wrong connection or fail to find the intended one, even though the device configuration itself is valid.

1. Run system.opc.getServers() in the same execution scope as the failing script.
2. Record the returned connection names exactly, including capitalization and spacing.
3. Compare each returned name with the connection visible in the Gateway and with the first argument passed to system.opc.browseServer and system.opc.readValue.
4. Use the returned connection identifier rather than a name copied from a 7.10 installation.

Installation case	Connection-name decision	Proof
Existing 7.10 system	Use the name actually returned at runtime	The expected device appears below Devices
Fresh 8.0 installation	Account for the changed built-in OPC UA connection name	Browse and Quick Client target the same connection

The check passes when the chosen connection browses the same device and diagnostic namespace shown by the Gateway Quick Client.

Are the device and diagnostic item paths exact?

The script constructs each item address by appending a fixed diagnostics suffix to device.getDisplayName(). That produces three requested paths:

path + "_Meta:[Diagnostics]/Connection State"
path + "_Meta:[Diagnostics]/Port"
path + "_Meta:[Diagnostics]/Hostname"

A successful browse of Devices proves that the server connection exposes devices; it does not independently prove that a display name is the correct prefix for every readable item. Validate one device at a time. Copy the device name returned by the browse, construct each complete path, and locate that same item in the Gateway Quick Client.

Requested value	Path suffix	Commissioning check
Connection state	_Meta:[Diagnostics]/Connection State	Quick Client shows the current state
Port	_Meta:[Diagnostics]/Port	Quick Client shows the configured diagnostic value
Hostname	_Meta:[Diagnostics]/Hostname	Quick Client shows the configured diagnostic value

Do not use the diagnostic hostname or port values to prove the path before they can be read. Use the configured connection and the Quick Client namespace as the independent reference. The check passes when all three constructed paths resolve under the same device.

Does subscription work while a direct read returns null?

Read and subscription are different request patterns. A direct read asks for a value once and returns a result to the script. A subscription creates monitored delivery and reports values through the Quick Client. Layer one comes first: if neither mode works, inspect the server connection, device connection, hostname, port, and item address. If subscription works but only the direct scripting read returns null, the physical path and namespace are already carrying data.

Test	Timing model	Observed result	Decision
Gateway Quick Client	Subscribed updates	Diagnostic value visible	Connection and target item are operational
system.opc.readValue	One synchronous request	Null from getValue()	Matches the 8.0 diagnostic-tag read defect after name and path checks pass

Test the same complete item path through both mechanisms. Do not compare a subscribed device value with a direct read of a different diagnostics path. The defect is isolated when the identical diagnostics item subscribes successfully but returns null from the synchronous call.

Which software change corrects BUG-14837?

BUG-14837 covers system.opc.readValue returning null for diagnostics tags in 8.0, despite those tags being visible through a subscription. The script worked in 7.10. The correction was reported in the 8.0.5 nightly build uploaded on 9/3.

1. Record the running platform version before changing software.
2. Confirm the failure matches the defect boundary: diagnostics tags, synchronous system.opc.readValue, null values, and a working Quick Client subscription.
3. Move to the corrected 8.0.5 nightly build identified above using the site’s normal upgrade and rollback procedure.
4. Restart or complete any upgrade actions requested by the platform.
5. Confirm the running version from the Gateway rather than relying on the installer filename.

Do not treat a connection-name mismatch as this software defect. Correct the connection selection first. Likewise, do not change device hostname or port merely because their diagnostic reads are null; those values are the outputs being requested, not proof that the underlying settings are wrong. The check passes when the Gateway reports the corrected build and the same item remains subscribable.

How do you verify the complete script path?

Run discovery, browse, path construction, and direct reads together so the test exercises the production data path. Delay string conversion until after inspecting the returned values; converting immediately can hide the distinction between an actual null and printable text.

OPCServers = system.opc.getServers()
for OPCServer in OPCServers:
    devices = system.opc.browseServer(OPCServer, "Devices")
    for device in devices:
        path = device.getDisplayName()
        connectionState = system.opc.readValue(
            OPCServer,
            path + "_Meta:[Diagnostics]/Connection State"
        ).getValue()
        port = system.opc.readValue(
            OPCServer,
            path + "_Meta:[Diagnostics]/Port"
        ).getValue()
        hostname = system.opc.readValue(
            OPCServer,
            path + "_Meta:[Diagnostics]/Hostname"
        ).getValue()

1. Confirm OPCServers contains the intended connection.
2. Confirm browsing Devices returns the expected device.
3. Confirm the three complete paths match Quick Client items.
4. Confirm Quick Client subscriptions still display values.
5. Run the direct reads and verify that connection state, port, and hostname are no longer null.

The end-to-end check passes only when discovery, browse, subscription, and all three synchronous reads succeed against the same server connection and device.

FAQ