Arrays: CSV round-trip rejects variable-length arrays; Plain MQTT ignores isArray; no live Sparkplug array test; #751 SDK reflection #770
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Follow-ups from #754 (Sparkplug arrays) and #751:
ArrayLengthwhenIsArrayis set, but browse-commit (MQTT now, MTConnect's documented flow) and the composer allow variable-length arrays with no length — exporting such a tag to CSV and re-importing it fails validation.isArray: a Plain tag markedisArray: truebecomes an array node fed scalar values, with no authoring or driver warning.Items 1–2 fixed on master
b8d2fc37: RawTagCsvMapper no longer demands a positive ArrayLength when IsArray is set, so variable-length arrays round-trip (Variable_length_array_round_trips_lmxopcua_770 fails without the fix); MqttTagDefinitionFactory.Inspect warns (advisory — the inspector can't see the driver's mode) when isArray is on a Plain-shaped tag (Inspect_IsArrayOnPlainTag_Warns fails without the fix; Sparkplug-shaped control stays quiet). Driver.Mqtt 904 + 53 AdminUI CSV/array/parity tests pass. Still open: live Sparkplug array test (simulator publishes no arrays) and the #751 SDK-reflection tracking.Item 3 done on master: Sparkplug simulator now publishes Int32Array/BooleanArray/FloatArray(+Double/String encoders, written from the spec text not the driver codec). New live test
Array_metrics_arrive_as_typed_arrays_and_a_changed_vector_is_a_change(negative + >16-bit int, 9-element bool crossing a byte boundary, float; changed vectors incl. a different bool length; non-isArray binding → BadTypeMismatch). Live run vs a throwaway Mosquitto 2.0.22 (TLS): SparkplugLiveTests 9/9. Mutations (bind scalar / drop seed) → new test fails. Driver.Mqtt.Tests 904/904.Remaining: item 4 — #751 reads the client endpoint from the OPC UA SDK's private channel table by reflection; needs an upstream SDK API. Keeping open for that.
Item 4 (the last open item) now has a concrete path. OPC Foundation SDK 2.0.1 adds a public
SecureChannelContext.PeerAddress, the API the #751 reflection inSecureChannelRemoteEndpointwas waiting for. Using it means the major 1.5.378 → 2.0.x SDK upgrade, now tracked in #782. Items 1–3 are done (b8d2fc37,a0c8b63c), so closing this in favour of #782.