Plus simple que MQTT? MQTT / UDP

Je voulais écrire un article détaillé sur ce sujet, mais, évidemment, mes mains n'atteignent pas. Par conséquent, un court message. J'ai développé et implémenté en plusieurs langues comme code prototype une version du protocole MQTT sous le nom de travail MQTT / UDP. Pour les impatients et ceux qui comprennent déjà tout et évidemment, le code sur Github

Pourquoi

Je vis dans un appartement qui est presque entièrement contrôlé par mon propre système de maison intelligente depuis plusieurs années. Lumière, climatisation, capteurs, automatisation facile, c'est tout.

Pendant ce temps, j'ai découvert (oui, d'ailleurs, je l'ai déjà compris) que la propriété principale des systèmes UD est la fiabilité.

Tous les systèmes avec un nœud central sont, par définition, peu fiables. D'où le désir d'obtenir l'interconnexion des composants du système (et ils sont nombreux dans une vraie maison intelligente) sans utiliser de hub central.

Dans le même temps, nous partons du fait que, en général, le trafic des systèmes UD est petit - les capteurs doivent rarement être mis à jour plus d'une fois par minute, le reste des données est basé sur les événements (allumé) et le trafic est complètement insignifiant. Même chaque seconde mise à jour de toutes les données du système n'est pas seulement une catastrophe, mais même un problème important.

La conclusion logique est que la diffusion UDP est un outil idéal.

(Oui, je suppose que le réseau interne de l'appartement est fermé par un pare-feu.)

Quels sont les avantages:

Implémentation incroyablement simple. Un microcontrôleur minimal avec une petite mémoire peut envoyer un paquet UDP. Pour le capteur, même la réception UDP n'est pas nécessaire.

Latence extrêmement faible. Il n'y a pas de renvoi dans le concentrateur central, le délai de livraison des paquets UDP est pratiquement le créneau horaire minimum dans un système moderne.

Il n'y a pas de point de défaillance central dans le concentrateur / courtier. Prenons un schéma simple: deux capteurs de température, un contrôleur de plancher chauffant, un contrôleur de batterie de chauffage. Avec l'utilisation de MQTT / UDP, la défaillance d'une partie quelconque d'un tel système n'entraîne pas une défaillance du système dans son ensemble.

Faible trafic réseau. En dessous de nulle part. TCP et les remerciements ajoutent uniquement du trafic, mais n'ajoutent pas de fiabilité. Un capteur défectueux ne fonctionnera pas lors de la réception d'un TCP ACK. Et nous identifions l'échec par l'absence de mises à jour.

La fiabilité du protocole UDP lui-même est insignifiante - les capteurs mettent toujours à jour les données régulièrement, et la disparition du comptage est complètement invisible, et la disparition d'une commande, par exemple, d'un commutateur est visuellement confirmée par la défaillance du système cible. Que fait une personne? Clique à nouveau. Cependant, il s'agit d'une limitation majeure de l'applicabilité du protocole. Idéal pour les sondages récurrents.

Aucune configuration système requise. Personne n'a besoin d'enregistrer l'adresse d'un courtier, d'un hub, etc. Cependant, la configuration du capteur est toujours nécessaire - vous devez enregistrer l'ID du capteur. Mais lors du transfert d'autres parties du système vers d'autres serveurs, la reconfiguration des composants de réponse n'est pas requise.

Il est particulièrement intéressant que ce modèle d'échange de données s'intègre bien sur des supports diffusés naturellement comme une chaîne radio ou RS / 485. Je n'ai pas expérimenté cela, et le protocole dans de tels environnements doit être contrôlé. Soit dit en passant, il est logique d'appliquer CRC16 à partir de Modbus.

Les inconvénients sont également évidents: la fiabilité de la livraison n'est déterminée que par le matériel et le trafic sur le réseau, eh bien, si l'ennemi pénètre dans le réseau, le protocole est immédiatement vaincu. Certes, nous serons francs, le piratage d'autres protocoles de maison intelligente typiques est une question de secondes, il s'agit donc d'un inconvénient controversé de MQTT / UDP. Un autre inconvénient non évident est un maximum d'un récepteur par adresse IP.

Ce qui a été fait et réside dans le référentiel de code source:

• Implémentations client / serveur en plusieurs langues. Il existe C, Python et Java. Je ne maîtrisais pas Lua (ne pouvais pas mettre tout ce dont vous avez besoin, comment vivez-vous dans cela?) Et Codesys (ne pouvais pas compiler le paquet, qui a inventé cette langue?).
• Portail minimal vers MQTT traditionnel en Python
• Un outil primitif pour afficher le trafic MQTT / UDP sur un réseau

Que ferais-je si j'avais plus de temps:

• J'écrirais un module pour openHUB.
• Ferait une variante de protocole sur JSON sur un autre port et un convertisseur au format principal et au port. Ou une porte dans les deux sens.
• Je ferais des blancs d'implémentation pour les principales plates-formes. Pour Arduino, j'ai fait une approche du poids et j'ai vraiment testé le code, mais je n'ai pas tout conçu correctement. Pour Raspberry, les cas de test en Python conviennent.
• Signerait et chiffrerait numériquement, mais il n'est pas clair comment.
• Multidiffusion.

Merci à ce sujet, bienvenue dans le référentiel

PS: Une approche similaire, mais avec une multidiffusion, est décrite dans cet article.