Skip to content

MTConnectStreams.schemaVersion / MTConnectDevices.schemaVersion hardcoded to "2.0" in JSON-cppagent-mqtt formatter #128

@ottobolyos

Description

@ottobolyos

Summary

Under the JSON-CPPAGENT-MQTT document format, the schemaVersion property at the top of every MTConnectStreams and MTConnectDevices envelope is a hardcoded string constant "2.0", not derived from the agent's configured DefaultVersion. Setting defaultVersion: 2.5 (or any other value) in agent.config.yaml has no effect on this field — the emitted value is always "2.0". The closely-related Header.version slot is also unaffected; it independently reports the library assembly version (see the companion issue #127).

Environment

  • MTConnect.NET-Applications-Agents + MTConnect.NET-JSON-cppagent at v6.9.0 (official image trakhound/mtconnect.net-agent:6.9.0, published 2025-10-16 — binary-equivalent to the v6.9.0.2 release).
  • Broker: eclipse-mosquitto:2.0.22.
  • Format ID: JSON-CPPAGENT-MQTT (same defect affects JSON-CPPAGENT via the same shared writer).

Reproduction — verified

Run the stock mqtt-relay module against any device model. Try setting defaultVersion to any valid MTConnect release in the agent config:

# applications/MTConnect-Agent/appsettings.yaml
defaultVersion: 2.5           # attempted override — no effect
# or:
defaultVersion: "2.5"         # quoted — no effect either
# or:
# (key omitted entirely)      # same result

modules:
- mqtt-relay:
    server: localhost
    port: 1883
    documentFormat: JSON-CPPAGENT-MQTT
    topicPrefix: MTConnect/Document
    topicStructure: Document

Subscribe to the Current topic and inspect schemaVersion:

mosquitto_sub -h localhost -t 'MTConnect/Document/Current/<uuid>' -C 1 | jq '.MTConnectStreams.schemaVersion'

Observed (regardless of defaultVersion setting)

"2.0"

Expected (per cppagent reference under JSON v2)

"2.7"

…or whichever MTConnect release the agent is actually configured to serve.

Root cause — library source

libraries/MTConnect.NET-JSON-cppagent/Streams/JsonMTConnectStreams.cs lines 26-35:

public JsonMTConnectStreams() 
{
    JsonVersion = 2;
    SchemaVersion = "2.0";             // ← hardcoded
}

public JsonMTConnectStreams(IStreamsResponseOutputDocument streamsDocument)
{
    JsonVersion = 2;
    SchemaVersion = "2.0";             // ← hardcoded (again)
    ...
}

Same pattern in libraries/MTConnect.NET-JSON-cppagent/Devices/JsonMTConnectDevices.cs (lines 26-35): hardcoded SchemaVersion = "2.0" on both the default constructor and the IDevicesResponseDocument-accepting constructor.

The corresponding JsonMTConnectAssets.cs does not expose SchemaVersion at all (it is not emitted in the Assets envelope).

Meanwhile, libraries/MTConnect.NET-Common/Configurations/AgentConfiguration.cs line 133 correctly initialises DefaultVersion = MTConnectVersions.Max (2.5), and line 72-86 exposes the YAML/JSON alias defaultVersion. The configured value is never threaded into JsonMTConnectStreams / JsonMTConnectDevices.

Impact

  • The field is a lie. The JSON schemaVersion property claims "MTConnect schema version 2.0" regardless of what the agent is actually configured to serve (v2.1, v2.5, etc.). Any consumer that branches on schemaVersion to decide whether v2.1+ features should be expected is silently misled.
  • cppagent compatibility broken. cppagent's JSON v2 printer emits schemaVersion as the actual configured MTConnect release (e.g. "2.7" when SchemaVersion=2.7 is set in agent.cfg). The JSON-CPPAGENT-MQTT format-label is an explicit cppagent-compat promise; this hardcode breaks it.
  • Per-operator unreachable. Unlike a simple default-to-floor, there is no YAML knob the operator can set to fix this without patching the library. The constant is not reachable from configuration.

Semantic alternative — is "2.0" meant to be the JSON-format version?

One could argue that schemaVersion: "2.0" is meant to denote a "version of the JSON shape itself" (given the sibling jsonVersion: 2). If that's the intent, the field is mislabelled: MTConnect standardises schemaVersion as the MTConnect release in XML, and cppagent's JSON v2 reuses that same semantic. A per-format version should use a different property name (e.g. jsonFormatVersion or be folded into jsonVersion with a minor bump like 2.0).

Either way — rename the property OR populate it from DefaultVersion — the current state is a divergence from the cppagent reference that the JSON-CPPAGENT-MQTT label promises to track.

Suggested fix

  1. Thread DefaultVersion into the JSON formatters. JsonMTConnectStreams.SchemaVersion and JsonMTConnectDevices.SchemaVersion should be populated from the agent's configured DefaultVersion (as a dotted MTConnect release string, e.g. "2.5"), not a hardcoded literal.
  2. Drop the hardcoded "2.0" initialisers from both constructors.
  3. Add a unit test that exercises new JsonMTConnectStreams(doc) with an agent configured for DefaultVersion = 2.5 and asserts schemaVersion == "2.5".
  4. Once the v2.6 / v2.7 uplift lands (companion request: 07-support-for-mtconnect-v2.6-and-v2.7.md), the same pathway naturally picks up the new ceiling without any further code change.

Verified by reproduction

Captured against trakhound/mtconnect.net-agent:6.9.0 on 2026-04-20:

  • current.json (no defaultVersion set) → schemaVersion: "2.0".
  • current-explicit-v25.json (defaultVersion: 2.5) → schemaVersion: "2.0" — setting ignored.
  • current-explicit-v25-quoted.json (defaultVersion: "2.5") → schemaVersion: "2.0" — setting still ignored.
  • cppagent-current.json (cppagent v2.7.0.7 with SchemaVersion = 2.7) → schemaVersion: "2.7" — behaves correctly, demonstrating the expected semantic.

Stability across MTConnect versions

Unaffected by v2.6 / v2.7 uplift — the hardcode is in the cppagent-compat formatter regardless of which MTConnect release the library supports. Fixing this before the uplift means the uplift "just works" for schemaVersion semantics.

Related issues

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions