Je me permets d’ouvrir un sujet sur la gestion du MQTT et de l’ipx800v5. J’ai actuellement un ipx800v4 pour contrôler toute ma maison (volet + lumière) et j’hésite à passer au v5 cela me permettra de passer toute ma domotique en MQTT. Mais j’ai un soucis j’ai l’impression qu’on ne peut pas dire à l’ipx800 d’envoyer tous les events en MQTT et de prendre des ordres en MQTT. De ce que j’ai compris il faudrait que je fasse une scène pour chaque lumières et volet pour l’état ainsi que les commandes. Hormis le coté laborieux de l’histoire j’ai 48 lumières + 6 volets donc ça fait environ 108 scènes (une pour la remontée d’info + une pour la partie commande * 54).
Suis je passé a coté de quelque chose ? Avez vous peut etre une astuce ?
Bonjour,
quel intérêt avez-vous à tout passer en MQTT ?
MQTT est à réserver pour la communication entre matériels hétérogènes si vous avez une IPX au cœur de votre domotique. Ce que faisait la V4, la V5 peut le faire, en natif.
Quels matériels/logiciels avez-vous ?
Ça je comprends bien mais je voulais éviter le pulling toute les X secondes de l’ipx et faire en sorte que ça soit lui qui pousse les informations sur le MQTT.
En gros je cherche a passer toute ma domotique sur MQTT pour simplifier la gestion et uniformiser.
vous n’avez pas répondu aux questions matériels et logiciels, je vais donc faire des hypothèses
si vous avez Jeedom en tant que centrale domotique, vous pouvez utiliser le plugin de la V5, ce qui vous évite les Suscribe et Publish de MQTT. Le plugin étant développé par GCE, les flux sont optimisés).
Si votre IPX V5 est au cœur du système, il n’y a besoin de MQTT que pour les matériels non GCE.
C’est effectivement Jeedom qui est utilisé mais il y a aussi du nodered qui permet de gérer certaines fonction. Je pourrais effectivement demander a jeedom a travers le plugin ipx800v5 de renvoyer toute les informations sur MQTT pour que ca soit en suite prise en charge par nodered mais je trouve ca dommage surtout que l’ipx800v5 sait nativement faire du MQTT.
Vu le nombre d’IO possibles sur IPX800 V5, il est impossible d’envoyer toutes les valeurs en 1 fois, la trame serait bien trop longue (à construire et à émettre). Le nombre de Subscribe et de Publish est limité pour la préservation du bon fonctionnement de l’IPX (conso ressources)
MQTT doit être utilisé au coup par coup.
C’est dommage car ca permettrai d’etre compatible avec tout sans rien avoir a developper, c’est un protocole rapide en plus et fiable… Vraiment dommage.
Je dois vous avouer que moi aussi je pensais que chaque changement d’état d’un relais/volet ou autre était automatiquement poussé en MQTT et qu’on pouvait aussi piloter l’inverse en envoyant le message mqtt associé. On retrouve en effet cette fonctionnalité sur pas mal de solution, par exemple domoticz.
Citation @fgtoul
ll est impossible d’envoyer toutes les valeurs en 1 fois,
Il n’est pas question de pousser tout l’état de l’ipx en une trame, mais une trame par event sur des topics distincts genre /ipx/out/extension/x8r1/1 pour lire l’état du relais 1. Et écrire un 1 sur /ipx/in/extension/x8r-1/1 permet de passer le relais 1 à « On ».
C’est assez pratique pour les systèmes hétérogènes. Personnellement j’ai aussi du nodered (avec du mqtt), des équipements en wifi Xiaomi (pont miio ↔ mqtt), jeedom (sur mqtt), passerelle avec l’alarme pour lire l’état des zones (alarme ↔ mqtt) et de l’arduino (piloté par mqtt et me remonte la téléinfo et les températures des pièces en onewire).
@mamatdv j’avais pas vu ton post non plus. C’est exactement ça !
C’est aussi comme ça que ça marche en esp home, dans jeedom, dans tous ce qui est 2mqtt. En faite dans tous ce qui fait du mqtt.
pour moi l’ipx800v5 ne fait pas vraiment du MQTT, chez moi par exemple il faudrait pour pouvoir m’en servir que je fasse 108 scènes à la main. Et je pense que dire que c’est un automate et donc il n’a pas la puissance est une fausse excuse, j’arrive a le faire sur des puces qui valent moins de 1€ donc aucune raison que l’ipx800v5 n’ai pas la puissance nécessaire pour.
L’automate a beaucoup d’autres tâches liées à des interruptions donc prioritaires.
Générer systématiquement des trames, même scindées par fonctions ou types d’objets, pour plusieurs milliers de variables n’a pas de sens selon moi (ça n’engage que moi), c’est du gâchis de ressources.
Ça je peux plus le comprendre mais on peut faire autant de scène sur événement que l’on veut donc ça doit être possible quand même. L’idée c’est pas forcement d’envoyer les milliers de variable en mqtt mais juste de pouvoir choisir d’envoyer l’état des sortie (48 chez moi) et les volets (6). Ca fait donc 54 variables a envoyer ça fait pas énorme. Le pilotage depuis le MQTT n’étant a mon avis pas un probleme.
le MQTT est une nouveauté dans la gamme IPX et va certainement évoluer.
Mais avec la préparation des nouveaux produits attendus par la majorité, X-Pool, X-Display II, modules Connect, … je ne crois pas que cela soit en haut de la ToDoList.
oui l’ipx est permissive, mais vous serez tout de même limité par un nombre max de scènes et de règles qui a pour but de préserver les performances globales de l’ipx.
Essayez de mettre un push MQTT sur événement lié à un clignotant dont Ta et Tb sont réglés à quelques millisecondes puis répétez les tests sur plusieurs clignotants. Observez les réceptions sur votre broker, pas sûr qu’il reçoive tout.
Ce ne sera pas forcément l’ipx qui sera en faute, mais peut être votre broker ou votre réseau.
Je veux dire par là que systématiser un envoi MQTT sur événement aura forcément un impact.
Dans ce cas GCE pourrait integré un systeme de slow down. En gros pas d’envoi trop rapproché. C’est ce que fait jeedom pour beaucoup de chose, les démons recuperer les informations, les stocks et toute les 3s font l’envoi a jeedom. Si pendant les 3s l’information change seul le dernier état est conservé.
Il y a une possibilité de lui dire je veux les informations en temps réel bien pour ce genre de cas. Mais par exemple pour une lumière ou une remonté de puissance, avoir l’information en différé de 3s n’est absolument pas gênant et ça empêche les soucis de surcharge.
dans ce cas, juste rajouter un flag pour dire si l’on veut du push ou non permettrait de régler ce genre de problème et d’envoyer très facilement (sans mettre en place de scénario) la valeur pour les variables qui nous intéresse.
