[danielpeintner]

provides a workaround for #1400, but does not really fix the issue.

[danielpeintner]

This is just a left-over I would like to remove

[relu91]

I found this workaround quite sneaky... I'm wondering if you have looked here? It seems that the library is not following our architectural pattern. Instead of defining a serdes, he manually takes care of payload serialization and deserialization. Looking in the code base, it seemed that at the time he couldn't find a way to properly register his custom serdes, we should re-evaluate this, and if not possible, we should update the content handling.

[danielpeintner]

We quickly discussed some possible solutions in the committer call and we were wondering whether the contentTypes used so far

• application/opcua+json
• application/opcua+octet-stream

are actually right. Should it be with or without opcua+ prefix

@sebastiankb ?

[danielpeintner]

I have been looking into the code more closely and it seems the node-opcua library call of session.read(...) to retrieve a property value.

i.e.,

node-wot/packages/binding-opcua/src/opcua-protocol-client.ts

Lines 310 to 313 in 699e6b6

	const dataValue = await session.read({
	nodeId,
	attributeId: AttributeIds.Value,
	});

returns already a JSON structure (see DataValue), even if the value on the wire is binary.

e.g., for dataValue the JSON may look like this

{
    "value": {
        "dataType": "Double",
        "arrayType": "Scalar",
        "value": 1500
    },
    "statusCode": {
        "value": 0
    },
    "sourceTimestamp": "2025-07-01T11:59:50.620Z",
    "sourcePicoseconds": 824200000,
    "serverTimestamp": "2025-07-01T11:59:50.620Z",
    "serverPicoseconds": 824200000
}

The actual value is the double 1500 (in value.value).

The call one line after (on line 314) extracts this value.

node-wot/packages/binding-opcua/src/opcua-protocol-client.ts

Line 314 in 699e6b6

return this._dataValueToContent(form, dataValue);

FYI: By default, the two codecs OpcuaBinaryCodec and OpcuaJSONCodec are not even called if no contentType is given. This is the case the binding works nicely.

The whole workflow seems to conflict with what we do in other bindings were we get the raw data and the ContentSerdes converts it if needed (later).

Hence, I see the following options to move on:

1. We ignore the contentType in the TD and let binding-opcua deal with it (currently implemented in this PR)
2. We re-code the value to the given contenType (seems weird to me, but we could return dataValue.value.value as is)
3. We evaluate whether there is anything else we could use besides the JSON structure DataValue. Maybe there is a binary counterpart? I looked a bit around and the expectation is to work with DataValue... but I might be wrong.
4. Something else ???

Comments are welcome!

[erossignon]

assigning to me, an other library is required to convert node-opcua internal objects to OPCUA+JSON compliant one

[erossignon]

Following up on the question I left on #1400 last week.

#1574 is now open and CI is green. It supersedes this draft, and it settles the two things left hanging in this thread:

• @relu91's point from 2025-06-26 — the binding serializes payloads by hand instead of defining a serdes. fix(binding-opcua): own the octet-stream codec for opc.tcp forms (#1400) #1574 does define one: the OPC UA codecs are registered for the opc.tcp scheme and core does the rest. That only became possible when feat(core): register codecs per URI scheme (completes #1412) #1572 landed last week.
• The naming question from 2025-06-27 — application/opcua+json keeps the prefix, and the default stays application/json per W3C WoT TD 1.1 §5.3.4.2. OPC 10101 §6.5.3 is conditional and does not set a default. Detail in the proposal on ContentType seems to confuse OPC UA #1400.

The extra library I mentioned when I took this over in August also exists now, which is what unblocked the 1.04/1.05 JSON encodings.

OK to close this one in favour of #1574?