Piloter IPX800-v5 dans Gladys

Ok donc en fait :

gladys/device/mqtt:commutateur/feature/mqtt:commutateur/state

quand gladys publie, le topic sur mosquito c’est gladys et il y a en clés
device/commutateur/feature
device/commutateur/state

gladys/master/device/mqtt:commutateur/feature/mqtt:commutateur/state

quand gladys reçoit, le topic sur mosquito c’est toujours gladys et il y a en clés
master/commutateur/feature
master/commutateur/state

En fait c’est le coté device/master(car on a pas d’indication du sens d’envoi des données) qui trompe :exploding_head:, slave/master (pas top) ou publish/suscribe (plus cohérent car cela indique le sens de l’envoi des données de façon implicite car le « device » comme « master » est à la fois master et slave dans le comportement !

Dans ce cas je pense que tout le monde s’accordera pour dire qu’il faudrait que les 2 adresses soit affichées de base et que si on coche “Est-ce un capteur ?” seule la ligne correspondante s’affiche !
Effectivement c’est quand implemente dans node-red qu’il faut faire attention à bien mettre dans les objets mqtt la bonne ligne ! :wink:

Sur le fond, je suis assez d’accord avec ton analyse.
Néanmoins, dans notre cas, avec Gladys, on peut faire l’hypothèse que c’est notre point central (box domotique) qui pilote le reste et qui gère tout l’aspect logique/ordonnancement. Dans ce contexte, il est assez logique de nommer ce nœud principal « master ».
Je ne veux pas trop m’avancer, mais je pense que c’est la logique qui a menée à choisir ces dénominations.

Je plussois cette partie, il me semble que ce bouton soit régulièrement source d’incompréhension sur le forum. Il faudrait peut-être créer un autre topic pour en discuter ?

Oui si effectivement gladys et mosquitto sont hébergés sur la même machine on peut le voir comme un point central mais le serveur mosquitto deployé par gladys dans la machine sur lequel il tourne fait également office de serveur pour d’autres clients qui ne passe pas par gladys et si gladys passe par un autre serveur mosquitto (ce qui est possible puisque paramétrable, par exemple chez moi j’ai un autre nuc sur lequel est hébergé Home-assistant sur lequel tourne mosquitto). Et si le noeud principal est « master » la logique aurait voulu que les devices soient …slave ! :roll_eyes:

Je confirme j’ai mis un bout de temps à comprendre ce point là alors que j’ai déployé sans problème un flow node-red sur home-assistant qui interagis avec mon module domotique IPX800V5 (ce module intègre des objets mqtt « suscribe » et « publish »).

Oui 100% d’accord, c’est un problème d’UX :slight_smile: Il y a déjà une issue Github qui a été créé =>

Bon alors bonne nouvelle enfin presque (now j’ai plus de cheveux ! :rofl:)
J’ai enfin réussi à avoir le fonctionnement dans les deux sens (relais IPX800V5 <=> Gladys) en utilisant des “commutateur” (ajouter le relais serait bien car pour moi commutateur=interrupteur :thinking:)

image

et pareil coté IPX800V5

image

les suscribe MQTT coté IPX800V5

image

image

les publish MQTT coté IPX800V5

image

image

le flow graphique


et le debug dans l’ordre :
Relais 1 “On” depuis l’IPX800V5
image
Relais 1 “Off” depuis l’IPX800V5
image
Relais 1 “On” depuis Gladys
image
Relais 1 “Off” depuis Gladys
image
Et le flux au format json

 [{"id":"cf6dc2aae7c8ab92","type":"tab","label":"Flow 3","disabled":false,"info":"","env":[]},{"id":"91ee9c360eac6d43","type":"mqtt out","z":"cf6dc2aae7c8ab92","name":"IPX800_V5-1","topic":"IPX800_V5-1","qos":"1","retain":"false","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"291914c5c9c68f02","x":1230,"y":100,"wires":[]},{"id":"c2659b7b2ff21d6e","type":"function","z":"cf6dc2aae7c8ab92","name":"selon payload \"[IPX]Relay state x\" true/false => 0/1","func":"var msg1,msg2;\n\nswitch (msg.payload) {\n    \n  case \"{\\\"[IPX]Relay state 1\\\":true}\":\n    msg1 = {payload:\"1\" };\n    break;\n  case \"{\\\"[IPX]Relay state 1\\\":false}\":\n    msg1 = {payload:\"0\" };\n    break;\n    \n  case \"{\\\"[IPX]Relay state 2\\\":true}\":\n    msg2 = {payload:\"1\" };\n    break;\n  case \"{\\\"[IPX]Relay state 2\\\":false}\":\n    msg2 = {payload:\"0\" };\n    break;  \n    \n  default:\n    break;\n}\n\nreturn[msg1,msg2];\n","outputs":2,"noerr":0,"initialize":"","finalize":"","libs":[],"x":450,"y":220,"wires":[["d7e02d71312aa03e"],["6ea07d03df94f62e"]]},{"id":"d9a7d3602448c88a","type":"mqtt in","z":"cf6dc2aae7c8ab92","name":"IPX800_V5-1","topic":"IPX800_V5-1","qos":"1","datatype":"auto","broker":"291914c5c9c68f02","nl":false,"rap":true,"rh":0,"inputs":0,"x":150,"y":220,"wires":[["c2659b7b2ff21d6e"]]},{"id":"d7e02d71312aa03e","type":"mqtt out","z":"cf6dc2aae7c8ab92","name":"gladys/master/device/mqtt:IPX800_5-1_Relais1/feature/mqtt:IPX800_5-1_Relais1/state","topic":"gladys/master/device/mqtt:IPX800_5-1_Relais1/feature/mqtt:IPX800_5-1_Relais1/state","qos":"1","retain":"false","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"291914c5c9c68f02","x":1000,"y":180,"wires":[]},{"id":"6ea07d03df94f62e","type":"mqtt out","z":"cf6dc2aae7c8ab92","name":"gladys/master/device/mqtt:IPX800_5-1_Relais2/feature/mqtt:IPX800_5-1_Relais2/state","topic":"gladys/master/device/mqtt:IPX800_5-1_Relais2/feature/mqtt:IPX800_5-1_Relais2/state","qos":"1","retain":"false","respTopic":"","contentType":"","userProps":"","correl":"","expiry":"","broker":"291914c5c9c68f02","x":1000,"y":260,"wires":[]},{"id":"4dc3520e0af08d51","type":"mqtt in","z":"cf6dc2aae7c8ab92","name":"gladys/device/mqtt:IPX800_5-1_Relais1/feature/mqtt:IPX800_5-1_Relais1/state      .","topic":"gladys/device/mqtt:IPX800_5-1_Relais1/feature/mqtt:IPX800_5-1_Relais1/state","qos":"1","datatype":"auto","broker":"291914c5c9c68f02","nl":false,"rap":true,"rh":0,"inputs":0,"x":350,"y":80,"wires":[["1bedbf53cbd0b7c2"]]},{"id":"e51228ced7b818c2","type":"mqtt in","z":"cf6dc2aae7c8ab92","name":"gladys/device/mqtt:IPX800_5-1_Relais2/feature/mqtt:IPX800_5-1_Relais2/state","topic":"gladys/device/mqtt:IPX800_5-1_Relais2/feature/mqtt:IPX800_5-1_Relais2/state","qos":"1","datatype":"auto","broker":"291914c5c9c68f02","nl":false,"rap":true,"rh":0,"inputs":0,"x":360,"y":140,"wires":[["1bedbf53cbd0b7c2"]]},{"id":"658e6d08a9bfa70c","type":"mqtt in","z":"cf6dc2aae7c8ab92","name":"#","topic":"#","qos":"2","datatype":"auto","broker":"291914c5c9c68f02","nl":false,"rap":true,"rh":0,"inputs":0,"x":130,"y":300,"wires":[["0b066345aae7ddb9"]]},{"id":"0b066345aae7ddb9","type":"debug","z":"cf6dc2aae7c8ab92","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":340,"y":300,"wires":[]},{"id":"1bedbf53cbd0b7c2","type":"function","z":"cf6dc2aae7c8ab92","name":"selon topic => [IPX]Relay cmd x : true/false","func":"var msg1,msg2;\n\nswitch (msg.topic) {\n  case \"gladys/device/mqtt:IPX800_5-1_Relais1/feature/mqtt:IPX800_5-1_Relais1/state\":\n    \n    switch (msg.payload) {\n      case \"0\":\n        msg1 = {payload:\"{\\\"[IPX]Relay cmd 1\\\":false}\" };\n        break;\n      case \"1\":\n        msg1 = {payload:\"{\\\"[IPX]Relay cmd 1\\\":true}\" };\n        break;\n      default:\n        break;\n    }\n    break;\n    \n  case \"gladys/device/mqtt:IPX800_5-1_Relais2/feature/mqtt:IPX800_5-1_Relais2/state\":\n\n    switch (msg.payload) {\n      case \"0\":\n        msg1 = {payload:\"{\\\"[IPX]Relay cmd 2\\\":false}\" };\n        break;\n      case \"1\":\n        msg1 = {payload:\"{\\\"[IPX]Relay cmd 2\\\":true}\" };\n        break;\n      default:\n        break;\n    }\n    break;\n    \n  default:\n    break;\n}\n\nreturn[msg1,msg2];","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":860,"y":100,"wires":[["91ee9c360eac6d43"]]},{"id":"291914c5c9c68f02","type":"mqtt-broker","name":"mqtt://localhost","broker":"mqtt://localhost","port":"1883","clientid":"","autoConnect":true,"usetls":false,"protocolVersion":"4","keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","birthMsg":{},"closeTopic":"","closeQos":"0","closePayload":"","closeMsg":{},"willTopic":"","willQos":"0","willPayload":"","willMsg":{},"sessionExpiry":""}]

J’ai des latences voire des non prise en compte si les ordres sont fait trop rapidement mais si on attend pas de souci cela fonctionnes très bien par contre depuis un node red dans home assistant donc homea assistant <=> IPX800V5 pas de latence !
Par contre depuis Gladys cela génère 4 message sur le debug au lieu de 2 quand c’est depuis l’IPX800V5

@pierre-gilles
Bon pour le coup je vais faire un tuto et sur le site de Gladys et sur le site de GCE pour montrer comment faire une passerelle via node-red entre gladys et l’IPX800V5 (en lien direct ça passe pas dans l’IPX800V5, la chaine mqtt est trop longue) sinon tu connais MQTT Essentials - Part 1 | Introduction to MQTT - YouTube faite par un des membres du comité des spécifications MQTT par contre pour les boutonneux du rosbeef c’est pas sous-titré :rofl:

Très bizarre ! Tu confirme que les conditions sont les mêmes (home assistant/node-red/Gladys sont sur la même machine ?), Gladys ne faisait rien de spécial ?

Top, merci @cce66 ! :pray:

@pierre-gilles


Je pense que ce serait plus simple aussi de ne pas mettre la partie “mqtt:” de “ID externe de la fonctionnalité” dans le topic, cela n’a pas de sens pour moi et ca rallonges le topic et sur l’ipx800v5 ca devient trop long ! (pas trouvé si il y a une limite pour le topic)
par exemple en renommant IPX800V5-1 en IPX800V5

gladys/device/mqtt:IPX800V5_Relais1/feature/mqtt:IPX800V5_Relais1/state

deviendrait

gladys/device/IPX800V5_Relais1/feature/IPX800V5_Relais1/state

voire (selon la norme MQTT)

gladys/device/IPX800V5_Relais1/state

De même

gladys/master/device/mqtt:IPX800V5_Relais1/feature/mqtt:IPX800V5_Relais1/state

devriendrait

gladys/master/device/IPX800V5_Relais1/state

Ca me parait plus clair là tout de suite non ? :wink:

Et comme les Dupont et Dupont je dirais même plus :

IPX800V5 souscrit à “Gladys\commutateur\state” (payload 0 ou 1 / on ou off / true ou false)
Gladys publie sur “Gladys\commutateur\state” (payload 0 ou 1 / on ou off / true ou false)
Si par scène ou dans la discussion je dis à Gladys “ouvre le relais” Gladys ouvre le commutateur
et publie l’état du commutateur, l’IPX800V5 est informé et bascule son relais et lycée de Versailles !

Gladys souscrit à “IPX800V5\Relais1\state” (payload 0 ou 1 / on ou off / true ou false)
IPX800V5 publie “IPX800V5\Relais1\state” (payload 0 ou 1 / on ou off / true ou false)
Si le relais de l’IPX800V5 est commuté par programmation dans l’IPX800V5 celui-ci publie l’état de son relais, Gladys est informé et bascule son commutateur
Le tout avec le QOS à 1 pour éviter les boucles

Donc dans Gladys on a

  • une souscription à l’état du Relais1 de l’IPX800V5 (“IPX800V5\Relais1\state”)
  • une publication de l’état du commutateur de Gladys (“Gladys\commutateur\state”)

Et dans l’IPX800V5 on a

  • une souscription à l’état du commutateur de Gladys ( “Gladys\commutateur\state”)
  • une publication de l’état du Relais1 de l’IPX800V5 (“IPX800V5\Relais1\state”)

On appréhende mieux cela si on considère que le broker mosquito ne sert qu’à stocker et transmettre les messages que des clients (publieurs) envoient à d’autres clients (souscripteurs) et que donc les clients peuvent indifféremment être à la fois publieur et souscripteur mais il faut à chaque fois bien préciser l’id du client émetteur de la publication et l’id du client receveur de la publication (Gladys et IPX800V5) :exploding_head:

Tout cela n’étant valable que si il n’y a pas une raison objective de faire autrement ! :thinking:
Donc même si Gladys tient un rôle de ‘master’ et pilote les périphériques ‘esclaves’ qui lui sont associés d’un point de vue mqtt il reste un client de mosquitto comme les autres périphériques !

En fait tu veux retirer le préfix obligatoire « mqtt: » sur l’ID externe, c’est plus une question d’ID externe que de topic MQTT.

A la base on a mis ce préfix car cet ID externe est unique en DB à tous les device dans tout Gladys, et on ne veut pas que plusieurs intégrations puissent entrer en collision, vu que l’intégration MQTT est la seule intégration ou l’utilisateur choisit cet ID externe.

Après je suis d’accord que niveau lisibilité c’est moins clean, et ça fait ces problèmes de topics trop long. A débattre avec l’équipe. @AlexTrovato T’en pense quoi ? (retirer le préfix « mqtt: » obligatoire pour les nouveaux périphériques MQTT)

C’est exactement ça :slight_smile:

En fait l’idée de master ce n’est pas que Gladys est « master », je pense que tu as mal compris cette notion de l’API car tu n’as pas tout l’historique de la conception : un des développements futurs de la v4 (bon après c’est du très long terme), c’était d’avoir une notion d’instance « maitre », et d’instances « pods »

L’idée c’était d’avoir théoriquement des « mini gladys » qui puissent tourner sur d’autre machine pour pouvoir contrôler des appareils distants.

Ainsi, Gladys ne serait pas juste une instance mais un réseau de plusieurs instances, dont 1 maitre et X pods.

On a conçu l’API pour pouvoir indiquer que tu parles à Gladys « master » :

gladys/master/**

Ou à une instance pod:

gladys/pod/ID_DU_POD/**

Néanmoins, cette notion n’étant pas développée, je ne t’en ai pas parlé pour ne pas t’embrouiller :slight_smile:

Mais je t’assure que toute cette API c’est des mois de réflexion et de travail, rien n’est dû au hasard ! Je t’invite à relire les discussions sur le forum de la conception, tout est publique.

J’ai pas trouvé dans les docs sur mqtt cette obligation ? c’est dans la 5 ? En tout cas cela marches parfaitement sans dans l’exemple mis plus haut entre l’IPX800 et nodered !

Là ok cela a du sens « gladys\master » « gladys\pods » et « gladys\device » avec ensuite des propriétés et des méthodes ! On est bien dans l’internet des objets ! :grinning:
D’ailleurs en réfléchissant :thinking: au vu de ces infos…l’IPX800V5 est quelque part …un mini-pods ! :smirk:

Bonjour @pierre-gilles

Après beaucoup de sueur, j’ai enfin réussi à piloter l’IPX800V5 depuis Gladys, voici le tuto !

Et le même sur le forum de GCE histoire de faire connaitre Gladys aux possesseurs d’IPX800V5, je pense que la partie Gladys plus pourrait vraiment les intéresser ! :wink:

J’espère avoir publié au bon endroit.
Par contre, coté reco vocale j’ai vu cela, c’est récent et ca a l’air performant
https://hub.docker.com/r/alphacep/kaldi-vosk-server
https://hub.docker.com/r/alphacep/kaldi-fr

Ce serait intéressant d’étudier la question de le déployer dans gladys ! Je vais essayé de le déployer sur mon nuc et voir comment « jouer » avec. C’est vrai que cela manques par rapport à la v3 !

1 « J'aime »

J’ai bougé le tutoriel dans la catégorie « tutoriel » du forum :slight_smile:

Bravo pour le tuto, c’est top !

Bah si cela peut faire avancer le schmilblick :+1: et le coté IPX couplé au Zigbee via Gladys est complémentaire (manques plus que la reco vocale… :crazy_face:)
Je vais en faire un autre car sur node-red il y a un module sun-calc qui permet de calculer la position du soleil et couplé aux capteurs température ça peut faire des scénario intéressant avec le module de volet roulants de GCE Pilotage volets roulants - X4VR qui est pilotable en mqtt via l’IPX800V5 ! :wink:

Par contre @pierre-gilles, il y a t-il des boutons qui pourrait faire le job par rapport aux volets roulants ?

Non! Il y a 2 demandes de fonctionnalités qui vont dans ce sens:

Et de manière plus complète:

C’est pour cela que j’ai préféré automatiser mes volets avec mon IPX car j’ai des retour d’états que je peux gérer via MQTT et donc utiliser dans Gladys !

Et avec node-red il y a également ce module qui permet pas mal de possibilités pour gérer les VR, finalement l’intégration de node-red avec Gladys est :+1:

flows.nodered.org

node-red-contrib-blindcontroller-v2

A collection of Node-Red nodes that automates the control of household roller blinds on the current position of the sun

Et on peut connaitre la position du soleil sur les volets ici Calcul de la position du soleil dans le ciel pour chaque localisation à importe quel moment

Manque plus que le bouton qui va bien dans gladys !

Comme qui dirait il manques plus à Gladys que la parole…et la reconnaissance vocale ! :wink:

Pour gérer les volets et les moteurs il y a aussi Tasmota : Shutters and Blinds - Tasmota

Pour le coup, l’intégration dans Gladys est automatique mais il manque pour être parfait soit le bouton à impulsion soit les boutons “Monter et Descendre” comme l’a proposé @syper dans cette demande d’intégration : Gestion des volets roulants - #16 by pierre-gilles

Le seul défaut pour moi dans le mode 1 de Tasmota est que le temps de commutation entre “Monter” et “Descendre” est fixé en dur dans le code à 50 ms. Un peut juste pour des relais, et dans certain montage avec triac et même mosfet.

Je connais pas tasmota, il y a un module VR ? Car je préfères une solution qui soit ok en cas de problèmes (incendie) car les assurances dans ce cas cherchent toujours à t’enfumer :sob: en disant que t’as fait du bricolage ! :triumph:

Je confirme que je viens d’améliorer l’UX de la vue MQTT en affichant les 2 topics lorsque l’option est désactivée :slight_smile:

Actionneur:

Capteur:

Pour l’instant c’est dans une PR, ça partira dans la prochaine mise à jour de Gladys.

Je confirme que l’amélioration d’UX est dispo dans Gladys Assistant 4.8 :