Passage au MQTT convainquant

Tags: #<Tag:0x00007fa7aaa72020>

Lut

A ce moment là autant mettre en place du docker …

  • A partir du fichier de config (surtout avec docker-compose), tu remontes 1 container d’un coup, ou même une stack compléte
  • Plus léger qu’une VM (pas d’OS embarqué si l’image est bien faite)
  • Plus facile à mettre à jour qu’une VM (récupération de l’image/ou rebuild et redémarrage du container). ça marche aussi pour le retour arrière
  • Plus fiable que qu’une carte SD
  • Docker s’installe dans une VM, et même dans un pi.

Les inconvénients sont les suivants :

  • Il faut quand même s’assurer que les volumes indispensables sont conversés quelque part en cas de crash
  • Le montage des devises c’est parfois pénibles
  • Les images x86_64 sont assez légions, celles pour armV7/V8 un peu moins.

Je vois un peu le principe mais je ne connais pas docker. Est-ce tout peut passer par docker ?
Comment se passe la gestion des ports USB avec Docker ou VM pour définir un port USB par container ou VM ?

J’aime vraiment bien le côté physique des RPi séparés. C’est vraiment indépendant. Une clé USB chacun et pas d’emmerdes de ports. Donc, je réfléchie…

Très intéressant ce retour d’expérience.

Content de Zigbee2MQTT ? Je suis en train de voir les différentes options Zigbee, et ça semble être celui qui couvre le plus largement les équipements. Et avec l’option frontend qui fournit une interface pour faciliter les opérations (renommage, bind, cartographie,…), ça semble de mieux en mieux.

Autre question, qu’as-tu utilisé pour la Teleinfo ? Je fonctionne avec un Wifinfo et le plugin Teleinfo pour le moment, mais je réfléchis à modifier cela. Apparemment, Tasmota semble supporter la teleinfo depuis quelque temps, ça pourrait être une solution.

  1. Il vaut mieux une machine avec VM ou Docker plutôt que plusieurs Raspberry. Pour avoir fait les deux et étant en VM aujourd’hui je ne reviendrais jamais en arrière :slight_smile:
  2. Pratiquement tous les protocoles ont une image (ou même par docker-compose), j’avais testé un peu aussi, c’est bien mais plus contraignant quand tu veux bricoler dedans. Il me reste encore un protocol et Rhasspy sous docker. (Dans une VM :smiley: )
  3. Coté VM, j’utilise Proxmox et rien pour la gestion des ports USB, je n’ai plus aucun problème ! Après c’est la solution qui demande le plus de temps à mettre en place quand on débute, mais ça vaut le cout et après comme je le disais plus haut la maintenance et le bricolage sont simples.

Super content oui, mais je ne reflète pas la majorité des gens, je n’ai que des capteurs d’ouvertures (20) et un répéteur en Zigbee. Donc question compatibilité je ne sais pas.

J’utilise une librairie python dédié à la téléinfo et un script perso. Rien de plus simple.
J’ai même branché deux clés USB Micro Tic sur la téléfinfo pour me faire un second afficheur avec un Raspberry :slight_smile:

En déviant un peu du sujet sur le MQTT, voici une page de mon Jeedom de surveillance, aujourd’hui il me sert à rien à part faire des test mais ça montre une vue d’ensemble de mes VM et de leur protocole associé.
jeedom_design_vms

J’avais vue un peu gros, mon serveur est à base de i9 mais il s’ennuie, clairement, vraiment pas besoin de si gros…
jeedom_proxmox

Salut

Je m’attaque déjà au Zigbee2mqtt avec une cle cc2531.
Est-ce celle là que tu utilise ?
Comment as tu fait pour rajouter dans les widgets pour rajouter en petit par exemple :PING VM MQTT…
Merci

Oui est non, la clé branché sur la VM Zigbee est un Conbee II et j’utilise branché nul part une cc2531 en Répeteur.

C’est juste de la déco: Affichage Line d’une commande dans un widget, et pour le Ping lui même soit le plugin network soit une VM avec des Ping sous Nodered.

Hello @JcDenis,

Merci pour ce super retour d’expérience !

Concernant tes Hat UPS, tu as choisi quoi ? Tu en es content ?
Du coup j’imagine que tu ne les utilises plus si tu as tout passé en VM ?

Pour le hat ups j’avais pris cette platine avec un script maison pour remonter les infos. Ça permet de tenir un bon moment lors de coupures. Par contre j’ai eu plusieurs fois ou il a coupé l’alimentation du Raspberry (Pi3 ou Pi4) sans trop comprendre pourquoi, j’ai l’impression qu’il vidait les piles même alimenté. (Avec une alim largement assez puissante.) J’en avais 3, les 3 m’ont fait le même coup. Peut-être à cause de piles 18650 trop veille, je ne sais pas.
Donc sur le papier c’était super, en réalité ça n’a jamais fait le job à 100%…

Je retiens donc que :

sur le papier c’était super, en réalité ça n’a jamais fait le job à 100%…

Merci pour le retour :sweat_smile:

1 J'aime

Hello,

Pour revenir sur le sujet, je suis aussi passé au MQTT depuis quelques temps et en effet la différence en terme de stabilité et de réactivité est impressionnate.
Exit les plugins ESPeasy (-> mqtt natif), ikea-light (-> zigbee2mqtt), Nabaztag (-> nab2mqttd) et autres diy à base de scripts/virtuels.
Pour le monitoring, comme l’a remonté @JcDenis, tout est aussi plus simple et fiable.

My 2 cents,
Bad

1 J'aime

Pour ma part, trop de problèmes avec zwave depuis plusieurs années. Instabilités, perte de module, associations qui perde leur config ou se modifient seuls etc… J’en ai marre.
Je suis en train d’acheter des modules Shelly sur Wifi donc (wallplug, relais 1 et 2). Je n’étais pas chaud pour mettre ma domotique sur mon wifi, ne voulant pas melanger les choses, mais là j’en ai vraiment trop marre du zwave, marre de me battre et le faire remarcher a coup de pieds au cu…

Je met mes modules sur un SSID wifi dedié. IP fixe géré par serveur DHCP.
MQTT pour remonter les infos, et fabrication d’un virtuel qui m’agrege à la fois les commandes (qui tapent sur le module Shelly) et les infos en upload (status, puissance etc) grace à MQTT.
J’en suis très content pour l’instant (3 modules zwave migrés)

3 J'aimes

Alors le Wifi… J’ai 12 ESP sur un SSID dédié, comme ce que tu es entrain de faire, et si c’était à refaire, bah pour quelques euros de plus, je partirais en Zigbee. J’ai aussi du Zwave, qui a pris sont temps pour se stabiliser, mais les problèmes était surtout causés par la jeunesse des produits sur le marché ou leur qualité, pas vraiment un problème de protocole.

Etant dans un immeuble en centre ville avec plus de 100m², il n’est pas rare que certains modules décrochent des bornes Wifi, par ce que celles des voisins ont décidés de changer de canal et de tout écraser.

La façon même dont est conçu le Wifi, fait qu’on empile trop de couches pour un simple réseau de capteurs (mqtt/udp, sur IP, sur 802.11), sans même parler de puissance d’émission ou de charge de la bande des 2,4GHz. Là où un protocole plus simple, comme Zwave, Zigbee ou LoRA limite les communications et ne maintient pas des sessions ouvertes pour rien.

Bon, cela étant, si ça te correspond, que ça marche et que tu en es content, c’est le principal !

Petit coucou en passant, cela fait 5 mois que mon Jeedom version MQTT tourne, et j’en suis super content, il fonctionne au poil.

Pour m’amuser aujourd’hui j’ai redémarré mon serveur Promox ou toutes mes VM Domotique sont, et tout est repartie impecable. Avec le bon ordre de redémarrage des VM, Jeedom n’a rien vu passer ! (Juste le Zwave qui a mis un peu de temps à redémarrer. (mais moins qu’avant.)

#MyLife

1 J'aime

Bonjour JcDenis,

J’utilise depuis le printemps Zwave2Mqtt pour mes « nouveaux » modules Zwave.
Tout fonctionne bien à par une ou deux fois où des modules sont passés en « dead ».
Je viens de me rendre compte qu’il y a eu pas de nouveautés en 2020.
Je suis en version 3.0.3 et la version actuelle est 4.1.1 avec un changelog important.

As-tu déjà fait une mise à jour de Zwave2Mqtt ?
Je n’ai même pas trouvé comment procéder

Edit : finalement (après snapshot) j’ai installé la dernière version R.A.S

ken@vo
Phil

Je ne sais même pas quelle version j’utilise (en docker) Je sais qu’elle embarque OpenZwave 1.6.1280. Mais ça fait un moment que je me dis qu’il faudrait faire la mise à jour :smiley:

Hello.
L’intérêt du docker il est là :

  • Les images sont toutes taggées, la dernière s’appelle toujours xxx:latest.
  • Les données sont séparées des binaires

Donc une mise à jour c’est une ligne de commande (au pire stop, pull, start) et un rollback pareil

1 J'aime

Pas forcément, si il passe à la librairie openzwave 2, ça risque d’engendrer pas mal de soucis sur les modules déjà inclue par exemple.

ça change rien sur le principe si ça nécessite de réinclure les modules… qu’importe le fonctionnement en docker ou classique, le souci sera le même.