Support non-JSON content types for events / observed properties via MQTT binding

[kiesel]

I have a TD where eg. an event is being declared in events like this:

  "customContentType": {
    "type": "string",
    "forms": [{ "contentType": "application/octet-stream" }]
  }

When the thing has been exposed, the directory contains this description:

  "customContentType": {
    "forms": [
      {
        "contentType": "application/octet-stream",
        "href": "http://<ip>:8080/mything/events/customContentType",
        "op": ["subscribeevent", "unsubscribeevent"],
        "subprotocol": "longpoll"
      },
      {
        "contentType": "application/json",
        "href": "mqtt://<brokerip>:1883/mything/events/customContentType",
        "op": ["subscribeevent", "unsubscribeevent"]
      }
    ],
    "type": "string"
  }

I am using node-wot to expose the thing, so when the event is being emitted as in thing.emitEvent('customContentType', Readable.from(Buffer.from('...'))); the value gets converted to JSON (exposing internal state of a Readable) and emitted.

Obviously, you cannot get the actual data from that emission (this was spyed on with mosquitto_sub):

{"_readableState":{"objectMode":true,"highWaterMark":16,"buffer":{"head":null,"tail":null,"length":0},"length":0,"pipes":[],"flowing":null,"ended":false,"endEmitted":false,"reading":false,"constructed":true,"sync":true,"needReadable":false,"emittedReadable":false,"readableListening":false,"resumeScheduled":false,"errorEmitted":false,"emitClose":true,"autoDestroy":true,"destroyed":false,"errored":null,"closed":false,"closeEmitted":false,"defaultEncoding":"utf8","awaitDrainWriters":null,"multiAwaitDrain":false,"readingMore":false,"dataEmitted":false,"decoder":null,"encoding":null},"_events":{},"_eventsCount":0}

When requesting the value w/ HTTP longpolling, the application crashes with an error:

Error: Unable to handle dataType undefined
    at OctetstreamCodec.valueToBytes (.../node_modules/@node-wot/core/dist/codecs/octetstream-codec.js:155:23)
    at ContentSerdes.valueToContent (.../node_modules/@node-wot/core/dist/content-serdes.js:108:27)
    at ProtocolListenerRegistry.notify (.../node_modules/@node-wot/core/dist/protocol-listener-registry.js:59:54)
    at ExposedThing.emitEvent (.../node_modules/@node-wot/core/dist/exposed-thing.js:91:35)
    at Kelvin.emitBeat (.../dist/kelvin.thing.js:90:20)

What I'd actually like to achieve would be to send a binary payload over both HTTP and MQTT channels and get the actual data in a suitable format. With MQTT, it would obviously not be possible to transmit a content type information, but this information can be extracted from the thing description.

[relu91]

I labeled the issue as a bug because the MQTT binding should respect the user content type. However, I'm interested in knowing more about your use case and the payload format of what you are trying to send. I'm asking because the octetstream-codec has support for strings (as you reported in your HTTP case it has a bug) but I would say that the MIME type text/plain should be used instead.

Can you tell us more about the platform you are using and the payload types you are sending in MQTT?

[kiesel]

Thank you for your update!

My usecase is actually about a thing that emits binary data such as a picture to its consumers. Due to some constraints I chose not to use a HTTP binding with long-polling for this (this would work ok as far as I can tell), but rather an MQTT binding.

As an addition to the report I need to mention that the TD must actually also contain:

[...]
  "data": {
    "type": "string"
  }
[...]

for the octet-stream codec not to fail catastrophically - it will throw uncaught error and terminate the program.

[relu91]

My usecase is actually about a thing that emits binary data such as a picture to its consumers.

Have you considered using image/png or other image-only content types?

[kiesel]

I think I tried but the contentType was also ignored for the mqtt binding.

[relu91]

Started looking into this issue, and it is related to #1029. We need to reconsider the generation of forms in protocol bindings. The idea of having generic methods in protocol helpers makes sense, but they need to be better designed taking into account protocol-specific terms. For example, If the user in the template specifies HTTP headers to use.