Passage au MQTT convaincant

Je voulais juste faire un petit retour d’expérience sur mon passage au protocole MQTT, après avoir éclaté ma clé Zwave sans avoir fait de sauvegarde avant :stuck_out_tongue:

Pourquoi ?
4 raisons de franchir le pas, 1) La curiosité, 2) Décharger mon Pi hébergeant Jeedom, 3) Facilité le bidouillage, 4) Supprimer mes problèmes avec Zigbee et Zwave.

Comment ?
L’organisation en rapport au MQTT se fait comme suis :

  • 1 Pi 4 pour Jeedom (+rfx, teleinfo, jeeRhasspy…) et le plugin jMQTT
  • 1 Pi 3 pour un Docker Mosquitto (1 seul broker pour tout ce qui est MQTT)
  • 1 Pi 4 pour un Docker Rhasspy Serveur (utilisant MQTT avec Hermes)
  • 1 Pi zero avec la clé Conbee2 monté en Docker zigbee2mqtt,
  • 1 Pi zero avec la clé Zwave monté en Docker zwave2mqtt
  • des Pi un peu partout pour les Squeezebox et les satellite Rhasspy, des NAS, etc…

Il me manque encore le bluetooth avec une clé Sena qui va arriver ces jours et que je voudrais monter en MQTT également.

Images

Vue du broker depuis MQTT explorer :
jmqtt_broker
Vue du maillage Zigbee : (je n’ai aucun répéteur, que des contacts)


Vue du maillage Zwave : (62 modules ici, il m’en reste 10 à réinclure)

Conclusion :
Il est encore tôt pour le dire, mais à première vue je suis époustoufler par le résultat. Transition finalement assez facile, meilleur répartition des charges systèmes, vitesse d’exécution plus rapide, Plus grande souplesse sur les modifications, màj, redémarrages, etc… Que du bon pour l’instant. En passant, j’ai pu placer ma clé Conbee en plein centre de la maison, j’ai pu me promener dans la maison avec mon Pi Zwave pour réinclure tous mes modules, je vais pouvoir placer ma clé enOcean dans mon local extérieur.
Je peux surveiller tous mes échanges depuis MQTT explorer ou MQTT Fx. Je peux avoir un second Jeedom (ou autre) branché sur le même broker pour tester :slight_smile:
En point négatif (même si je n’ai pu encore pu le constater) cela rajoute des étages dans le transfert et le traitement des informations avec ajout de deux protocoles (passage par MQTT et par le Wifi) donc plus de chances de rencontrer des problèmes.

Il me reste aussi à voir si il existe quelque chose pour les protocol rfx et téléinfo avec le materiel que j’ai.

#MyTwoCents
JC

5 « J'aime »

Ca fait un sacré budget Raspberry :rofl: :rofl:

Tu t’es basé sur ce post : OpenZwave 1.6 - Zwave2Mqtt - JMQTT ?

J’hésite encore à franchir le pas, vu que ca fonctionne chez moi, mais openzwave bloqué en 1980, ca commence à me poser des soucis avec certains modules…

Oui et non. Je me suis inspiré du github de z2m.
Et ce n’était pas pour du matos incompatible mais plus pour des petits bugs qui m’enervaient à la longue.

Pour le budget Pi, je les ai acheté au fil du temps suivant les promo donc finalement c’est quasi transparent.

Tu aurais un lien ??
Ca m’interesse !

Une petite recherche sur le net avec comme mots clés docker, mosquitto, zwave2mqtt, jmqtt, jeedom devrait t’aiguiller, il y a pas mal d’exemple. Je suis plutôt une brelle pour tout ça, j’ai installé mon premier Docker que très récemment (d’ailleurs en passant j’ai découvert Portainer qui est très bien pour gérer tout ça). Bref j’ai trouvé tout ce qu’il fallait et en plus ça fonctionne :stuck_out_tongue:

|
|
|

Pour exemple de la simplicité, pour la partie zwave2mqtt voila la manière rapide sur un pi zero tout frais. Tu branches ta clé zwave, tu te connectes en ssh et tu enchaines tout ça :
On commence par installer Docker :

curl -sSL https://get.docker.com | sh
sudo usermod -a -G docker $USER
sudo reboot

Sur le Pi zero il faut passer docker en experimental pour avoir la bonne version de Z2M :

sudo nano /etc/docker/daemon.json

dans ce fichier tu mets :

{
  "experimental": true
}

Enregistres et enchaines avec les commandes :

sudo systemctl restart docker

Puis on install zwave2mqtt :

mkdir store
docker pull robertslando/zwave2mqtt:latest --platform linux/arm/v6
docker run -it -p 8091:8091 --device=/dev/ttyACM0 -v $(pwd)/store:/usr/src/app/store robertslando/zwave2mqtt:latest

Et voila, plus qu’à se connecter à l’interface web IP_DU_PI_ZERO:8091 et régler les paramètres de ton brocker. Tu rentre les mêmes info de brocker dans jMQTT et voila, tout est relié. Ensuite il y a quelques post ici (comme celui que tu as cité) ou tu trouveras des infos pour créer tes equipements.

1 « J'aime »

Pour ceux que ça intéresse, voici un complément avec docker-compose


version: '3.7'

services:
  mqtt-master:
    image: <Votre image avec un server MQTT>
    container_name: mqtt-master
    networks:
    - mqtt
    ports:
    - 1883:1883 #Uniquement si besoin d'avoir le port exposé
    restart: always
    deploy:
      replicas: 2
      update_config:
        delay: 10s
        order: start-first
      restart_policy:
        condition: any
    healthcheck:
      test: "mosquitto_sub -t '$$SYS/#' -C 1 | grep -v Error || exit 1"
      interval: 5s
      timeout: 5s
      retries: 3

# La configuration dans zwave2mqtt sera le nom du service docker
  zwave2mqtt:
    image: robertslando/zwave2mqtt:latest
    container_name: zwave2mqtt
    networks:
    - mqtt
    ports:
    - 8091:8091 #Uniquement si besoin d'avoir le port exposé. Si seul le mqtt utilise ce service, l'exposition n'est pas utile, on passe par le sous réseau docker "mqtt"
    volumes:
    - /nfs/volumes/zwave2mqtt:/usr/src/app/store  # remplacer /nfs/volumes par l'emplacement du volume souhaité
    restart: always
    devices:
    - /dev/ttyACM0
    deploy:
      replicas: 1
      update_config:
        delay: 10s
      restart_policy:
        condition: any

  zigbee2mqtt:
    <Le code en dessous>

# On peux ajouter également Node-red. permettant une gestion de mqtt native
  node-red:
    image:  nodered/node-red
    container_name: node-red
    networks:
    - mqtt
    volumes:
    - /nfs/volumes/nodered:/data  # remplacer /nfs/volumes par l'emplacement du volume souhaité
    deploy:
      resources:
        limits:
          cpus: '0.75'
          memory: 150M
        reservations:
          cpus: '0.25'
          memory: 40M
      replicas: 1
      update_config:
        delay: 10s
      restart_policy: 
        condition: any
    healthcheck:
      test:
      - CMD
      - curl
      - -f
      - http://localhost:1880
      interval: 1m
      timeout: 10s
      retries: 3
      start_period: 10s

networks:
  controlleurs:
    name: controlleurs
    driver: overlay
    attachable: false # True pour que le réseau soit attachable par une autre stack

en espérant que cela peut aider :slight_smile:

4 « J'aime »

2 semaines se sont écoulés et ça tient toujours. jMQTT n’a pas bronché et la charge du Pi Jeedom reste très basse.

Quelques bugs avec les volets, j’ai un module Fibaro ou j’ai du mal à faire remonter les valeurs mais déjà sous ozw1.4 donc c’est plus le module qui est foireux. J’ai également réussi a passer les clefs Conbee2 et Zwave sur le même Raspberry (il faut juste surveiller que les /dev/ttyACM0 et ACM1 ne s’inversent pas entre les deux clefs au reboot, sinon il suffit des les débrancher et rebrancher dans le bon ordre.)

Ce week-end j’ai galéré à faire fonctionner le bluetooth en MQTT, piZero très mal supporté donc pas de Docker dessus mais du venv…, clé USB Sena UD100 capricieuse sur mon pi3, etc… Bref j’y suis quand même arrivé et ça à l’air de fonctionner.
PS: En passant plus jamais je me plaindrais du plugin Blea du coup :smiley: Je tire mon chapeau au dev.

Petite vue de mes premiers test du BLE sous MQTT explorer :

Reste le enOcean que je n’ai pas eu le temps de faire. Et je suis tombé sur des sujets pour passer la téléinfo vers MQTT :stuck_out_tongue: ça se tente.

Sympa le MQTT explorer

1 « J'aime »

Encore une semaine de passé, je continue mon petit bonhomme de chemin avec le plugin jMQTT.
Cette semaine j’ai passé le monitoring des mes Raspberry sous MQTT et comme toujours ça marche impec !

Un mini script pyhton lancé en systemd sur chaque Raspberry envoie les infos au broker.

Que je récupère ensuite dans le plugin jMQTT.

Et je passe par un virtuel, avec une comparaison de temps pour définir si il est mort ou pas.

Et le résultat dans un design.

PS: Je suis un buse en python mais si ça vous intéresse d’avoir le script que j’utilise, le voici.
rpi2mqtt.py.txt (4,6 Ko)

3 « J'aime »

Merci du retour

ça ne manque pas de PI chez toi :rofl:

alors petite optimisation pour Python ou MicroPython

lorsque tu utilise une fonction d’une librairie

exemple avec time/sleep

au lieu d’écrire

import time
et
time.sleep....

fait plutôt

from time import sleep
et
sleep...

ça économise de l’écriture et evite d’importer toutes les fonction dont tu n’a pas besoin

have a fun :100:

1 « J'aime »

L’avantage du Pi est qu’il change de fonction tous les 6 mois chez moi :sweat_smile: Et que ça peut servir à tout !
Merci pour l’optimisation, il faut vraiment que je prenne le temps d’apprendre un peu ces langages…

1 « J'aime »

Je vais vous raconter ma vie, encore… :grin:
Une semaine s’est écoulée et je n’ai pas fait grand chose, je suis quand même passé de 4 raspberry à 2 seulement dans mon rack. Le MQTT ne consommant quasi rien en ressource !
J’ai rassemblé tout le nécessaire au MQTT sur un seul Pi, tandis que le second me sert pour Jeedom, LMS et Rhasspy Serveur. Et ça a été assez simple de redémarrer le Zwave ou Zigbee sans rien perdre.

Vue des containers MQTT :

J’en ai quand même profité pour passer la téléinfo vers le plugin jMQTT. Le cumulus et le délestage fonctionnent toujours. :sweat_smile:


Résultat dans le design :
jmqtt_teleinfo_design
Et la vue depuis MQTT explorer :

Dans la semaine je recois deux Hat UPS que je vais mettre dans le rack, et toujours géré depuis MQTT :slight_smile: Je reviendrais faire la présentation du résultat ici.

Salut,

Dans le même genre d’idée, j’ai viré le plugin monitoring (de phifi) et je passe par un truc custom en python/mqttt pour mes pi, c’est vraiment plus léger et efficace ! Par contre pas vraiment possible de mettre ça sous docker (et c’est bien dommage).
Dans le même genre d’idée, j’ai viré les plugins blea et detection téléphone (remplacé par le scanner BT/BLE dispo ici [TUTO] Scanner Bluetooth (BLE ou non) - Forum Communauté Jeedom). Techniquement il fonctionne mais est un peu lourd et il faut créer systématiquement des commandes action on/off (ç c’est pénible)… Je vois que tu utilises bt-mqtt-gateway, ça marche pour les 2 BT et BLE ? J’ai besoin de gérer uniquement de la présence …

Pour le BT je ne l’utilise que pour de la présence, mais normalement ça marche pour tout. Par contre il faut connaitre l’adresse MAC de chaque appareil et la renseigner dans un fichier config sur chaque antenne. Pas le plus user-friendly mais ça marche.

Et si tu relis mon poste pour le monitoring, idem j’ai supprimé les plugins et je passe par des script python sur chaque Pi. Et comme précédemment, pas hyper user-friendly car il faut refaire les manip pour chaque Pi à surveiller. Mais une fois en place c’est transparent et ça prend 0 ressource.

1 « J'aime »

ça c’est une bonne nouvelle

Connaitre l’adresse MAC, c’est pas le plus pénible. Pour la config partout, à voir comment faire pour faire de la synchro (rsync ou push)… Je vais jeter un oeil

De ce coté là l’utilisation d’un container simplifie la vie (pas besoin de gérer les dépendances, les versions python etc)… mais bon monitorer le container c’est pas le but. J’ai quelques scripts qui compensent par contre

Encore une semaine de passée. J’ai enfin transferé mon dernier protocole vers le plugin jMQTT.
Les sondes et télécommande RFX passent désormais par MQTT. Ça a été à la fois facile et compliqué. Facile car je n’ai que des equipements en réception j’ai donc trouvé un simple script python de quelques lignes aidé de la librairie pyRFXtrx et la remonté se fait. Compliqué car les télécommandes DIO Chacon ne lève pas de trigger dans jMQTT si on appuie plusieurs fois sur le même bouton, il a fallu adapter un scénario qui fait retomber les valeurs… Bref ça marche.

Vue dans MQTT explorer :


Vue d’un équipement Rfx dans le plugin jMQTT :

Tous les principaux protocoles et monitoring sont passés dans le plugins jMQTT, ce qui fait plus de 130 équipements dans le plugin, il me reste a consolidé tout ça, j’ai encore quelques bugs de mise à jour d’information mais qui sont plus dû à ma mauvaise connaissance du MQTT. Mon Jeedom est désormais plus léger, plus homogène, plus soyeux :stuck_out_tongue: Je n’ai plus à m’occuper du matériel dedans, uniquement des scenarios, interactions et design.

Après cela reste un test, je vais tourner quelques mois comme ça, voir si c’est une bonne solution, solide et évolutive…

PS: Du coup je suis passé de 4 à 2 Raspberry dans mon rack Domotique ! Un pour Jeedom/LMS/Rhasspy et un pour MQTT.

Salut,

As tu un retour d’expérience à partager après deux mois de protocole en mqtt ?

Merci

Salut, oui, ça tourne en prod chez moi. Chauffage inclus.
Je n’ai pas eu de gros soucis. Quelques ratés mais que j’avais déjà avant comme sur un volet Fibaro.

Au passage, je suis passé de Raspberry vers des VM sous Proxmox.

Je bricole encore un peu quelques réglages, histoire de mieux comprendre le Qos, true/false vs 1/0, slider, etc. Et Enocean que je n’arrive pas a faire fonctionner.
Ces jours je regarde pour doubler mon Jeedom, comme avec le mqtt on peut «brancher» plusieurs clients dessus, je veux me faire un second Jeedom uniquement de surveillance.

Bref, pour l’instant je reste en MQTT :slight_smile:

PS: Je me répète un peu mais même si on rajoute un étage (le broker MQTT) je trouve l’ensemble beaucoup plus stable, un peu plus rapide et plus facile à modifier/mettre à jour car chaque étage (VM) ne fait qu’une seule tâche et est optimisé pour ça.b

La solution tout en 1 avec Jeedom sur une seule machine, c’est pratique. Mais lorsqu’il faut dépanner un protocole particulier, c’est compliquer d’éviter les dommage collatéraux : redémarrages parfois nécessaires / déconnexions des autres clés USB et ce sont tous les protocoles qui sautent en même temps !

Je réfléchie à une solution d’utiliser 1 Raspberry Pi zero par protocole (avec une seule interface USB branchée dessus) et de tout envoyer en MQTT. C’est un plus lourd, mais tout est indépendant et cela permet de ne plus toucher à un truc qui fonctionne Et je rejoins

Bon j’ai tout ceci à passer en MQTT :

  • rfplayer2mqtt (je ne vois pas trop de solution à par un mini Jeedom)
  • teleinfo2mqtt
  • ebusd2mqtt (déjà fait)
  • zwave2mqtt (suivre le tuto plus haut)
  • zigbee2mqtt
  • gsm2mqtt (passer par node-red)
  • 1wire2mqtt (passer par node-red)
  • apcusd2mqtt
  • eiscp2mqtt [protocole Onkyo] (passer par node-red)
  • broker MQTT (présent sur la machine Jeedom)

Et s’il pouvait exister des interfaces toutes faites, ce serait super. :rofl: Bon, ça n’existe pas vraiment. Alors, j’aimerais bien me faire un système de cartes SD déjà configurées à mettre dans un RPi0 et hop tout est prêt.

@JcDenis Mieux vaut 1 grosse machine avec des VM ou pleins de Raspberry Pi ?

Question :
Existe-il une méthode pour exporter de façon massive toutes les infos Jeedom en MQTT avec un topic du style objet/equipement/commande(info) sans devoir créer les commandes une par une comme on le fait avec les plugins jMQTT/MQTT ?

1 « J'aime »