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
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 :
Vue du maillage Zigbee : (je n’ai aucun répéteur, que des contacts)
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
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.
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.
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
|
|
|
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.
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
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 Je tire mon chapeau au dev.
Petite vue de mes premiers test du BLE sous MQTT explorer :
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.
L’avantage du Pi est qu’il change de fonction tous les 6 mois chez moi Et que ça peut servir à tout !
Merci pour l’optimisation, il faut vraiment que je prenne le temps d’apprendre un peu ces langages…
Je vais vous raconter ma vie, encore…
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.
Dans la semaine je recois deux Hat UPS que je vais mettre dans le rack, et toujours géré depuis MQTT Je reviendrais faire la présentation du résultat ici.
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.
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.
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 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, 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.
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. 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 ?