ContentType seems to confuse OPC UA

The following code tries to read an OPC UA property

const read1 = await thing.readProperty("1:Speed");
console.log("speed value is: ", await read1.value());

with the following TD

              "properties": {
                  "1:Speed": {
                      "title": "Speed",
                      "type": "number",
                      "forms": [
                          {
                              "href": "/?id=ns=1;s=MotorSpeed"
                          }
                      ],
                      "observable": true
                  }
             }

everything works fine while adding a "contentType": "application/octet-stream" which looks like this breaks it.

              "properties": {
                  "1:Speed": {
                      "title": "Speed",
                      "type": "number",
                      "forms": [
                          {
                              "href": "/?id=ns=1;s=MotorSpeed",
                              "contentType": "application/octet-stream"
                          }
                      ],
                      "observable": true
                  }
             }

fails with

TypeError: dataType.toLowerCase is not a function
at OctetstreamCodec.valueToBytes

This seems to indicate that OPC UA data is processed by OctetstreamCodec also (again?)

Changing it to something unknown like "contentType": "application/octet-stream-x" fails, with
NotSupportedError: Content type application/octet-stream-x not supported
which is fine.

Changing it to "contentType": "application/opcua+octet-stream" creates a different error.

NotSupportedError: Invalid value according to DataSchema
    at InteractionOutput.value (...\opcua-test\node_modules\@node-wot\core\dist\interaction-output.js:129:19)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async ...\opcua-test\test.js:54:47 {
  value: {
    Value: { Type: 11, Body: 1500 },
    SourceTimestamp: 2025-06-24T15:00:32.167Z
  }
}

@sebastiankb

I think the problem is, that the node-opcua library we are using converts the data on the wire directly to a DataValue class by calling read(...).

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

Lines 305 to 313 in 3325e12

    
           public async readResource(form: OPCUAForm): Promise<Content> { 
        
               debug(`readResource: reading ${form}`); 
        
               const content = await this._withSession(form, async (session) => { 
        
                   const nodeId = await this._resolveNodeId(form); 
        
                   const dataValue = await session.read({ 
        
                       nodeId, 
        
                       attributeId: AttributeIds.Value, 
        
                   });

Maybe it is possible to get the raw data, but I am not sure.
Hence, I wonder whether a simplified fix is also reasonable. What do I mean by that, we remove the contentType for any OPC UA form so that no other ContentSerdes codec can kick in?

@sebastiankb @egekorkan do you think that is okay?
@erossignon do you have another proposal?

In #1402 I show what I intend to do...

What do I mean by that, we remove the contentType for any OPC UA form so that no other ContentSerdes codec can kick in?

The developer should not need to do that but if node-wot does it internally until a better solution is available, I would be ok with it.

I agree. We should keep this issue open in any case until we find a better solution.

The developer should not need to do that

BTW, the developer doesn't need to do anything. We take care internally...

I'm on it

@erossignon

@erossignon any updates you can share with us?

chore(binding-opcua) fix application/octet-stream encoding/decoding e…

@danielpeintner

@danielpeintner here you go , thank you for your patience.

chore(binding-opcua) fix application/octet-stream encoding/decoding e…

@erossignon

@erossignon do you plan to work on the content type issues?

Yes this is the next big item and is almost done on my side...

Actually waiting for the pending PRs to be merged on master , as my work relies on them...

@danielpeintner

@danielpeintner @sebastiankb @egekorkan @relu91 the proposal for this issue. #1449 is closed; this replaces it.

Measured on master today, reading a Double over OPC UA:

no contentType: works.
application/octet-stream: fails with dataType.toLowerCase is not a function, wherever type is declared. Core's generic octet-stream codec is decoding OPC UA content.
application/opcua+json: fails in core's schema check, with Invalid value according to DataSchema, or No schema type defined when the TD has no type.

What the PR will do:

The default stays application/json (TD 1.1 §5.3.4.2). OPC 10101 §6.5.3 names the content type to use for the server's own serialization; it does not set a default.
application/octet-stream means the raw bytes of a ByteString (images, files). Any other type is refused with an error naming the form and the actual OPC UA type. OPC UA Binary cannot be decoded without the data type's encoding rules, so it is only offered as application/opcua+octet-stream.
Reads go through the binding's own content negotiation, using the type the server reports.
Writes need Add possibility to register ContentCodec with scheme #1412 (codecs per URI scheme, Allow different Codecs for the same contentType #1409), because core serializes them before the binding is called. The missing part of Add possibility to register ContentCodec with scheme #1412 is in feat(core): register codecs per URI scheme (completes #1412) #1572.

Not in this PR: the application/opcua+json schema-check failures. They belong with #1243 and #1265.

@danielpeintner this covers what #1402 was after, while keeping contentType. OK to close #1402 in favour of it?

test(binding-opcua): end-to-end contentType matrix for eclipse-thingw…

fix(binding-opcua): own the octet-stream codec for opc.tcp forms (#1400…

Navigation Menu

Repository navigation

ContentType seems to confuse OPC UA #1400

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	public async readResource(form: OPCUAForm): Promise<Content> {
	debug(`readResource: reading ${form}`);

	const content = await this._withSession(form, async (session) => {
	const nodeId = await this._resolveNodeId(form);
	const dataValue = await session.read({
	nodeId,
	attributeId: AttributeIds.Value,
	});

ContentType seems to confuse OPC UA #1400

Description

Activity

danielpeintner commented on Jun 24, 2025

danielpeintner commented on Jun 24, 2025

danielpeintner commented on Jun 25, 2025

egekorkan commented on Jun 25, 2025

danielpeintner commented on Jun 25, 2025

danielpeintner commented on Jun 25, 2025

erossignon commented on Sep 1, 2025

danielpeintner commented on Oct 14, 2025

erossignon commented on Oct 15, 2025

danielpeintner commented on Sep 14, 2026

erossignon commented on Sep 14, 2026

erossignon commented on Sep 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions