Salut
Comme je l'ai écrit récemment (
Premier court article sur MQTT / UDP ), MQTT / UDP est un protocole basé sur MQTT, mais:
- Va au-dessus de la diffusion UDP (aucun courtier nécessaire, presque aucune configuration requise)
- Il est indécemment simple à mettre en œuvre (10 lignes sur la pile C + UDP / IP - et vous envoyez des données à partir du capteur)
- Tout le monde entend tout le monde
D'une certaine manière, c'est CAN, mais en plus d'Ethernet.
Pourquoi.
Mon appartement vit en fait depuis plusieurs années sous le contrôle d'un système tel que «la maison n'est pas vraiment oligophrène». Il serait superflu de l'appeler intelligence, mais la lumière et le climat sont automatisés. Pour imaginer l'ampleur de la catastrophe - le système occupe un rack plein à craquer d'environ 19 pouces de large et deux mètres de haut. Deux parois du rack sont occupées presque au sol.
Lorsque j'ai conçu tout cela, la question de la tolérance aux pannes est venue en premier. Plusieurs années de fonctionnement l'ont montré: c'est vrai. Nie tout. Tôt ou tard. Mais les relais électromécaniques n'ont pas encore échoué, et c'est sur eux le dernier échelon de protection contre les défaillances.
Le prochain problème après la tolérance aux pannes est le zoo. En raison du cours naturel de la vie, de ma curiosité et de mes besoins urgents, les Unix habituels sur un PC ordinaire, Aries PLC, Raspberr + Orange PI, les modules Atmega, les modules basés sur NodeMCU (ESP8266) vivent dans le système, et tout cela va les uns aux autres via Modbus 485, Modbus TCP, http, et sur le côté se bloque un courtier MQTT agité, comme héritage d'une tentative infructueuse de basculer vers lui avec un camp entier.
Pourquoi la tentative de basculer vers MQTT a échoué. Premièrement, pour une partie du fer, il est lourd ou compliqué. Sur le fragment de Pascal qui se cache dans l'automate CodeSys, seul un masochiste peut écrire MQTT. Mais alors vous devez déboguer. De même sur atmega: on peut fourrer, mais de près. Mais ce n'est pas tout le problème.
MQTT tel qu'il est (et il est acceptable partout 3.1.1) insiste pour envoyer un paquet PUBLISH (c'est-à-dire notre message au courtier) à tous les destinataires, y compris l'expéditeur. L'effet de cette folie est enchanteur - le même OpenHAB ne peut pas envoyer et recevoir des données dans MQTT sous le même nom. Cela signifie qu'il est impossible d'organiser un bus basé sur MQTT (plusieurs modules qui mettent à jour la valeur du même objet et l'utilisent). Et c'est exactement comme cela que la communication PLC doit être organisée, dans laquelle réside le principal contrôle de la lumière, OpenHAB, qui contrôle la lumière de l'interface Web et de l'application mobile, et les commutateurs intelligents, que j'aimerais pouvoir ajouter ici et ici. C'est, bien sûr, ce problème peut être contourné, mais en fait cela signifie la construction de votre propre protocole SURFACE MQTT, et cela semble déjà être trop.
En même temps, de quoi ai-je besoin? Envoyez une mise à jour de la valeur du paramètre et obtenez-la à tous les points intéressés. Pour quoi, en fait, les grands-pères ont fait UDP à l'adresse de diffusion.
Après le dernier post sur Habré, un des lecteurs m'a longtemps reproché la non fiabilité du protocole UDP. Je lui ai répondu de manière spéculative que pour l'IoT, UDP est PLUS fiable que TCP: avec 50% de perte de paquets sur un réseau, TCP ne se contentera pas de s'allonger, mais généralement, et le capteur de température envoyant des mesures sur UDP perdra simplement la moitié du nombre, ce qui affectera le fonctionnement du système de quelque manière que ce soit. Généralement.
Mais c'était spéculatif. Cependant, les vacances du Nouvel An ont également été données à une personne afin de finir de boire du champagne pour se demander: allons-nous mettre notre réseau local à la maison sur des pelles aujourd'hui? Et quoi qu'il arrive.
J'ai pris MQTT / UDP et j'ai écrit un test primitif. Un côté envoie autant de paquets consécutifs sans pause entre les paquets. Le second considère la vitesse et la perte de paquets. L'expérience était simple: nous lançons cette moquerie, et en parallèle deux téléviseurs HD diffusent des films sur Internet, et l'ordinateur de bureau écrit un énorme fichier sur le NAS.
Notez le résultat. J'ai tout attendu, mais ... la perte maximale pour UDP a atteint un demi pour cent, et les deux téléviseurs ont cessé de s'afficher. J'étais donc toujours pessimiste. Dans un véritable réseau domestique, la fiabilité de la livraison UDP est presque absolue. Néanmoins, je ferai probablement une version avec des confirmations et renverrai des paquets. Il y a peu de difficultés, mais la question est complètement supprimée.
La deuxième question est la sécurité, mais bon, s'ils pénètrent dans mon réseau domestique, la perte de données des capteurs de température est la dernière chose dont je vais pleurer. Cependant, encore une fois, la tâche de signature numérique des packages dans le suivi des problèmes est présente, et je comprends déjà comment étendre les packages MQTT pour son implémentation.
En général, je prévois que la première paire d'appareils du réseau domestique passera à MQTT / UDP juste l'autre jour.
Et je vous suggère de l'essayer dans vos programmes et appareils:
Référentiel et
documentation en anglais .
Ce qui est disponible:
Implémentations assez complètes en Java, Python et C. Implémentation de base sur Lua. Jusqu'à présent, l'envoi uniquement pour Arduino et CodeSys PLC (testé et fonctionne sur Aries, mais il devrait faire n'importe quoi).
Outil GUI pour regarder ce qui se passe et intervenir:
Programmes d'envoi et de réception de données en Python, Lua et Java.
Connecteurs Python pour l'intégration avec MQTT standard et directement avec OpenHAB. Ils établissent une protection contre les cycles, interdisant la diffusion inverse du message pendant 5 secondes après un passage vers l'avant. De plus, il existe une bibliothèque pour limiter le flux de données répétées. Elle vérifie s'il y a déjà eu une mise à jour de ce sujet pour la durée spécifiée et si c'est le cas, elle ignore la nouvelle mise à jour uniquement si les données ont changé.
Je prévois de passer progressivement à ce protocole complètement, et voici un exemple de ce que je veux obtenir avec des capteurs:
Il y a trois capteurs dans une pièce (enfin, ou dans la rue, ça n'a pas d'importance). Ils envoient des échantillons via MQTT / UDP. Ces relevés sont reçus simultanément par le principal système de maison intelligente (OpenHAB), une base de données historique et un moniteur mural qui affiche la température des résidents.
Tout le charme de MQTT / UDP est que dans un tel schéma, la défaillance d'un bloc ne crée aucun problème pour tout le monde. Et c'est avec la simplicité enchanteresse du protocole.
De plus, des schémas de contrôle redondants avec duplication sont facilement mis en œuvre dans le même schéma. Le serveur de base de données peut être dupliqué sans aucun problème. Il sera plus délicat de dupliquer les modules traitant de la gestion. Par exemple, l'écoute de la température donne une action de contrôle sur les radiateurs. Mais c'est probablement la prochaine histoire. Aujourd'hui, je prévois de me concentrer sur la collecte de signaux provenant de capteurs et l'échange entre les modules d'une maison intelligente.