Reflection on the MQTT API

Development
2

My first impression after reading the API documentation is about the topics related to device features.
I’m not a big fan of the current implementation on two points:

  • There is no differentiation between « incoming » and « outgoing » topics. We know that a device must publish its new state on gladys/master/device/state/update but which one should it listen to to retrieve its state? These topics should be standard.
  • The IDs of the objects pass in the payload and not the URL. So, if I want to subscribe to the update of a single device… well I can’t :confused: All devices should subscribe to a topic of the type « device/update » and look inside the payload if the message concerns them. This seems like an anti-pattern.

A proposal that could respect these two remarks:
If I have an object of this type:

{
  "name": "Living room connected object",
  "external_id": "custom:12",
  "should_poll": false,
  "features": [
    {
      "external_id": "custom:12:temperature:1",
      "name": "temperature",
      "category": "temperature-sensor",
      "type": "decimal",
      "read_only": false,
      "has_feedback": true,
      "min": -50,
      "max": 80
    },
    {
      "external_id": "custom:12:onOff:1",
      "name": "On/Off",
      "category": "light",
      "type": "binary",
      "read_only": false,
      "has_feedback": true,
      "min": 0,
      "max": 1
    }
  ]
}

Proposed topics and payloads:

  • The device publishes its state
payload: 19.8

topic: gladys/master/device/custom:12/feature/custom:12:onoff:1
payload: 1
  • Gladys publishes changes for the device to react

topic: gladys/device/custom:12/feature/custom:12:onoff:1
payload: 0

Thus, my device can subscribe to one or more topics depending on what it can handle:

gladys/device/custom:12/feature/custom:12:onoff:1
gladys/device/custom:12/feature/#

And Gladys only needs one for all devices:

I think it is necessary to take into account the wildcards offered by the protocol.
You will say, yeah, but that’s a lot of topics in the end!
Yes, and so what? We have a choice… more topics or more listeners on the same topic.
I believe that the « standard » in IoT is to differentiate topics by device. An argument in this direction is that it is not up to the object to know how to differentiate the content of the messages it receives. We also save the load of a JSON.encode / JSON.decode on the connected object side.
We could also imagine, on the security side, differentiating access by topic, and thus not allowing an unauthorized object to publish on a topic that does not concern it.

What do you think about it?