Hello,
Une nouvelle solution vient d’être commercialisé par Lixee, le créateur de Zigate, pour intégrer Linky en zigbee 3.0, et sans alimentation additionnelle.
Abavala nous présente cette solution ici :
Le produit est dispo en précommande dés maintenant au prix de 49€.
Enfin BestOfCpp a publié un petit tuto pour le connecter.
Une intégration HomeAssistant est en cours de préparation et devrait sortir prochainement, et il faut probablement attendre sa sortie avant de commander. A noter aussi que seul le mode historique est supporté mais la aussi, cela devait évoluer.
C’est du zigbee donc pas besoin d’intégration particulière, à voir si déjà supporté par ZHA ou zigbee2mqtt. Ça fonctionne avec Jeedom et le plugin zigbee qui utilise la librairie de ZHA donc ça va pas tarder si pas encore fonctionnel
Ca me paraît très très bien tout ça. Par contre, les statistiques ne sont activées que sur le sensor energy qui correspond dans mon cas à la somme de indexHC + indexHP. Or je voulais essayer d’activer les statistiques sur les sensors indexHC et indexHP pour pouvoir intégrer le suivi des coûts.
J’ai ajouté dans customize.yaml les valeurs suivantes pour les deux sensors et je n’ai toujours rien dans les statistiques. Les sensors ne sont pas ajoutés dans la table statistics_meta, qu’ai-je raté selon vous ?
state_class: total_increasing
device_class: energy
Excellent et prometteur
J’imagine que tu as regardé dans outils de développement / statistique si les entités HP et HC apparaissent et sans erreur ? As tu bien les unités en Wh et pas WH ? Les statistiques demandent des unités précises, et en respectant les minuscules / majuscule (WH ne marchera à priori pas et c’est ce qui est affiché sur les échanges sur github pour HC et HP).
Merci pour la piste, l’unité en majuscule était probablement la cause.
ralmn a fait une nouvelle version de son converter compatible avec le mode standard du Linky et dans celle-ci, les unités sont correctes. Comme je l’ai écrit sur son gist, je suis super impressionné par le produit ZLinky_TIC car à 24m de mon router Zigbee le plus proche à travers 2 façades d’immeubles (l’immeuble donnant sur la rue et ma propre maison) comportant des fenêtres, j’ai quand même une connexion qui même si elle est très faible, semble stable
Côté dashboard énergie, j’ai pu ajouter les deux sensors HCHC et HCHP et rajouter deux input_number pour le coût en €/kWh, ce qui permet de suivre très joliment la consommation.
Je confirme, sans antenne je ne suis pas chaud pour percer le capot du Linky dans la mesure où, techniquement, il reste la propriété d’Enedis. Mais même sans antenne, je capte relativement bien compte tenu de la distance et des obstacles. Au pire, plutôt qu’une antenne et si le besoin s’en faisait sentir, j’ai un local au RDC de l’immeuble où je pourrai amener un router ce qui réduirait un peu la distance (resterait 18m avec les mêmes obstacles).
Je pense que je le ferai de toutes façons le jour où je voudrai automatiser mon garage qui se trouve un peu plus loin, car vu les LQI que j’ai avec le ZLinky, je ne pense pas me reposer sur ses capacités de router dans mon mesh.
Cette mise à dispo dans zigbee2Mqtt de Zlinky et l’abandon pure et simple de la zigate dans ZHA ( j’ai l’impression ) me pousse sérieusement à passer à faire la conversion ZHA → Z2M
Mais le taff me rebute un peu
Je pense qu’une fois l’intégration dans zigbee-herdsman-converters (utilisé par Z2M) et probablement assez rapidement dans l’intégration Zigbee de jeedom, on devrait retrouver la compatibilité dans ZHA un peu plus tard. Donc à voir en fonction du délai si ça vaut le coup de tout migrer.
Non Jeedom utilise une intégration Zigbee spécifique autant que je sache, mais le travail fait sur les converters herdsman et jeedom permettra aux développeurs de ZHA d’avoir une base solide et d’implémenter la compatibilité. Les quirks ZHA sont assez similaires aux converters Herdsman. Il faudra certainement faire une demande de support sur le github de zha-device-handlers pour ça, mais les éléments seront disponibles par ailleurs.
On est bien d’accord que tu parles du plugin non officiel zigbee2mqtt (le conteneur comme ha encapsulé dans du php, base 1600 appareils) ? Parce le plugin officiel (en fait il y en a plusieurs officiels) c’est une base de devices indépendante (genre 500 appareils) et à mon avis il ne faut pas trop compter sur une compatibilité à venir
J’ai lu quelque part (désolé je n’ai plus le lien) qu’il y avait déjà des gens qui travaillaient à l’intégration dans le plugin officiel jeedom. Pour zigbee2mqtt c’est la même base que pour HA donc c’est ce qu’est en train de faire ralmn.
Après j’ai envie de dire qu’une fois qu’il y aura un truc stable dans Z2M, dans l’absolu ça suffit pour avoir une base.
A mon avis le converter est déjà pas mal en l’état. Il reste à bien vérifier les remontées (tester) et voir éventuellement pour déterminer si le Linky est mono ou triphasé pour limiter le payload mqtt si c’est possible dans Z2M
OK, j’ai pas lu cette information. En tout cas par expérience, il y a un écart souvent significatif entre le moment ou ù jeedom travaille officiellement sur un sujet et la concrétisation côté utilisateurs…
Et ça met de côté le fait que ce soit réutilisable ailleurs
Oui c’est d’ailleurs un peu pareil sur ZHA, ça dépend un peu des devices, Z2M est souvent un peu plus « bleeding edge ».
Exemple : interrupteurs Aqara H1 double sans neutre qui ne fonctionne toujours pas à 100% sur ZHA alors qu’ils sont supportés parfaitement dans Z2M depuis plusieurs mois.
Si tu veux je peux aussi te donner les contre-arguments. A savoir bleeding-edge veut aussi dire que c’est plus propice aux breaking changes. ZHA est très stable et je pense que ça le restera. En outre une migration ce n’est pas anodin selon la complexité du système à migrer (devices, dashboard, scènes, automatisations, etc.)
