[Tuto] Utilisation de la fonction MQTT sur l’IPX800 V5

Objectifs de ce tuto :
A. Mettre en œuvre MQTT au sein de la V5
B. Publier sur le broker MQTT, le statut d’une variable au sein de la V5
C. Pour aller plus loin :
a. Mettre à jour une variable de la v5 en fonction d’un évènement extérieur
b. Modifier le statut d’un appareil extérieur à la V5

Prérequis :

  1. Disposer d’un broker MQTT (type Mosquitto ou autre)
  2. Installer un explorer de Topics MQTT (ex : MQTTLens – extension du navigateur Chrome ou MQTT Explorer …)
  3. Si vous souhaitez connecter des objets communicants à votre V5 en MQTT, vous devez connaitre les topics disponibles pour ces objets. Les topics sont de 2 natures :
    a. Topic d’information / interrogation d’état
    b. Topic de mise à jour de plus ou moins d’information de l’objet connecté

A. Mise en place de MQTT sur la V5 : Menu Système => MQTT

  1. Activer la fonction MQTT
  2. Précisez l’adresse et le port de votre broker MQTT
  3. Donnez un nom de Client MQTT, un nom d’utilisateur et le mot passe associés
  4. Activez la fonction SSL si votre broker n’est pas en local mais hébergé sur un Cloud
  5. Validez la configuration (aucun message d’erreur ne doit apparaitre sur le bas de la fenêtre une fois l’IPX800 V5 redémarrée)

B. Publication du statut d’une variable : Ex l’état d’un relai de la V5 lors de sa commande

  1. Activez MQTTLens, vous pouvez utiliser l’abonnement à tous les topics en utilisant le symobole # puis subscribe.
  2. Dans la V5, Menu Liens => Objets=> MQTT Publish
  3. Sur le Panneau de gauche, cliquez sur Ajouter MQTT Publish
  4. Ouvrir l’objet MQTT Publish créé en cliquant sur le bouton « Edition » :

Voilà votre 1er topic créé : cmd_café
Je choisis de créer une variable de pilotage nommée « state » de type IO
Le topic ne sera publié sur le broker Mosquitto QUE SI la variable « state » change d’état »
Lions pour l’exemple cette variable « state » à la commande d’un relai. Pour cela il faut écrire une rule:


image

NB : ceci ne peut pas être fait par lien en 5.4.0 En effet, seules les rules donnent accès à l’input 1.

Vérification du fonctionnement
a. Dans MQTTLens, abonnez-vous au topic « cmd_café »
b. Dans la vue relai cmd de la V5, actionnez la commande en appuyant sur la pastille correspondant au relai

image

c. Vérifiez dans MQTTLens, que vous voyez apparaitre :

image

C. Connaitre l’état d’un appareil extérieur et changer son état par MQTT
Pour cet exemple :

  • Je dispose d’un ShellyDimmer 2.
  • MQTT est activé sur l’appareil et est appairé au broker MQTT Mosquitto
  • J’ai cherché dans la doc Shelly les topics d’état publiés et les topics de commande de mon ShellyDimmer2
  • Avec MQTTLens, j’ai vérifié la publication des topics d’état et j’ai repéré les noms exacts des topics auxquels je dois abonner la V5.

a. Connaitre l’état d’un appareil extérieur

Principe de fonctionnement :
 L’appareil extérieur émet sur le broker à chaque changement d’état le statut de ses différentes variables ou set de variables.
 La V5 doit s’abonner (Subscribe) aux différents TOPICS d’état.

Créons notre 1er topic SUBSCRIBE :

D’après la doc Shelly, le topic « shellies/shellydimmer2-XXXXXXXXXX/light/0/status » renvoie un JSON comme suit :
{
« ison », /* whether the channel is turned ON or OFF /
« has_timer », /
whether a timer is currently armed for this channel /
« timer_started », /
unix timestamp of timer start; 0 if timer inactive or time not synced /
« timer_duration », /
timer duration, s /
« timer_remaining », /
if there is an active timer, shows seconds until timer elapses; 0 otherwise /
« mode », /
always white /
« brightness » /
output brightness, 1..100 */
}

Choisissons dans notre exemple d’obtenir le statut « ON/OFF » avec la variable « ison » et de connaitre l’intensité lumineuse avec la variable « brightness ».
Je déclare donc ces 2 informations dans le JSON à récupérer dans la V5.

Nous pouvons alors afficher le statut « ON/OFF » sur un Dashboard en créant le widget :

Remarque : vous pouvez aussi vous servir de cette variable dans les rules.

b. Changer l’état d’un appareil extérieur

Vous avez besoin de connaitre les commandes MQTT le permettant, dans notre exemple pour faire « ON/OFF », nous aurons besoin de la commande
shellies/shellydimmer-/light/0/set qui a besoin d’un JSON :
`
{
« brightness »: 100, /* output brightness 1…100 */

"turn": "on",       /* one of "on", "off", or "toggle" */
"transition": 500   /* One-shot transition, `0..5000` [ms] */

}`

Nous allons donc créer l’objet PUBLISH associé.
En version 5.04 du firmware de la V5, il n’est pour l’instant pas possible de créer un « on » ou « off » avec une IO (IO étant soit true, soit false). Il faut donc trouver une astuce pour l’instant.
Je crée donc 2 objets PUBLISH contenant 2 chaines de caractères « on » et « off » :

image
Turn = «off »

image

Turn = « on »

La clé « on/off » est une IO pilotée par dashboard (par ex) de la V5 et lors de l’envoi du Json, elle sera ignorée par le shelly dimmer.
Il faut alors introduire des rules afin de piloter ces IO :

image

Permet de contrôler la clé « on/off »

image

Permet de contrôler la clé « on/off »

Petites explications complémentaires sur le fonctionnement :

  1. If IO ON clé « on/off »
  2. Introduction d’un delai TA de 1s
  3. avant d’envoyer le OFF sur clé on/off
    ainsi on envoie ces 2 JSON :
    {"turn": "off", "brightness": 23, "on/off": true}

{"turn": "off", "brightness": 23, "on/off": false}

Idem pour « turn » : « on »
Le fait d’envoyer le 2eme JSON rend la solution toujours utilisable

10 « J'aime »

Hello @Jweb
Ça c est du tuto , clair et précis, on comprend bien la merci à toi
Cordialement

2 « J'aime »

Merci pour ce tuto @Jweb , clair et détaillé.

Je ne comprends pas trop ce NB, j’arrive à lier des I/O directement à l’entrée de MQTT Publish, ou c’est un problème d’accès à une sortie de l’IPX?

1 « J'aime »

Le nom de l’input1 est trop long c’est pour ça que le input 1 ne fonctionne pas par les liens.
Sinon on peut parfaitement lier une IO sur une input dans un objet MQTT sans passer par les rules.

Edit: remarque sans objet, voir l’explication dans les messages suivants.

1 « J'aime »

Bonsoir @patam et @Thierry_59

Dans le tuto, j’ai souhaité lier le Publish à la commande… et d’après mes tests ce n’est pas possible par lien mais uniquement par scénario.

Il est possible de lier un objet Publish à un relais state.

En effet le publish attend une entrée et de même pour le relai commande. C’est pour cela que le relai state existe qui lui fournit une sortie.

Donc oui, pour le réaliser par lien, il aurait fallu prendre le relais state et non le relai cmd. Ce n’était pas mon choix :sweat_smile:

Et on retrouve la logique inverse sur les objets Subscribe qui sont eux liables par liens à une commande relais et non à un relais state

ça peut même permettre d’envoyer une commande MQTT sur un relais depuis plusieurs autres clients MQTT vers le relais 1 (anenomètre ou capteur de pluie=>Fermeture volet) ou d’envoyer l’état d’un relais vers plusieurs autres client MQTT
image


A mon avis le fait d’utiliser une règle est plus élégante je trouves et sera bien plus facile à gérer dans le cas de scénario complexe par contre si les besoins sont limités mettre plusieurs « suscribe » en entrée d’objet à commander et plusieurs « publish » en sortie d’état d’objet à renvoyer peut suffire dans certains cas…

Donc oui, pour le réaliser par lien, il aurait fallu prendre le relais state et non le relai cmd. Ce n’était pas mon choix

Je dirais même plus pour le relais cmd il aurait fallu effectivement prendre un suscribe :yum: En tout cas merci pour le tuto qui amène des réponses avec un cas concret ici le Shelly, cela permet de transposer sur d’autres objets ! :+1:
Par contre je me pose la question du cas de figure ou peut être utile le « MQTT all » ? :thinking:

Bonjour,
Le MQTT all permet de plublier et de souscrire à un Topic en même temps.
Prenons l’exemple avec jedom, si vous utilisez un MQTT all vous êtes capable avec ce seul objet à la fois d’envoyer l’état d’un relais mais aussi de le piloter depuis jeedom, ça évite d’avoir 2 objet MQTT.

Bonjour,

Je rencontre des difficultés avec l’utilisation du MQTT.
Je possède 2 volets roulants Somfy que je pilote avec une box Tost Corp à l’aide du broken maqiatto en MQTT.
J’ai déclaré dans la fenêtre MANAGE MQTT mes différents paramètres qui ont l’air de fonctionner car je n’ai pas de messages d’erreurs en partie basse.
Mon objectif est d’utiliser le MQTT publish de la V5 pour piloter mes volets roulants et ne plus passer par l’application du téléphone.
voici comment fonctionne un volet en monté par exemple. Un volet est un topic. Je dois renseigner les infos suivantes : mail/volet1/u (u pour up).
Je n’arrive pas à comprendre comment paramétrer ça sur un objet publish. A quoi correspond URL et clé?

J’espère avoir été clair. Merci pour votre aide.

Bonjour @micou211187 ,

  • L’URL correspond à la dénomination de votre topic
  • les clés sont les 3 informations (mail/volet1/u) que doit contenir le publish.
    Je vous conseille de vous inspirer de mon tuto ci-dessus pour faire la montée et la descente de vos volets en rajoutant une IO de pilotage car le message ne sera publié qu’en cas de changement d’une variable :wink:

Bonjour,
Vous pouvez chercher sur le forum mqtt vous arrivez à

Cela devrez vous apporter des explications complémentaires
Bonne journée

Bonjour @Jweb et @cce66

Merci pour votre aide. Du coup avec vos explications, je touche du doigt la solution, enfin j’espère.
Pour l’URL et la clé, OK, ça fonctionne et je vois bien les messages arrivée dans le monitoring du MQTT.
Voici ce que j’ai fait :
MQTT

Mon dernier problème est le suivant:
Normalement lorsque j’envoi un ordre depuis mon application téléphonique, voila ce que je peux voir sur le monitoring:

Ecoute

Lorsque j’active une variable sur ma programmation, voici ce que j’obtiens au monitoring :

Comme indique dans votre tuto @Jweb , l’IO utilisé renvoi un message dès qu’il change d’état. Dans mon cas j’ai choisi de faire une impulsion.
Ce qui fait que ça ne fonctionne pas, c’est le nature du message reçu qui ne correspond pas.
Le Payload est entre guillement alors que sur un message classique il ne l’ai pas.

Merci à vous

Bonsoir @micou211187 ,

De ce que j’ai compris du besoin de la payload

  1. soit pour le mail une STR128 (par ex) contenant votre email
  2. soit pour volet : une STR32 (par ex) contenant le nom du volet que vous souhaitez actionner
  3. une STR32 contenant u pour le 1er objet publish (un 2eme objet publish doit contenir d)
  4. une IO volet-up (mon conseil pour actionner le publish) cette IO doit retomber 1s aprés pour que l’objet publish soit toujours disponible

Pour commander la montée faites passer à true l’IO volet-up depuis la V5 (soit par dashboard soit par scénario)
NB: le passage à false de l’IO fera un renvoi de l’objet Publish mais ce n’est pas grave car le message renvoyé sera identique (et l’IO sera ignorée dans l’interprétation de la payload - surtout si elle est en position finale)

Le 2eme objet publish pour baisser le volet:

  1. soit pour le mail une STR128 (par ex) contenant votre email
  2. soit pour volet : une STR32 (par ex) contenant le nom du volet que vous souhaitez actionner
  3. une STR32 contenant d
  4. une IO volet-down (mon conseil pour actionner le publish) cette IO doit retomber 1s aprés pour que l’objet publish soit toujours disponible

EDIT: Une solution plus élégante par la suite suivant évolution de la V5, serait d’enlever les IO et n’utiliser qu’un seul objet Publish en faisant un SET VAL sur la STR32 en l’affectant à u ou à d selon le besoin

@Jweb

Merci pour votre retour,
Si je comprend bien il faut que je paramètre mon objet comme ceci :

Capture d’écran 2022-01-02 205405

Ce que je ne comprend pas, c’est comme actionner le publish avec un IO (scénario) car les variables d’entrées sont du textes ? Quelques choses doit m’échapper.

Bonne soirée

voici un exemple pour l’objet Publish:

contenu de l’objet ouverture STR32:

Sur le dashboard vous pouvez mettre un bouton pour piloter l’IO volet-up
NB: l’IO doit avoir un TB = 1s
Pensez à faire un Subscribe pour connaitre l’etat du volet

Je comprends l’idée.

Je pense que le String 32 « ouverture » n’est pas nécessaire, si je ne me trompe pas, car j’ai besoin du mail/nom du volet/ordre de mouvement (u/d/s)

En effectuant ce paramétrage, voici ce que j’obtiens sur le monitoring :

Capture d’écran 2022-01-02 212058

C’est à la fois simple et complexe ce paramétrage.

Est-ce que cela fonctionne avec votre dernier paramétrage ?

Non pas du tout. la forme du payload n’est pas la bonne.
normalement je ne devrais pas y avoir les guillemets, true false, …
Après payload, il devrais juste y avoir la lettre u (pour une montée)

alors utilisez le paramétrage avec 4 variables que je vous ai indiqué :wink: il y aura bien u ds la payload

Oui et le résultat donne ça :
Capture d’écran 2022-01-02 212058

Les valeurs restes avec des guillements.

cela ne devrait pas donner ce résultat … seule la variable volet-up est en IO et peut repondre true or false, je vous invite à reprendre le paramétrage que je vous ai indiqué…
la variable ouverture (input 3 contient la string u)

L’objet publish doit reseembler à ca: