Passage au MQTT convainquant

Tags: #<Tag:0x00007f2834dd51e0> #<Tag:0x00007f2834dd5118> #<Tag:0x00007f2834dd5000> #<Tag:0x00007f2834dd4f38>

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)
jmqtt_zigbee
Vue du maillage Zwave : (62 modules ici, il m’en reste 10 à réinclure)
jmqtt_zwave

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

1 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:

3 J'aimes

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 :
jmqtt_bt

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.
jmqtt_monitoring_explorer

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

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

Et le résultat dans un design.
jmqtt_monitoring_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)

2 J'aimes

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 :
jeedom_portainer_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:
jmqtt_teleinfo_jmqtt
Résultat dans le design :
jmqtt_teleinfo_design
Et la vue depuis MQTT explorer :
jmqtt_telefino_mqtte

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 https://forum.jeedom.com/viewtopic.php?t=25492). 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