Pourquoi MQTT?

Salon des Développeurs Aide Programmation
1

Je ne connais pas MQTT et je me pose quelques questions en voyant que de plus en plus de plugin l’utilise pour, si j’ai bien compris, la communication entre le deamon du plugin et Jeedom. Je suis persuadé qu’il y a des avantages à faire ainsi mais mes connaissances actuelles ne me permettent pas de les voir.

Dans les plugins qui utilisent un deamon que j’ai créé:

  • Le code php Jeedom envoie des informations au deamon en passant par un socket tcp
  • Le deamon envoie des messages à Jeedom en HTTP via une url qui déclenche un traitement dans un programme PHP du plugin.

Si j’ai bien compris, les plugins qui utilisent MQTT ont le deamon qui ne communique pas directement avec Jeedom mais avec un brocker MQTT qui fait le passe-plats entre le deamon et Jeedom.

A première vue, il me semble que ce passage via MQTT implique une utilisation supplémentaire de ressources et induit probablement une légère latence dans les communications entre le deamon et Jeedom.

J’aimerai donc comprendre quels sont les avantages de l’utilisation MQTT et s’il faudra que j’envisage de faire évoluer mes plugins pour qu’ils l’utilisent aussi MQTT (après passage en stable de MQTT manager?)

2

Hello,

Non en fait il y a pas de demon fait maison la, on utilise un produit existant et mondialement réputé (comme Zigbee2mqtt ou zwavejs2mqtt ) et on communique avec via mqtt. (Car ce protocole a été directement intégré dans le produit). Ou encore on communique directement avec un valetudo ou un shelly (qui intègrent ce protocole).

Donc c’est pas spécialement qqch que tu dois implémenter dans tes plugins… (pour l’instant du moins)

3

Intérêt de mqtt c’est que c’est une messagerie qui ne consomme rien en ressources , qui existe depuis les années 80 et qui s’affranchit des protocole.
Tout les informations sont disponibles et on

s’inscrit uniquement a ce que on a besoins.
Jeedom commence enfin à si mettre mais c’est même un peu tard et il devrait de mon avis être le moteur principal.

D’autre comme ha ne jure que par ça.

Une base de donnée pour tous les protocoles disponibles pour toutes les clients connectées

L’intérêt aussi en machine de dev c’est d’avoir les mêmes infos que la machine de prod sans pour autant la polluer.

4

J’avais donc mal compris en supposant que ces plugin intègrent un deamon fait maison qui aurai aussi pu être écrit pour dialoguer directement avec Jeedom.

L’utilisation de MQTT se justifie donc si on doit communiquer avec une librairie ou un équipement qui sais nativement communiquer en MQTT.
Si le plugin a un deamon écrit spécifiquement pour Jeedom, on peut communiquer en direct ou via MQTT selon l’envie du développeur.

5

Salut,

Je me suis posé un peu les mêmes questions et j’ai fait le pas pour quelques nouveaux plugins, en partie pour valider le principe moi même au début.

On ne peut pas vraiment comparer les deux, un socket tcp c’est vraiment bas niveau, un client mqtt est au dessus et avoir un protocole un peu plus évolué qu’un simple socket tcp ça aide au moment du dev.
Je pense que ça aidera aussi à l’usage et à la configuration (par exemple plus de conflit de port entre différent plugin, ça arrive peu pour l’instant mais cela ne va que être de plus en plus risqué)

Point de vue perf, je te rejoins sur le cas d’un plugin isolé mais à chaque plugin avec démon c’est un nouveau serveur tcp… si on regarde l’ensemble, pas sur qu’on ait la même conclusion vs un et un seul serveur.

« Rien » est probablement exagéré; du coup un socket tcp ça ne consomme rien non plus, on ne peut pas faire plus léger que ça :wink:

6

Exactement :slight_smile:

7

Merci à tous pour vos éclairages.

Ce soir, je vais me coucher un peu moins bête :smiley:

8

Peut être qu’un jour jeedom imposera de passer par la pour les plugins mais pour l’instant comme le dit @Mips autant passer en direct c’est plus bas niveau.

Je pense que passer les plugins en docker à bcp plus d’intérêt dans un premier temps (et intégrer docker nativement au core)

9

Pas faut sur le sockets mais comme tu le dis le coup des ports moi ça me refroidi pour mon démon de plugin

10

Si tout le monde prend un port libre dynamiquement au démarrage du démon aucun problème :

public static function getFreePort() {
		$freePortFound = false;
		while (!$freePortFound) {
			$port = mt_rand(1024, 65535);
			exec('sudo fuser '.$port.'/tcp',$out,$return);
			if ($return==1) {
				$freePortFound = true;
			}
		}
		config::save('socketport',$port,'unifi');
		return $port;
	}
1 « J'aime »
11

Voilà, on peut s’arrêter là :wink:

Blague à part, je suis d’accord; cela pourrait même être inclus au core je trouve ainsi plus de soucis.
Mais on a déjà eu cette conversation il y a quelques années…

12

Blague a part pourquoi ce n’est pas intégré à la Doc :stuck_out_tongue_closed_eyes: