Intégration zha

[max5962]

Hello,

Plus un ticket de demande qu'un vrai bug. Mais c'est essentiel pour l'utilisation. Qui s'occupe de l'intégration via ZHA de zlinky ? Merci

[le-pet]

et comment on bricole cela? non car la j'en ai assez de tout retourner, reconfigurer, déconfigurer. je suis plombier pas développeur, donc je veut bien comprendre 2-3 choses mais la c'est trop!

un peut comme si je vous demandait quelle PAG il y avait dans le compresseur de votre frigo...

[landaisbenj]

A la différence près qu’il n’aurait sûrement pas construit son frigo avec un tuto YouTube et des pièces acheté sur internet, si on se comprends.

[fairecasoimeme]

Si vous ne souhaitez pas bricoler, il y a plein de solutions mais surement pas Home-assistant avec ZHA. Si malgré tout, vous ne souhaitez pas changer Home assistant, je vous conseille Z2M à la place de ZHA.

[le-pet]

le github n'est pas la "notice" ?

[le-pet]

non mais je m'en sors très bien sur HA avec des tutos détaillés et explicatifs..., je ne demande que ça apprendre, mais la on me jette des données comme ça sas trop d'explications, même en y mettant la meilleure des volontés depuis 1 semaine je n'y arrive pas, j'ai retourné la majorité des explications trouvées ici et là, mais forcément à un moment il y as une manip de non expliquée qui fait que sa coince.

ou alors je suis stupide avec mes gros doigts

[landaisbenj]

Ce qu’il faut lire ici c’est qu’il ne s’agit pas d’une solution professionnel et documenté comme pourrais l’être un frigo vendu dans le commerce par exemple. il s’agit de solution diy fait sur mesure généralement avec du temps libres non rémunéré. Donc en gros quand on n’aime pas bricoler, et qu’on s’attend à ce que ça fonctionne du premier coup, ce n’est pas ici qu’il faut venir … tout ça pour dire qu’il vaut mieux éviter les commentaires alarmiste ou un peu extrême. Je ne pense pas que vous réagiriez de la même manière si vous étiez plombier bénévolement … demandez des conseils humblement, cherchez de l’aide, mais ne le faite pas aussi abruptement même si c’est compliqué.

[Hedda]

@fairecasoimeme Would be great if you would consider submitting a pull request to zigpy with ZLinky TIC Zigbee OTA Provider code now that ZHA Device Handlers support for your Lixee ZLinky TIC has now been merged into the zha-quirks package that will likely be added around the time that the next upcoming major Home Assistant core version is released.

Please see this related feature request for zigpy which is Zigbee library Home Assistant ZHA depends on:

https://github.com/zigpy/zigpy/issues/1060

That would close issue/suggestion:

https://github.com/fairecasoimeme/Zlinky_TIC/issues/66

This really becomes a user experience problem as now the first impression without a such Zigbee OTA Provider code firmware for ZLinky TIC is that it can not be updated automatically with the ZHA integration so users who can pair/join it will still not be able to use it until they manually updated the firmware on ZLinky TIC via other means.

Again please note that Zlinky TIC users still need to upgrade the firmware on their Zlinky_TIC device to be able to use it properly:

https://github.com/fairecasoimeme/Zlinky_TIC/releases

Firmware update on the Zlinky_TIC device can either be done manually or simi-manual via the zha-toolkit OTA function, see:

https://github.com/mdeweerd/zha-toolkit#ota_notify

PS: Hoping @fairecasoimeme in the future submit code for native OTA provider for zigpy to enable automatic firmware updates:

https://github.com/zigpy/zigpy/issues/1060

[MayeulC]

@le-pet

et comment on bricole cela? non car la j'en ai assez de tout retourner, reconfigurer, déconfigurer. je suis plombier pas développeur, donc je veut bien comprendre 2-3 choses mais la c'est trop!

un peut comme si je vous demandait quelle PAG il y avait dans le compresseur de votre frigo...

OK, alors quelques explications: tout appareil zigbee est capable de remonter plein d'infos. Pour simplifier, on peut considérer cluster=dossier, et attribut=fichier.

Certaines infos sont présentes dans des emplacements standards, d'autres, il faut avoir une connaissance particulière de l'emplacement où aller chercher l'info que l'on veut. C'est pour cela que des "quirks" (cas particuliers) doivent être ajoutés à zha (solution zigbee intégrée à homeassistant), pour qu'il sache où aller chercher les trucs.

En attendant, on peut aller chercher ces infos nous-même, et les remonter dans des capteurs que l'on créée pour cela. C'est ce que décrit @skanx dans son super post ici: https://github.com/fairecasoimeme/Zlinky_TIC/issues/18#issuecomment-1021186192

OK, pas d'heures creuses? La documentation, je l'avoue, difficile à lire, est ici. Au lieu de lire les attributs n°0x0100 et 0x0102 (c'est de l'hexadécimal, en décimal c'est 256 et 258), qui correspondent à Index HCHC et Index HCHP respectivement, il faut lire 0x0000 (0 en décimal), qui correspond à BASE.

Donc la procédure:

1. Ajouter le périphérique zigbee à homeassistant, ne pas se soucier des valeurs erronées lues par zha
2. Installer HACS et redémarrer HA
3. Depuis HACS, installer l'intégration ZHA Toolkit
4. Il faut modifier le fichier de configuration de HA pour charger ZHA Toolkit, en ajoutant la ligne zha_toolkit:,
5. Ajouter un capteur dans la configuration de Homeassistant:

   template:
   - sensor:
     - unique_id: lixee_zlinky_tic_metering_tarif_base
       unit_of_measurement: "Wh"
       device_class: energy
       state_class: total_increasing
       state: unavailable

6. Redémarrer HA (je conseille de vérifier le yaml avant dans Dev tools -> YAML -> Check configuration)
7. Ajouter une automatisation qui va venir lire l'info dans le cluster identifié plus haut (n°0) et la mettre dans le bon capteur 1 fois par minute:

   alias: Mise à jour infos tarif BASE
   description: ''
   mode: single
   trigger:
     - platform: time_pattern
       hours: '*'
       minutes: /1
       seconds: '0'
   condition: []
   action:
     - service: zha_toolkit.execute
       data:
         command: attr_read
         # ICI mettre la MAC du zlinky ou alors un des capteurs du zlinky créés par zha
         ieee: sensor.lixee_zlinky_tic_electricalmeasurement
         cluster: 1794
         attribute: 0
         state_id: sensor.template_lixee_zlinky_tic_metering_tarif_base
         allow_create: false

Si je ne me trompe pas, zha a intégré quelques changements pour améliorer l'expérience par défaut, et cela devrait être publié le mois prochain... Il reste du travail à faire avant que tout marche par défaut cependant.

---

Personellement, je ne sais pas trop pourquoi le relevé en VA ne s'actualise que lorsque je redémarre HA... Je vais essayer de voir si je peux en régler la fréquence avec ZHA Toolkit, ~j'éditerai cela.~ EDIT: Succès, il me semble. Dev tools -> Service -> yaml mode et demander cela (j'ai mis des valeurs un peu arbitraires: min 40s, max 200s, min 1Wh): Cela permet à la valeur relevée de s'actualiser, il serait bien que ce soit par défaut dans le firmware

service: zha_toolkit.conf_report
data:
  ieee: sensor.lixee_zlinky_tic_electricalmeasurement
  cluster: 1794
  attribute: 0
  max_interval: 200
  reportable_change: 1
  min_interval: 40

La différence est flagante:

Aussi, c'est bizarre: je suis en heures pleines, mais c'est mon capteur heures creuses qui augmente (j'ai vérifié les clusters pourtant...). Edit: possible que ce soit parce que je suis en HC Week-End, j'ai fait une demande pour basculer en mode standard (appel EDF -> demander une prestation F185 auprès d'ENEDIS).

EDIT: pas de souci, tout marche en mode standard, y compris les valeurs de tension qui étaient farfelues jusque-là, et j'ai bien la différence HC/HP. Malheureusement, il a fallu que j'ajuste manuellement la base de données pour annuler le saut que le changement a provoqué dans les données, je conseille donc à tout le monde de faire la demande si possible avant de mettre de zlinky en place.

Je conseille aussi de modifier la template de @skanx ( https://github.com/fairecasoimeme/Zlinky_TIC/issues/18#issuecomment-1021186192 ) pour utiliser unique_id à la place de "name", ce qui permet d'éditer le nom depuis l'interface de HA. J'ai édité mon post plus haut pour refléter cela.

---

Edit: j'ajoute la procédure de mise à jour du firmware avec zha, inspiré depuis [ici](https://forum.hacf.fr/t/zha-ota-update-firmware/9693):

Configuration homeassistant: ```yaml zha: zigpy_config: ota: otau_directory: /config/zigpy_ota ikea_provider: false ledvance_provider: false ``` Ajuster bien sûr le dossier `otau_directory` vers un dossier accessible dans lequel déposer les fichiers OTA. Il me semble que cela suffit en théorie, et que la disponibilité de mises à jour est vérifiée périodiquement, donc le Zlinky devrait se mettre à jour d'ici quelques jours. Le processus est accélérable en notifiant le Zlinky de la disponibilité d'une mise à jour. Pour cela, il faut la "toolbox zha" (disponible avec HACS), et appeler le service suivant (dans developer tools; il est également possible d'écouter l'événement `ota_notify_done` sur une autre page pour avoir plus d'infos): ```yaml service: zha_toolkit.ota_notify data: ieee: sensor.lixee_zlinky_tic_electricalmeasurement path: /home/homeassistant/.homeassistant/config/zigpy_ota event_success: ota_notify_success event_fail: ota_notify_fail event_done: ota_notify_done ```

[le-pet]

@MayeulC

Merci pour toutes ces infos et directives hyper complètes à suivre. néanmoins j'ai abandonné l'idée de ZHA et suis passé sous zigbee2mqtt, et la le Zlinky as fonctionné sans trop de soucis.

il faudrais juste que je prenne le temps d'aller fouiller dans la config de Z2M pour avoir la remontée de conso en instantanée (comme j'avait réussi à faire avec ZHA) car pour l'instant sa remonte minute par minute, pas dérangeant en soi, plus pour la satisfaction personnelle.

[noosander]

Bonjour MayeulC

Merci pour ton tuto. Juste eu un petit souci, chez moi ça ne marchait pas car le capteur crée dans ton template se nomme: sensor.template_lixee_zlinky_tic_metering_tarif_base au lieu de: sensor.lixee_zlinky_tic_metering_tarif_base

Apres avoir changé le nom du capteur dans la commande zha toolkit ca marche nickel. J'espere que cela va fonctionner sur le long terme.

[MayeulC]

@noosander ah oui je viens d'éditer mon post pour utiliser unique_id au lieu d'utiliser name, ce qui permet de mettre un nom plus sympa dans l'interface, mais effectivement le capteur s'appelle template_[etc] du coup. Je corrige, merci d'avoir relevé cela.

[tex0l]

Hi all!

I'm not sure if I understand the purpose of the PR @pdecat did on the quirks for HA actually (https://github.com/zigpy/zha-device-handlers/pull/1165).

I thought I would be able to have my meters for busy and idle hours (heures pleines & heures creuses) along with the current power factor, power consumption, etc. but after updating everything I still get garbage readings: . Is that expected if I use firmware v0x0000000b and HA v2022.11.3?

I use the workaround suggested by @MayeulC which works with zha_toolkit, but I think it'd be much better to have it work out of the box!

Is there an issue that tracks making a quirk that works out of the box? Anyone has given any thought about this (what issues I might face and so on?) I think I'll spend some time making this work properly in the coming weeks.

[axellebot]

https://github.com/zigpy/zha-device-handlers/pull/1165 only added Zigbee communication capability on Zigpy for Zlinky_TIC . I was also hoping to have my meter working out of the box since the PR we must miss something about ZHA implementation.

[MayeulC]

@tex0l, some of that info became available to me after I called EDF to ask them to put me in "standard" mode (same as #133, ask them to order a "prestation F185" from Enedis).

Firmware version is a bit strange, I don't really get it, but it was reported correctly after pushing an OTA update. I still need to figure out where my mettering for "Heures creuses week-end" is going, it's not within "heures creuses".

Indeed, it would be great if everything could be discovered and set-up automatically, but reaching that level of integration is going to take a while (assuming there are no issues on Enedis's side either).

[pdecat]

Firmware version is a bit strange

11 is 0b in hexadecimal

[MayeulC]

Got it, thanks. I misunderstood it as 0b000000000 (and was not aware there was a v11).

[tex0l]

Hi @MayeulC,

I contacted EDF, and they switched me to the standard mode overnight (thank you for the tip) which fixed the "Active power" and "RMS voltage" entities, however the entity SummationDelivered stayed at 0.

From my understanding, the SummationDelivered gets its data from the cluster 0x0702 and attribute 0x0000 as defined there https://github.com/zigpy/zigpy/blob/dcf56d44b2db41dd2cd04015438f5054c6dbc67a/zigpy/zcl/clusters/smartenergy.py#L28 (I don't get how it gets the name SummationDelivered, I can't find the string in any of the projects involved btw). Am I correct?

When I tried to manually read the value of this attribute in this cluster from ZHA's GUI, it updated the value of the SummationDelivered entity. It works anytime I update it manually, but it isn't done automatically. Anyone knows why it doesn't get updated automatically?

Also, why don't the other meters (on cluster/attribute 0x702/0x0100 0x702/0x0101 for example) appear as separate entities in ZHA? Among all the attributes of the metering cluster, how does ZHA decides what entities are built?

[MayeulC]

@tex0l this is usually the zigbee device that automatically reports a change when it's big enough. You can follow the steps I wrote here, originally from there so that it gets updated more frequently. I agree this should be the default. Maybe a zha quirk can update this when adding the device?

Unfortunately, I don't know enough about zha to answer your other questions. It probably has to do (in part) with these clusters being used somewhat differently depending on your plan.

[Kassouma]

Hello everyone, Sorry if the question looks dumb but there are so many subjects about ZHA&Zilinky that it's difficult to know what's the last status...?

I can see there's a new quirck for version 12 that provides the following information " LiXee ZLinky_TIC Summation delivered " which is identical as "sensor.template_lixee_zlinky_tic_metering_tarif_base" suggested by @MayeulC . Does it mean there's no need to implement tweaks ? On my side I have a funny behavior, If I only use the default" LiXee ZLinky_TIC Summation delivered" it's randomly updated, most of my energy dashboard grid is empty. If I implement the "sensor.template_lixee_zlinky_tic_metering_tarif_base" then " LiXee ZLinky_TIC Summation delivered" starts working well and provides same output as "sensor.template_lixee_zlinky_tic_metering_tarif_base"....I am quite confused! Thanks in advance for the help!

[tex0l]

Finally! The latest firmware (0x0000000c) combined with the latest HA version (2023.2.0) work out of the box on my end!

[lbonvarl]

Hello I am on the current FW v13 (Firmware: 0x0000000d on the ZLinky_TIC by LiXee) and the native integration works well for a TEMPO subscription (6 differents tariffs) with a linky SAGEMCOM running in TIC=STANDARD mode and a triphasé 18kV subscription. However, a lot of the parameters readable are not exposed natively. I am notably interested in PMAX (Target Cluster = 0x0504, Attribut=0x050D). I can read it via ZHA Toolkit: Read Attribute, Target Cluster=2820, Attribute Id or Name = 1293, but is anyone looking at updating the native ZHA integration to support most readable parameters via the ZLinky_TIC by LiXee ? See attached what I see on ZHA native integration. Thanks in advance.

[Hedda]

a lot of the parameters readable are not exposed natively. I am notably interested in PMAX (Target Cluster = 0x0504, Attribut=0x050D). I can read it via ZHA Toolkit: Read Attribute, Target Cluster=2820, Attribute Id or Name = 1293, but is anyone looking at updating the native ZHA integration to support most readable parameters via the ZLinky_TIC by LiXee ?

See this existing device support request that is also asking for more sensor entities -> https://github.com/zigpy/zha-device-handlers/issues/2583

Mentions the need to extend -> https://github.com/home-assistant/core/blob/dev/homeassistant/components/zha/sensor.py

(best would be if Zlinky_TIC developers took on that task as to present it the best way possible using the ZHA without mods).

Also check out the other open issues -> https://github.com/zigpy/zha-device-handlers/issues?q=is%3Aissue+is%3Aopen+ZLinky

ZHA docs -> https://www.home-assistant.io/integrations/zha#how-to-add-support-for-new-and-unsupported-devices

That is, normally you would "only" need to extend the existing quirk for Lixee's ZLinky device in ZHA Device Handlers repository, (i.e. zigpy/zha-device-handlers/zhaquirks/lixee/zlinky.py) however in some cases where no one has previously exposed similar clusters and attributes as entities under the ZHA integration inside Home Assistant core then I believe that you probably also need to extend the sensor (sensor.py) device type capabilities under the ZHA integration component code inside the Home Assistant core:

https://github.com/home-assistant/core/blob/dev/homeassistant/components/zha/sensor.py

under

https://github.com/home-assistant/core/tree/dev/homeassistant/components/zha

Recommend you ask in those existing open Device Support Request issues in the ZHA Device Handlers repository (or create a new) as it is usually best to keep the discussion there under a Device Support Request issue even if need to change the ZHA code inside the Home Assistant core:

https://github.com/zigpy/zha-device-handlers/issues?q=is%3Aissue+is%3Aopen+ZLinky

Why those attributes are not exposed as entities under the ZHA integration inside Home Assistant is explained in ZHA docs here:

https://www.home-assistant.io/integrations/zha#how-to-add-support-for-new-and-unsupported-devices

Also read relevant info here on why many clusters and attributes from other Zigbee devices are exposed without a quirk handler:

https://www.home-assistant.io/integrations/zha#knowing-which-devices-are-supported

For those who are not already aware of this:

Zigbee devices that do not only use standard configuration and parameters (default ZCL clusters and attributes) but instead also implement custom manufacturer clusters and attributes (also rerfered to as "quirks") will need a custom handler/converter/parser/translator as Python script code in the upstream "ZHA Device Handlers" library repository to extend custom manufacturer device "quirk" (also known as a ZHA quirk) support for specific non-standard ZCL clusters and attributes (which Zigbee gateway implementations that depends on zigpy and the ZHA Device Handlers library, like Home Assistant s ZHA integration, then can make use of).

https://github.com/zigpy/zha-device-handlers/#readme

If you can not code that Python script code yourself to write the needed custom handler/converter/parser/translator for adding that specific device to the "ZHA Device Handlers" repository/library then suggest submitting a "device support request" (with device signature and diagnostic information) as new issues -> https://github.com/zigpy/zha-device-handlers/issues

Without a "device support request" as a new issue posted to the "ZHA Device Handlers" repository/library requesting support for an unsupported device or device feature with Device signature and Diagnostic information the ZHA integration developers will not even know about the device unless they by random chance happened to have bought it themselves.

The reason why non-standard devices need a custom handler/converter/translator is explained in ZHA integration documentation here -> https://www.home-assistant.io/integrations/zha#zha-exception-and-deviation-handling

Zigbee devices that use clusters and attributes that are standard in the official ZCL (Zigbee Cluster Library) do not need custom handlers/converters/translators as explained in the ZHA integration documentation here -> https://www.home-assistant.io/integrations/zha#knowing-which-devices-are-supported

PS: Off-topic but FYI, this also works kind of similarly for Zigbee2MQTT which also requires a custom handlers/converters/parsers/translators for specific devices -> https://www.zigbee2mqtt.io/advanced/support-new-devices/01_support_new_devices.html (which is different compared to example OpenHAB's Zigbee Bindings which instead require users to code their own "Thing Configuration" -> https://www.openhab.org/addons/bindings/zigbee/#thing-configuration).

[orrionis]

Sous zha comment faire pour avoir un sensor qui m indiqué si je suis en heure pleine ou heure creuse.

Visiblement il y l info à cet emplacement PTEC 0x0702 0x0020 RO string 4char nulle

Merci

[Hedda]

@fairecasoimeme any chance you would consider looking into extending and improving or enhancing the zha component's sensor code inside Home Assistant's core for ZLinky TIC device yourself to truly make the Home Assistant's ZHA (Zigbee Home Automation) integration a fully first-party supported implementation with every important sensor presented as entity there out-of-the-box by default after just pairing/joining the device to the ZHA integration for a better user experience? Please see this comment for what sensors are missing and how to go about implementing this -> https://github.com/fairecasoimeme/Zlinky_TIC/issues/18#issuecomment-1826119238

While it already works today with the ZHA integration, not all entities (attributes) are presented by default so it is currently not as user-friendly experience as it could be out-of-the-box, or in other words it is complex so more complicated to use than needed because not all clusters and attributes are fully supported nativly inside the sensor code for the ZHA component and thus advanced configuration is needed -> https://github.com/fairecasoimeme/Zlinky_TIC/blob/master/README.md#zha

Also, another missing feature wanted for ZLinky TIC in ZHA is Zigbee OTA updates for firmware, see request -> https://github.com/zigpy/zigpy/issues/1060

If you need commercial incentive and motivation for this then you should know that Home Assistant founders have previously estimated that only around 20% of all users have enabled opt-in for analytics and if that is the case then today the 23% of the userbase that use the ZHA ("Zigbee Home Automation") integration inside Home Assistant should mean that there approximately 250,000 Home Assistant installations instances with the ZHA integration installed around the world. Reference for that is Home Assistant analytics statistics -> https://analytics.home-assistant.io/integrations/

Note that there are several other benefits for manufacturers to implement an OTA provider for the zigpy library (ZHA dependency).

For example, you could then join the Home Assistant's "Works with Home Assistant" partner program with its matching "Works via Zigbee with Home Assistant" compatibility badges and ask them as a company if they would not consider joining that program, and by extension also provide Zigbee OTA images publicly to show that they approve of Home Assistant's ZHA integration as a supported Zigbee gateway implementation for their devices:

https://www.home-assistant.io/blog/2022/07/12/partner-program/

There it says "Works with Home Assistant partners are expected to provide firmware updates via user-friendly services provided by Home Assistant" under Responsibilities in a section there called "Provide easy firmware updates" which explains that "Works with Home Assistant partners are expected to provide firmware updates via user-friendly services provided by Home Assistant".

https://partner.home-assistant.io/

"There are manufacturers that are creating products that integrate into Home Assistant using standards like Z-Wave, Zigbee, or Matter (soon). In these cases, the integration is maintained by the Home Assistant community and Nabu Casa. These companies can still become a member of the Works with Home Assistant program but are relieved from integration maintenance."

"With Home Assistant we are always working on educating our users about preferring local control and open standards when acquiring new products. This is also reflected in the “Works with Home Assistant” badges."

FYI, see example ThirdReality, a Zigbee device making company that joined their partner program + having a zigpy OTA provider:

https://www.home-assistant.io/blog/2022/10/13/third-reality-partner/

PPS: This relates to zigpy as it may imply some commitment from companies to help with OTA updates and ZHA Device Handlers.

https://www.home-assistant.io/integrations/zha#ota-firmware-updates

https://github.com/zigpy/zigpy/blob/dev/README.md#zigbee-device-ota-updates

https://github.com/zigpy/zigpy/wiki/OTA-Information-for-Manufacturers

https://www.home-assistant.io/integrations/zha#zha-exception-and-deviation-handling

https://github.com/zigpy/zha-device-handlers

https://github.com/zigpy/zha-device-handlers/blob/dev/README.md

[Hedda]

ZHA Device Handlers requests -> https://github.com/zigpy/zha-device-handlers/issues?q=is%3Aissue+is%3Aopen+zlinky_tic

@fairecasoimeme any chance you would consider looking into extending and improving or enhancing the zha component's sensor code inside Home Assistant's core for ZLinky TIC device yourself to truly make the Home Assistant's ZHA (Zigbee Home Automation) integration a fully first-party supported implementation with every important sensor presented as entity there out-of-the-box by default after just pairing/joining the device to the ZHA integration for a better user experience? Please see this comment for what sensors are missing and how to go about implementing this -> #18 (comment)

While it already works today with the ZHA integration, not all entities (attributes) are presented by default so it is currently not as user-friendly experience as it could be out-of-the-box, or in other words it is complex so more complicated to use than needed because not all clusters and attributes are fully supported nativly inside the sensor code for the ZHA component and thus advanced configuration is needed -> https://github.com/fairecasoimeme/Zlinky_TIC/blob/master/README.md#zha

Also, another missing feature wanted for ZLinky TIC in ZHA is Zigbee OTA updates for firmware, see request -> zigpy/zigpy#1060

Again, best would be best if you could extend and improve/enhance the zha component code inside Home Assistant's core for additional or custom attributes and clusters ZLinky TIC device as probably no one else knows better what this product should expose under the device in ZHA user interface to make be presented better there than what it is today:

https://github.com/home-assistant/core/blob/dev/homeassistant/components/zha/sensor.py

https://github.com/home-assistant/core/tree/dev/homeassistant/components/zha/core/cluster_handlers

https://github.com/home-assistant/core/tree/dev/homeassistant/components/zha/core

PS: For reference, check out this PR that changes and adds additional category to ZHA's sensor -> https://github.com/home-assistant/core/pull/102157

[laurent-home]

Bonjour à tous, depuis 6 mois mon Zlinky focntionnait parfaitement. En Tier 3 j'avais mes remontées de conso horaire. Je ne sais pas ce qui s'est passé, y a 1 mois plus de connexion au zlinky , j'ai débranché et remis, depuis je n'ai plus accès à ma conso horaire. Quelqu'un a une idée d'où ca peut venir ? merci

[lbonvarl]

Bonjour à tous, depuis 6 mois mon Zlinky focntionnait parfaitement. En Tier 3 j'avais mes remontées de conso horaire. Je ne sais pas ce qui s'est passé, y a 1 mois plus de connexion au zlinky , j'ai débranché et remis, depuis je n'ai plus accès à ma conso horaire. Quelqu'un a une idée d'où ca peut venir ? merci

J'ai eu un souci similaire, j'ai refait un pairing apres l'avoir débranché du linky et c'est reparti.

[laurent-home]

Merci de votre aide. J’ai installé zigbee2mqtt et tout est ok Amicalement LaurentLe 11 janv. 2024 à 14:26, Loic Bonvarlet @.***> a écrit :

Bonjour à tous, depuis 6 mois mon Zlinky focntionnait parfaitement. En Tier 3 j'avais mes remontées de conso horaire. Je ne sais pas ce qui s'est passé, y a 1 mois plus de connexion au zlinky , j'ai débranché et remis, depuis je n'ai plus accès à ma conso horaire. Quelqu'un a une idée d'où ca peut venir ? merci

J'ai eu un souci similaire, j'ai refait un pairing apres l'avoir débranché du linky et c'est reparti.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[lbonvarl]

Hello @fairecasoimeme, are there plans to update the ZHA integration ? It would boost the hardware sales as easy to deploy for home assistant newbies.

[Hedda]

@fairecasoimeme also check out discussion about ZHA Device Handlers version 2 (ZHA-Quirks V2) architectural design developer:

https://github.com/zigpy/zigpy/discussions/1312

FYI, just want to raise awareness to any ZHA Device Handler (a.k.a. quirk) developers here that you might be interested in following this architectural proposal and developers discussion about changing how to decouple entities exposed in Home Assistant’s built-in Zigbee Home Automation (ZHA) integration from underlying zigpy devices, clusters, and endpoints to make it easier to develop ZHA Device Handlers (a.k.a. quirks). So if interested please read and follow that ongoing dicussion:

https://github.com/zigpy/zigpy/discussions/1312

Summary; the discussion includes a new zigpy API concept that will allow ZHA-quirks developers to add support for a new device that uses custom (non-standard) Zigbee clusters and attributes without having to both create a quirk and modify both the codebase of the ZHA component in the Home Assistant code. The proposed idea was raised now by puddly with a suggestion on how to make quirks easier and less complicated to create and edit by new ZHA-quirks developers.

For back-story reference and background what this is about, also read:

https://www.home-assistant.io/integrations/zha#how-to-add-support-for-new-and-unsupported-devices

and

https://www.home-assistant.io/integrations/zha#knowing-which-devices-are-supported

plus

https://github.com/zigpy/zha-device-handlers/blob/dev/README.md#what-the-heck-is-a-quirk

"ZHA device handlers bridge the functionality gap created when manufacturers deviate from the ZCL specification, handling deviations and exceptions by parsing custom messages to and from Zigbee devices. Zigbee devices that deviate from or do not fully conform to the standard specifications set by the Zigbee Alliance may require the development of custom ZHA Device Handlers (ZHA custom quirks handler implementation) to for all their functions to work properly with the ZHA component in Home Assistant."

"In human terms you can think of a quirk like Google Translate. I know it's a weird comparison but let's dig in a bit. You may only speak one language but there is an interesting article written in another language that you really want to read. Google Translate takes the original article and displays it in a format (language) that you understand. A quirk is a file that translates device functionality from the format that the manufacturer chose to implement it in to a format that Zigpy and in turn ZHA understand. The main purpose of a quirk is to serve as a translator."

[penso]

Sous zha comment faire pour avoir un sensor qui m indiqué si je suis en heure pleine ou heure creuse.

Visiblement il y l info à cet emplacement PTEC 0x0702 0x0020 RO string 4char nulle

@orrionis est-ce que ça a été ajouté? J'aimerais bien utiliser le changement heure creuse pour allumer mes ballons plutôt que d'avoir une heure fixe...

[Hedda]

@fairecasoimeme also check out discussion about ZHA Device Handlers version 2 (ZHA-Quirks V2) architectural design developer:

zigpy/zigpy#1312

FYI, just want to raise awareness to any ZHA Device Handler (a.k.a. quirk) developers here that you might be interested in following this architectural proposal and developers discussion about changing how to decouple entities exposed in Home Assistant’s built-in Zigbee Home Automation (ZHA) integration from underlying zigpy devices, clusters, and endpoints to make it easier to develop ZHA Device Handlers (a.k.a. quirks). So if interested please read and follow that ongoing dicussion:

zigpy/zigpy#1312

Summary; the discussion includes a new zigpy API concept that will allow ZHA-quirks developers to add support for a new device that uses custom (non-standard) Zigbee clusters and attributes without having to both create a quirk and modify both the codebase of the ZHA component in the Home Assistant code. The proposed idea was raised now by puddly with a suggestion on how to make quirks easier and less complicated to create and edit by new ZHA-quirks developers.

@fairecasoimeme, FYI; > ZHA needs to be modified for now, but we're adding support for "quirks v2" soon (if everything goes as planned).

You'll be able to expose attributes for ZHA to automatically create switches/sensors/...

FYI, ZHA/zigpy developers have now introduced initial support for what is called ”quirks v2” + begun new how-to documentation:

https://github.com/zigpy/zha-device-handlers/pull/3019

This ”quirks v2” implementation is a huge chance to the development of making quirks for devices like Zlinky TIC since it now allows you adding new entities to Home Assistant via a quirk alone without having to modify ZHA code in Home Assistant core.

For more information please see these for reference:

https://github.com/zigpy/zigpy/discussions/1312

https://github.com/zigpy/zigpy/pull/1329

https://github.com/home-assistant/core/pull/111176

That PR with new docs will initially add a separate quirks_v2.md file to difference v1 from quirks v2 -> https://github.com/zigpy/zha-device-handlers/pull/3019

# Quirks v2

## Introduction

Quirks v2 use a fluent interface style. While this isn't common in python it was done to improve the readability of the source code and to make it human-friendly for non developers. The amount of boilerplate code has been significantly reduced and the need to specify a signature dictionary and a replacement dictionary has been removed. This should make it much easier for the community to contribute quirks.

## Goals

- Significantly reduce the amount of boilerplate code required to write a quirk
- Make it easier for the community to contribute quirks
- Make it easier to read and understand quirks
- Make it easier to maintain quirks
- Expose entities from a quirk
- Allow custom logic to determine if a quirk should be applied to a device
- Allow custom binding, reporting configuration or any sort of initialization logic without hacking the bind or configure_reporting methods

## Breakdown of a minimal example

...

PS: Also check out summarized back-story and more links here:

https://community.home-assistant.io/t/zha-device-handlers-version-2-zha-quirks-v2-architectural-design-developer-discussion/666460

[Ced-C]

Hey all, I just purchased a Lixee Zlinky TIC module and paired it with my homeassistant instance. I have found that some of the values are not reported : In particular, the power and voltage which I found interesting (although, I guess I can get back to it using current and appearing power). I wonder if it is a bug or if I received a faulty device. any issues with those value on your side ?

[fairecasoimeme]

Hey all, I just purchased a Lixee Zlinky TIC module and paired it with my homeassistant instance. I have found that some of the values are not reported : In particular, the power and voltage which I found interesting (although, I guess I can get back to it using current and appearing power). I wonder if it is a bug or if I received a faulty device. any issues with those value on your side ?

It's not due to ZHA. You have a Linky in historic mode. If you want more informations, you have to change to standard mode. You can find the procedure here : https://github.com/fairecasoimeme/Zlinky_TIC/blob/master/README.md#faq

[almostlunatic]

It's not due to ZHA. You have a Linky in historic mode. If you want more informations, you have to change to standard mode. You can find the procedure here : https://github.com/fairecasoimeme/Zlinky_TIC/blob/master/README.md#faq

I've passed to standard mode a long time ago but it seems that nothing has changed. Should I repair ZLinky TIC, should I update the FW?