Je vais m’équiper pour travailler sur la technologie Zigbee, j’abandonne progressivement zwave.
J’ai beaucoup mu et comparé, je pense partir sur Deconz/Conbee II, cela semble le couple le plus fonctionnel d’après ce que j’ai lu.
En fouillant sur le site de Dresden Elektronik / Phoscon je vois qu’il existe pour Raspberry une carte Raspbee II qui semble avoir un fonctionnement similaire ou proche mais qui se connecte directement dans le Raspberry.
Savez vous si cette carte fonctionne avec le plugin Deconz ? Ou si j’abandonne immédiatement l’idée ?
L’intégration dans le Raspberry me semblait pratique et efficient. Que me conseillez vous ?
Je peut pas mettre la main au feux car je n’en n’ait pas …
Il y a de grande chance quand même qu’elle se présente sur un /dev/ttyxxxx et qu’elle utilise le port serie du pi !
Comme la config du deconZ est basé sur un /dev/ttyxxxx y a pas de raison que ça marche pas !
mais bon si tu veux pas prendre de risques la clef usb conbe2 fonctionnera aussi sera plus générique dans d’autres installe mais nécessitera un hub alimenté sur un pi …
Si tu veux passer sur zigbee, je te conseille de te renseigner un peu plus sur le nouveau plugin zigbee (en bêta pour le moment) mais les intégrations/améliorations sont gérées par jeedom
Il a encore quelques inconvénients mais est très prometteur (je suis sur deconz et je passerai sûrement sur zigbee prochainement).
Regarde aussi pour la clé, car il y a une autre clé qui gérerait "mieux " (à confirmer) le maillage que la conbee2…
Je pense que déjà tu peux oublier le raspbee2, je ne vais pas entrer dans le détail mais j’ai lu un post de @Yves19 où il explique les risques d’interférences.
Ensuite le choix entre les plugin dépend surtout de tes besoins et du choix de tes futurs appareils.
On peut pour le moment faire du binding directement avec deCONZ/Conbee2 ce qui n’est pas possible (pour l’instant) avec Zigbee/Conbee2.
Ça, j’aimerais bien voir ou tu as vu ça ? ^^. Les problemes de maillages viennent généralement des appareils, pas de la passerelle. Si ça marche mieux pour certains c’est parce que Xiaomi ne change jamais de parent, et qu’ils ont juste refait le réseau. Et je suis pas sur que la clé elealabs gère le Green power.
Sinon moi j’éviterais le Raspbee, les passerelles zigbee sont très sensibles aux perturbations, et il te sera toujours plus facile d’éloigner une clé USB qu’un module GPIO, et tu pourras t’en servir sur PC par exemple pour la MAJ du firmware.
Je crois que c’est sur le post principal du plugin zigbee ou plusieurs personnes ont constaté cela. Effectivement à nuancer s’il y a du Xiaomi dedans . J’édite mon post pour mettre du conditionnel
Regarde le sujet principal ou il y a 1500 postes, il y a eu une discussion ce matin ou hier je crois (ce sont les derniers postes il me semble). Mais a vérifier dans le temps et suivant les équipements comme souligné par @HugoVal11
Justement, c’est juste des remarques, pas de vrais tests, par exemple ça plugin-ZIGBEE Beta - #1197 par TheAbdel
La personne met une image de son réseau en disant qu’elle a un meilleur maillage, a part que le maillage ne représente PAS la réalité, il y 2 connections pour les end devices, ce qui n’est pas possible technologiquement.
On verra sur le long terme, mais pour le moment y a pas a s’affoler.
Oui tout a fait d’accord, c’est pour cela que j’ai mis du conditionnel suite à ton retour.
Il faudrait effectivement des études comparatives pour voir si l’une ou l’autre est "meilleure ".
Dans mon cas, j’ai déjà une conbee2 sous deconz et garderai la même si je passe avec le plugin zigbee… sauf si une autre est meilleure…
Je fais parti de ceux qui ont remarqué un meilleur maillage avec la clé EZSP. Par contre j’avais avant une Pizigate avec antenne (v3.1d) et non une Conbee 2.
Ok j’ai pas fait de test poussé et super détaillé, mais ce que j’ai remarqué en changeant de clé, c’est que j’avais de nombreux capteurs Xiaomi qui n’étaient jamais routé par des routeurs Xiaomi ou Ikea, et même après une ré-inclusion du capteur.
Quand je suis passé sur EZSP, quasiment tous mes capteurs étaient routé. Alors oui on peut dire que les Xiaomi ont fait parti d’un nouveau réseau donc ils ont trouvé le routeur, mais quelques jours après, j’ai ajouté d’autres routeurs et 30 minutes après des capteurs Xiaomi étaient routé sur le nouveau routeur sans rien faire, ni de nouvelle inclusion de ce capteur…
Par contre, il n’y a pas que la clé qui rentre en jeux, le firmware fait tout et pour le moment, aucun regret avec la clé EZSP…
C’est pas faux, mais ton maillage lui, l’est, tu as des capteurs avec 2 connexions, ce qui est impossible, ou alors cela ne représente pas les connexions, ou alors les « neigtboard table » ne sont pas mise a jour assez régulièrement (ça peut arriver quand un appareil « se cherche » mais ça ne reste pas), et ça fausse les résultats.
Et quand tu regardes ce capteur justement, il y a une connexion vers un routeur, et une vers le coordinateur, laquelle est la vraie pour toi ?
Effectivement, il y a 2 routes, une vers le coordinateur et une vers le routeur.
Je sais pas si c’est une erreur de représentation du plugin Zigbee, mais quand je vais sur le capteur, les informations de signal qui s’affichent correspondent à celui de la liaison du routeur.
Il faudrait voir avec Loic pour savoir pourquoi il y a 2 liaisons sur le graphique…
Je confirme et je bisse. A un instant donné pour chaque équipement du réseau il ne peut y avoir qu’une seule route active. Donc gare aux conclusions hâtives basées sur l’interprétation graphique du maillage.
Le seul résultat à prendre en compte est le taux de messages transmis bons du premier coup et le nombre de sauts (latence) pour conclure de la solidité de son maillage. La clef coordinatrice y est presque pour pas grand chose puisque le réseau peut et doit pouvoir fonctionner sans elle.
. J’édite mon post pour mettre du conditionnel
