`Header.version` reports library assembly version instead of MTConnect release

[ottobolyos]

Summary

Every envelope published by the mqtt-relay module (and, by extension, any consumer of the shared Header serialiser) reports Header.version as the library's own assembly version (e.g. "6.9.0.0" on v6.9.0.2), rather than the MTConnect Standard release the agent is serving. This misidentifies the agent to every downstream consumer and breaks any logic that branches on spec version.

Verified by reproduction — 2026-04-20

Reproduced live against trakhound/mtconnect.net-agent:6.9.0 (the official TrakHound image published 2025-10-16 alongside v6.9.0.2) with eclipse-mosquitto:2.0.22 as the broker. The Header.version slot emits "6.9.0.0" on every MTConnectStreams MQTT envelope, and version="6.9.0.0" on the HTTP XML Probe Header, regardless of any defaultVersion value set in agent.config.yaml. Side-by-side comparison: cppagent v2.7.0.7 in an identical configuration emits "2.7.0.7" in the same slot — correctly reporting the agent's MTConnect release.

Environment

• MTConnect.NET-Applications-Agents + MTConnect.NET-SHDR + MTConnect.NET-JSON-cppagent at v6.9.0.2 (published 2025-10-16, the latest release).
• Broker: eclipse-mosquitto:2.0.22.
• Format ID: JSON-cppagent-mqtt (the same shared Header serialiser is also used for JSON-CPPAGENT — please confirm the scope when fixing).

Reproduction

applications/MTConnect-Agent/appsettings.yaml (minimum viable):

defaultVersion: 2.5.0.0       # the library's advertised ceiling; any valid value surfaces the same bug
modules:
  - mqtt-relay:
      server: localhost
      port: 1883
      topicPrefix: MTConnect
      documentFormat: JSON-cppagent-mqtt

Start a local Mosquitto (eclipse-mosquitto:2.0.22 on 127.0.0.1:1883), run the agent, and subscribe:

mosquitto_sub -h localhost -t 'MTConnect/Current/#' -C 1 | jq '.MTConnectStreams.Header.version'

Observed

"6.9.0.0"

Expected

"2.5.0.0"

(With defaultVersion unset, the companion hardcoded-schemaVersion issue #128 further forces this to "2.0"; with defaultVersion correctly wired to the configured release, it should echo that release.)

Authority

MTConnectStreams_2.7.xsd (identical wording in _2.5.xsd and _2.6.xsd):

<xs:attributeGroup name='HeaderAttributesType'>
  <xs:attribute name='version' type='VersionType' use='required'>
    <xs:annotation>
      <xs:documentation>The document version</xs:documentation>
    </xs:annotation>
  </xs:attribute>
  ...
</xs:attributeGroup>

<xs:simpleType name='VersionType'>
  <xs:restriction base='xs:NMTOKEN'/>
</xs:simpleType>

The XSD does not pattern-constrain VersionType, but the MTConnect prose standard, Part 1 (Overview, §5) and Part 2 (Devices Information Model, §7 Header), documents version as the MTConnect Standard release the agent serves (e.g. "2.5.0.0", "2.7.0.0").

The cppagent reference implementation emits exactly that — "2.7.0.0" on a v2.7 agent, "2.5.0.0" on a v2.5 agent. The format ID JSON-CPPAGENT-MQTT is itself an explicit promise of cppagent-reference compatibility; diverging here breaks both the prose-spec contract and the format-label contract.

Impact

• Consumers that branch on Header.version to decide whether v2.x-only fields should be surfaced receive a version string they can never match against any published MTConnect release.
• Strict cppagent-shape consumers fail format-label validation.
• Operational diagnostics (e.g. schema registries, compliance dashboards) misreport the agent as running an undefined "6.9.x" MTConnect version.

Location in source

Shared Header serialiser used by libraries/MTConnect.NET-JSON-cppagent/Formatters/JsonMqttResponseDocumentFormatter.cs. The encoder currently reads the MTConnect.NET assembly version when populating the version slot instead of the configured DefaultVersion / agent release.

Suggested fix

1. Emit the configured MTConnect release as Header.version — the same value used for schemaVersion. Library assembly version should be exposed via metrics, a non-standard extension field, or a sender suffix, but never in the spec-defined version slot.
2. If the value is currently pulled from Assembly.GetExecutingAssembly().GetName().Version, switch to reading the agent's configured MTConnect version (AgentApplicationConfiguration.DefaultVersion or equivalent).

Stability across MTConnect versions

Identical across v2.5, v2.6, v2.7 — HeaderAttributesType.version has been a required attribute typed VersionType since v1.3+, and the prose-spec guidance that this reflects the MTConnect release has been stable across every v2.x release.

Related issues

• MTConnectStreams.schemaVersion / MTConnectDevices.schemaVersion hardcoded to "2.0" in JSON-cppagent-mqtt formatter #128 — MTConnectStreams.schemaVersion / MTConnectDevices.schemaVersion hardcoded to "2.0" — same envelope, adjacent root cause; the two slots should report the same MTConnect release.
• Add support for MTConnect Standard v2.6 and v2.7 #133 — Add MTConnect v2.6 + v2.7 support — once available, the fix here automatically serves the latest release rather than the library's compiled-in ceiling.

References

• XSDs: MTConnectStreams_2.7.xsd, MTConnectStreams_2.6.xsd, MTConnectStreams_2.5.xsd.
• Prose standard: https://www.mtconnect.org/standard-download20181 — Part 1 §5, Part 2 §7.
• Normative SysML / XMI model: https://github.com/mtconnect/mtconnect_sysml_model — MTConnectSysMLModel.xml.
• cppagent reference: https://github.com/mtconnect/cppagent.

[ottobolyos]

@PatrickRitchie, before I open PRs against the below, could you sanity-check the scope and approach in each issue's Suggested fix section and confirm you’d review and merge PRs that follow them?

• Header.version reports library assembly version instead of MTConnect release #127;
• MTConnectStreams.schemaVersion / MTConnectDevices.schemaVersion hardcoded to "2.0" in JSON-cppagent-mqtt formatter #128;
• JSON-cppagent-mqtt: numeric Sample value emitted as JSON string instead of number token #129;
• JSON-cppagent-mqtt: Header.schemaVersion absent on MQTT Streams Header #130;
• JSON-cppagent-mqtt: Header.testIndicator absent on MQTT Streams Header #131;
• ASSET_COUNT DataItem not auto-rendered as representation="DATA_SET"; stream observation named AssetCount instead of AssetCountDataSet #132;
• Add support for MTConnect Standard v2.6 and v2.7 #133;
• Organizers._systems list is stale — causes asymmetric <Systems> auto-nesting in Device.AddComponent() #134;
• mqtt-relay module publishes Agent Availability on a non-canonical {prefix}/Probe/{agent-uuid}/Available four-segment topic #135.

Most are single-file diffs:

• MTConnectStreams.schemaVersion / MTConnectDevices.schemaVersion hardcoded to "2.0" in JSON-cppagent-mqtt formatter #128 / JSON-cppagent-mqtt: Header.schemaVersion absent on MQTT Streams Header #130 / JSON-cppagent-mqtt: Header.testIndicator absent on MQTT Streams Header #131 root in libraries/MTConnect.NET-JSON-cppagent/Streams/JsonStreamsHeader.cs + the JsonMTConnectStreams / JsonMTConnectDevices wrappers;
• JSON-cppagent-mqtt: numeric Sample value emitted as JSON string instead of number token #129 is the numeric-value writer in JsonMqttResponseDocumentFormatter.cs;
• Organizers._systems list is stale — causes asymmetric <Systems> auto-nesting in Device.AddComponent() #134 is libraries/MTConnect.NET-Common/Devices/Organizers.cs + Device.cs:317;
• mqtt-relay module publishes Agent Availability on a non-canonical {prefix}/Probe/{agent-uuid}/Available four-segment topic #135 is agent/Modules/MTConnect.NET-AgentModule-MqttRelay/Module.cs:738-744.
• Header.version reports library assembly version instead of MTConnect release #127 + ASSET_COUNT DataItem not auto-rendered as representation="DATA_SET"; stream observation named AssetCount instead of AssetCountDataSet #132 touch the shared Header path and the auto-DataItem generator respectively.
• Add support for MTConnect Standard v2.6 and v2.7 #133 is the v2.6 + v2.7 uplift.

I can ship it all as one PR or split per envelope family, whichever suits your review cadence. Happy to order / bundle however you prefer, however, I’d like to get all of these issues fixed ASAP. 🙏

[PatrickRitchie]

@ottobolyos Thanks for documenting these issues! Yes feel free to create PRs for these issues (separate PRs would be preferred).

• For Header.version reports library assembly version instead of MTConnect release #127 it looks like you are correct, it is the version of the Standard and not the Application. I must have read that wrong when I first wrote it.

• For mqtt-relay module publishes Agent Availability on a non-canonical {prefix}/Probe/{agent-uuid}/Available four-segment topic #135 this was a simple way to signal when the Agent disconnects and was not part of the standard. I believe the cppagent uses the same method the last time I used it.

• For Add support for MTConnect Standard v2.6 and v2.7 #133 I may need to run the SysML import found in the MTConnect.NET-SysML-Import project. But if you are using Claude, etc. I would be curious to see how it would update it on its own.

Thanks!

[ottobolyos]

@PatrickRitchie, heads-up on how I'm planning to land fixes for the 12 issues I've filed over the last week (#127-#138). I want to make sure the approach aligns with your PR-per-task preference before I start opening PRs.

Plan

Ten PRs total:

#	Issues	Scope
1	#133	Add v2.6 + v2.7 XSDs, constants, regenerated DataItem/Component classes. Biggest blast radius—propose landing first so the rest rebase cleanly.
2	#134	Align Organizers.Systems list with XSD substitution-group union (adds Heating etc.).
3	#127	Route configured MTConnect release through Header.version instead of library assembly version.
4	#128	Thread configured SchemaVersion through JsonMTConnectStreams / JsonMTConnectDevices instead of hardcoded "2.0".
5	#129	Emit numeric Sample values as JSON number tokens; keep "UNAVAILABLE" as string.
6	#132	Auto-generated ASSET_COUNT stamped representation="DATA_SET"; emit AssetCountDataSet with per-type counts.
7	#135	Relocate Agent Availability publish out of Probe/# wildcard.
8	#130 + #131 (merged)	Both add missing JSON-cppagent Header properties (schemaVersion, testIndicator) on the same three files (Json{Streams,Devices,Assets}Header.cs). Splitting them into two PRs would guarantee a rebase conflict on adjacent lines, so they ship together.
9	#136 + #137 (merged)	Both strip defaults from the same Device default ctor. #137 additionally touches Component ctors. One PR covers both atomically.
10	#138	Omit name key on JSON-cppagent Probe DataItems when source Name is null or empty, mirroring the existing guard at XmlDataItem.cs:198. Independent of #136/#137 — different file (JsonDataItem.cs), different layer (DTO serialiser vs POCO model), non-breaking (spec-conformance only).

Entries 8 and 9 are the two exceptions to the one-PR-per-issue rule. Each covers a single file-cluster where the two issues' fixes are in adjacent lines of the same file. I can split them further if you prefer separate PRs—happy to do whichever serves your review flow better. My read is that one cluster-PR is cheaper for you to review (one file diff, two logical fixes) and eliminates the interdependent-rebase dance; a separate-PR-per-issue split would mean merging one then rebasing the other.

Order

Any order works for entries 3-7 and 10—they're disjoint surfaces. The ordering in the table above minimises rebase churn:

• Add support for MTConnect Standard v2.6 and v2.7 #133 first: its XMI regeneration ripples through *.g.cs files; later PRs rebase cleanly against a stable regenerated tree.
• Organizers._systems list is stale — causes asymmetric <Systems> auto-nesting in Device.AddComponent() #134 right after Add support for MTConnect Standard v2.6 and v2.7 #133: depends on whichever System-substitution-group members the regen surfaces.
• JSON-cppagent-mqtt: Header.schemaVersion absent on MQTT Streams Header #130+JSON-cppagent-mqtt: Header.testIndicator absent on MQTT Streams Header #131 and new Device() ctor auto-generates a random Uuid that re-rolls on every construction, silently violating the XSD "for its entire life" identity contract when a caller does not overwrite it #136+new Device() ctor stamps demo-fixture defaults (Id="4A1GF40513", Name="dev"); new <T>Component() ctors back-fill Name from lowercase type-name #137 (clusters) last: they're independent of everything above, and rebasing them once at the end beats rebasing every other PR against them.

Would appreciate your feedback on

1. Are the two merged PRs (8, 9) OK by you, or would you prefer them split? If split, we get clean one-PR-per-issue but one rebase per cluster.
2. Any ordering preference that overrides mine?

I'll hold on opening any of the draft PRs until I hear back. Thanks for the thoughtful issue responses on the whole batch—happy to adjust the plan to whatever fits your workflow.