Reflexion autour de l'API MQTT

Développement
2

Ma première impression à la lecture de la doc de l’API est sur les topics liés aux devices features.
Je ne suis pas super fan de l’implémentation actuelle sur deux points:

  • Il n’y a pas de différenciation entre les topics “entrant” et “sortant”. On sait qu’un device doit publier son nouvel état sur gladys/master/device/state/update mais sur lequel doit-il écouter pour récupérer son état ? Ces topics devraient être standards.
  • Les ids des objets passent dans le payload et non l’url. Ainsi, si je veux souscrire à l’update d’un seul device… et bien j’peux pas :confused: L’intégralité des devices devrait souscrire à un topci du type “device/update” et chercher à l’intérieur du payload si le message le concerne. Ca me semble anti-pattern.

Une proposition qui pourrait respecter ces deux remarques:
Si j’ai un objet de ce 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
    }
  ]
}

Proposition de topics et de payloads:

  • Le device publie son état
topic: gladys/master/device/custom:12/feature/custom:12:temperature:1
payload: 19.8

topic: gladys/master/device/custom:12/feature/custom:12:onoff:1
payload: 1
  • Gladys publie des changements pour que le device réagisse
topic: gladys/device/custom:12/feature/custom:12:temperature:1 // Adresse inutile dans la mesure ou on ne peut pas setter la T° sur le device :D

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

Ainsi, mon device peut souscrire à un seul ou plusieurs topics en fonction de ce qu’il peut gérer:

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

Et gladys qu’à un seul pour l’ensemble des devices:

gladys/device/#

Je pense que prendre en compte les wildcards offertes par le protocol est nécessaire.
Vous me direz, ouais, mais ça fait beaucoup de topcis au final!
Oui, et alors ? On a le choix… plus de topics ou plus de listeners sur le même topics.
Je crois que la “norme” dans l’IOT, est de différencier les topics par device. Un argument qui va dans ce sens est que ce n’est pas à l’objet de savoir différencier le contenu des messages qu’il reçoit. On s’économise en plus la charge d’un JSON.encode / JSON.decode côté objet connecté.
On pourrait aussi imaginer côté sécurité, différencier les accès par topic, et ainsi ne pas permettre à un objet non autorisé à publier sur un topic qui ne le concerne pas.

Qu’en pensez-vous ?

1 « J'aime »