fairecasoimeme / Zlinky_TIC

Téléinformation Linky autoalimenté ZigBee 3.0
291 stars 21 forks source link

Intégration zha #18

Open max5962 opened 2 years ago

max5962 commented 2 years ago

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

fairecasoimeme commented 2 years ago

Bonjour, Pour le moment personne à ma connaissance, je n'ai pas eu le temps de vraiment regarder comment faire la requête auprès des dev ZHA. J'imagine qu'il n'y a pas grand chose à faire mais peut-être que cela requiert un zha-quirks. J'essaie de regarder dans la semaine ...

max5962 commented 2 years ago

Bonjour,

merci beaucoup. Dans le doute, j'avais créé un ticket ici : https://github.com/zigpy/zigpy-zigate/issues/103

fairecasoimeme commented 2 years ago

Bonjour, Je pense que c'est plus sur ZHA qui faut faire la demande. Zigpy est capable de gérer l'appareil je pense. C'est plus l'intégration vers HA qui faut faire

pdecat commented 2 years ago

Cela semble s'intégrer nativement dans ZHA:

image

image image

Mais il y a comme un problème d'unité ou de virgule.

max5962 commented 2 years ago

Etonnant chez moi, j'ai beaucoup moins d'informations . Même en supprimant et relançant l'association ... : image

EDIT : vous ne semblez pas utiliser de zigate. Cela est peut être la différence. (zigpy plus à jour chez vous)

pdecat commented 2 years ago

J'utilise effectivement une passerelle zzh avec firmware Z-Stack supportée par zigpy-znp, et il s'agit d'une version de développement de Home Assistant mise à jour le 31 octobre.

MichaelBitard commented 2 years ago

J'ai la même chose que @pdecat avec une zigate

2021-11-11_11-40-20_grim

J'imagine qu'il doit manquer quelques informations :)

Le fait que le module apparaisse comme "Router" semble indiquer qu'il faudra probablement un zha_quirks pour mieux le configurer non ?

max5962 commented 2 years ago

@MichaelBitard tu es sous quel version de hass ? vraiment étonné de ne pas voir les mêmes fonctionnalités :S j'espère pas une version casé du zlinky :/

EDIT : tu as quoi dans "informations zigbee" ? @fairecasoimeme une idée ce qui peut cause la non exposition de certaines fonctionnalités ?

merci :)

MichaelBitard commented 2 years ago

La dernière à jour normalement:

System Health

version core-2021.11.2
installation_type Home Assistant OS
dev false
hassio true
docker true
user root
virtualenv false
python_version 3.9.7
os_name Linux
os_version 5.10.17-v7
arch armv7l
timezone Europe/Paris
Home Assistant Community Store GitHub API | ok -- | -- Github API Calls Remaining | 5000 Installed Version | 1.15.2 Stage | running Available Repositories | 904 Installed Repositories | 7
Home Assistant Cloud logged_in | false -- | -- can_reach_cert_server | ok can_reach_cloud_auth | ok can_reach_cloud | ok
Home Assistant Supervisor host_os | Home Assistant OS 6.6 -- | -- update_channel | stable supervisor_version | supervisor-2021.10.8 docker_version | 20.10.8 disk_total | 13.9 GB disk_used | 7.0 GB healthy | true supported | true board | rpi3 supervisor_api | ok version_api | ok installed_addons | Terminal & SSH (9.2.1), Syncthing (1.18.3), Signal (10.16.0), Z-Wave JS (0.1.47)
Lovelace dashboards | 2 -- | -- resources | 4 views | 9 mode | storage

Il est où le panel "informations zigbee" ?

max5962 commented 2 years ago

La dernière à jour normalement:

System Health

version core-2021.11.2 installation_type Home Assistant OS dev false hassio true docker true user root virtualenv false python_version 3.9.7 os_name Linux os_version 5.10.17-v7 arch armv7l timezone Europe/Paris Home Assistant Community Store Home Assistant Cloud Home Assistant Supervisor Lovelace Il est où le panel "informations zigbee" ?

image Just ici :)

MichaelBitard commented 2 years ago

Ha ok, en anglais c'est zigbee device signature :)

{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4151, maximum_buffer_size=127, maximum_incoming_transfer_size=100, server_mask=11264, maximum_outgoing_transfer_size=100, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x0053",
      "in_clusters": [
        "0x0000",
        "0x0003",
        "0x0702",
        "0x0b01",
        "0x0b04",
        "0xff66"
      ],
      "out_clusters": [
        "0x0019"
      ]
    },
    "242": {
      "profile_id": 41440,
      "device_type": "0x0061",
      "in_clusters": [
        "0x0021"
      ],
      "out_clusters": [
        "0x0021"
      ]
    }
  },
  "manufacturer": "LiXee",
  "model": "ZLinky_TIC",
  "class": "zigpy.device.Device"
}

J'imagine que si quirk il y a, ça sera ici : https://github.com/zigpy/zha-device-handlers par contre mes compétences s'arrêtent là malheureusement.

max5962 commented 2 years ago

Ha ok, en anglais c'est zigbee device signature :)

{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4151, maximum_buffer_size=127, maximum_incoming_transfer_size=100, server_mask=11264, maximum_outgoing_transfer_size=100, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x0053",
      "in_clusters": [
        "0x0000",
        "0x0003",
        "0x0702",
        "0x0b01",
        "0x0b04",
        "0xff66"
      ],
      "out_clusters": [
        "0x0019"
      ]
    },
    "242": {
      "profile_id": 41440,
      "device_type": "0x0061",
      "in_clusters": [
        "0x0021"
      ],
      "out_clusters": [
        "0x0021"
      ]
    }
  },
  "manufacturer": "LiXee",
  "model": "ZLinky_TIC",
  "class": "zigpy.device.Device"
}

J'imagine que si quirk il y a, ça sera ici : https://github.com/zigpy/zha-device-handlers par contre mes compétences s'arrêtent là malheureusement.

La mise à jour a permit de remonter plus d'informations. (étonnant car il est noté nul part dans le changelog un upgrade de la lib zigpy )

Plus qu'à corriger l'unité/virgule et vérifier qu'il y ai bien une évolution des métriques :)

Après quelques jours de suivis, la remontée est hératique, parfois j'en ai tous les heures, parfois plusieurs heures sans rien. Espérons qu'une intégration ZHA réel corrige tout ça :)

pdecat commented 2 years ago

Pour info, j'ai ouvert une issue pour l'ajout du quirk : https://github.com/zigpy/zha-device-handlers/issues/1146

N0ciple commented 2 years ago

J'ai creusé un peu la question pour faire un quirk. Il y a quelques subtilités sur comment remonter les infos qui ne fonctionnent pas encore. La puissance par exemple: avec Zlinky c'est remonté sur le endpoint 1, Cluster 0x0B04, attribut 0x050F. Si l'on regarde dans gérer les clusters, c'est l'attribut apparent_power. image Hors, celui qui est remonté par ZHA comme sensor, c'est active_power. image Ces deux valeurs proviennent du même cluster (0xB04, "ElectricalMeasurement") et il semblerait que ZHA ne permette qu'un sensor par cluster : https://github.com/zigpy/zha-device-handlers/issues/605#issuecomment-753713044 L'info n'est pas super récente. Je ne sais pas si c'est encore le cas. Si ça l'est, je pense qu'il faut écrire un quirks qui prend la valeur de "apparent_power" et la renvoie pour "active_power".

Pour ce qui est du voltage, je crois que le mode historique ne renvoit pas cette info, c'est seulement le mode standard. @fairecasoimeme pourra surement confirmer. Ayant mon linky en mode historique je ne peux pas tester.

Les info de courrant fonctionnent bien.

L'index de consommation fonctionne correctement mais il faut explicitement demander la valeur dans le menu "gérer les clusters" pour que ce soit mis à jour. Je ne sais pas pourquoi c'est comme ça, mais je ne suis pas le seul dans ce cas : https://github.com/fairecasoimeme/Zlinky_TIC/issues/19#issue-1048835803 Il faut peut être spécifier dans le quirk sur c'est une valeur à actualiser. C'est à creuser...

J'ai commencé à faire le quirk et pour l'instant j'en suis là :

from zigpy.quirks import CustomDevice
from zigpy.types import basic
from zhaquirks import Bus, LocalDataCluster
from zigpy.profiles import zha

from zhaquirks.const import (

    DEVICE_TYPE,
    ENDPOINTS,
    INPUT_CLUSTERS,
    MODELS_INFO,
    OUTPUT_CLUSTERS,
    PROFILE_ID,
)

from zigpy.zcl.clusters.general import (
    Basic,
    GreenPowerProxy,
    Identify,
    Ota,
)
from zigpy.zcl.clusters.smartenergy import Metering
from zigpy.zcl.clusters.homeautomation import (
    ElectricalMeasurement,
    MeterIdentification

)

LIXEE = "LiXee"

class ZLinkyTIC(CustomDevice):
    """ZLinky_TIC from LiXee"""
    signature = {
        MODELS_INFO: [(LIXEE, "ZLinky_TIC")],
        ENDPOINTS:{
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.METER_INTERFACE,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    Identify.cluster_id,
                    Metering.cluster_id,
                    MeterIdentification.cluster_id,
                    ElectricalMeasurement.cluster_id,
                    0xff66, # Manufacturer Specific
                ],
                OUTPUT_CLUSTERS : [
                    Ota.cluster_id
                ]

            },
            242: {
                PROFILE_ID: 41440,
                DEVICE_TYPE: 0x0061,
                INPUT_CLUSTERS: [
                    GreenPowerProxy.cluster_id
                ],
                OUTPUT_CLUSTERS: [
                    GreenPowerProxy.cluster_id
                ]

            }
        }
    }
    replacement= {}

Pour le endpoint 242, je n'ai rien trouvé dans zigpy pour le PROFILE_ID et DEVICE_TYPE, donc j'ai hardcodé les valeurs.

Il faut maintenant remplir le dictionnaire replacement. Il faudra probablement créer un cluster ElectricalMeasurement custom pour faire ce que je décrivais plus haut (renvoyer la valeur de apparent_power pour active_power), et peut être d'autres choses, mais pour l'instant je ne sais pas encore bien comment faire ça.

N0ciple commented 2 years ago

Je crois que développer un quirk n'est pas ce qu'il faudrait faire (ou en tout cas pas la seule chose à faire). Le problème vient du fait que ZHA n'a pas de sensor pour apparent_power mais en a un pour active_power (pour la partie power). Visiblement c'est pas bien compliqué de rajouter un sensor pour un nouvel attribut. cf ici (et également les classes du dessous ElectricalMeasurementRMSCurrent, etc...) Il faut juste spécifier correctement les attributs du cluster. L'unité Volt-Ampères existe déjà dans Home Asisstant, pas besoin de la céer.

Je crois que quelque chose comme ça devrait être suffisant :

@MULTI_MATCH(channel_names=CHANNEL_ELECTRICAL_MEASUREMENT)
class ElectricalMeasurementApparentPower(ElectricalMeasurement, id_suffix="apparent_power"): # pas sûr pour le id_suffix
    """Apparent Power measurement."""

    SENSOR_ATTR = "apparent_power"
    _device_class = DEVICE_CLASS_POWER
    _unit = POWER_VOLT_AMPERE
    _div_mul_prefix = "ac_power"

    @property
    def should_poll(self) -> bool:
        """Poll indirectly by ElectricalMeasurementSensor."""
        return False

Cependant ça va bloquer. En effet, les devices de la classe power ne supportent (pas encore) les Volt-Ampères comme unité : https://github.com/home-assistant/core/issues/57236

On peut toujours dire qu'il s'agit de Watt en changeant POWER_VOLT_AMPERE par POWER_WATT. Puisqu'un Watt est homogène à une puissance et un Volt-Ampère aussi. Physiquement ce n'est pas faux mais c'est pas la bonne unité en pratique. (Pour les histoire d'homogénéité, voir ici spécifiquement la section Principes généraux d'homogénéité)

Je crois qu'il faudra quand même faire un quirk pour définir les ac_power_multiplier et ac_power_divisor (0X0604 et 0X0605 du cluster ElectricalMeasurement). Sinon le sensor va multiplier par None et on aura pas de valeur exploitable.

N0ciple commented 2 years ago

Bonne nouvelle, il suffit "juste" de rajouter un nouveau sensor comme je le disais dans mon dernier post et ça fonctionne (enfin presque) : image

J'ai testé en éditant le fichier homeassistant/components/zha/sensor.py. Dans une installation Docker il est situé dans /usr/src/homeassistant. Si vous faites la manip, attention à bien importer POWER_VOLT_AMPERE dans le from homeassistant.const import ... Pas de problèmes avec l'unité en Volt-Ampères finalement. Il reste cependant le problème de l'actualisation. Tout comme l'indexe de consommation, il faut explicitement demander via l'interface "gérer les clusters" la valeur du champ pour qu'il soit mis à jour. Peut-être est-ce lié à cette isssue https://github.com/fairecasoimeme/Zlinky_TIC/issues/24 ?

N0ciple commented 2 years ago

J'ai fait la PR qui est ici : https://github.com/home-assistant/core/pull/59857

pdecat commented 2 years ago

Il reste cependant le problème de l'actualisation. Tout comme l'indexe de consommation, il faut explicitement demander via l'interface "gérer les clusters" la valeur du champ pour qu'il soit mis à jour.

La réponse semble avoir été apportée dans la PR: https://github.com/home-assistant/core/pull/59857#discussion_r751705878

N0ciple commented 2 years ago

Il reste cependant le problème de l'actualisation. Tout comme l'indexe de consommation, il faut explicitement demander via l'interface "gérer les clusters" la valeur du champ pour qu'il soit mis à jour.

La réponse semble avoir été apportée dans la PR: home-assistant/core#59857 (comment)

Oui effectivement je n'avais pas vu qu'il fallait rajouter l'attribut à cet endroit également ! Malheureusement ce n'était pas le seul soucis qui bloquait l'actualisation 😕. J'ai testé en faisant la correction en local et l'actualisation ne se fait toujours pas. Le problème ne vient peut-être pas de ZHA 🤔. Un autre indice qui va dans ce sens, c'est que l'indexe de consommation est déjà intégré dans ZHA ici (et également la partie reporting ici). L'actualisation fonctionne sur d'autres appareils Zigbee, mais pas pour le Zlinky_TIC. Je corrigerai la PR en ajoutant la partie reporting et aussi les test qui sont manquants pour que la PR soit acceptée. Il restera le quirk pour convertir les Wh en KWh pour l'indexe de consommation, mais ça, ça ne devrait pas être trop compliqué :crossed_fingers:

N0ciple commented 2 years ago

La Pull Request sur ZHA est mergée 🥳 ! Ici le lien de la pull request pour le quirk : https://github.com/zigpy/zha-device-handlers/pull/1161 Le quirk sert juste à convertir les Wh en kWh pour pourvoir l'intégrer dans la partie Energie de home assistant.

Malheureusement, l'actualisation de l'index de consommation ne fonctionne pas. Cependant j'avais dit une bétise. J'ai une autre prise en zigbee qui rapport l'indexe et effectivement celui ci ne semple pas s'actualiser tout seul. Il doit falloir creuser du côté ZHA pour ça. Mais l'actualisation de la puissance en VA fonctionne elle !

@ralmn, est-ce que dans votre version du external_converters pour le ZLinky_TIC l'index de consommation s'actualise bien tout seul sans qu'il soit besoin d'aller requêter la valeur manuellement ?

ralmn commented 2 years ago

Non je suis obligé (comme pour pas mal de valeur) de lire la valeur périodiquement. Comme indiqué en #24 il faudra attendre une nouvelle version du firmware

max5962 commented 2 years ago

Hello,

Donc si je résume l'état des lieux :

J'ai tout bon ? ;)

D'autres choses avant d'avoir d'avoir une intégration au petits ognons ?

N0ciple commented 2 years ago

@max5962 C'est presque ça. Pour ce qui est du troisième point, ce n'est pas via un quirk mais via une modification directement dans l’intégration zha.

Pour info les sensors dispo dans zha (avant la PR) étaient rms_voltage, rms_current, active_power et current_summ_delivered (index de consommation). active_power n'est pas dispo sur ZLinky_TIC, c'est pour ça que j'ai rajouté le sensor apparent_power lui fonctionne. (Il y a une petite difference physique entre les deux, apparent_power, c'est la grandeur en Volt-Ampères que l'on peut voir sur son linky quand on appuie sur les boutons et qui correspond à la puissance apparente soutirée).

Si on résume les sensors dispo, ça nous fait : voltage, courrant, puissance apparente et indexe de consommation. Ça me semlble être les sensors plus pertinent. A savoir: le voltage n'est disponnible que sur les Linky en mode standard, pas en mode historique.

Les autres sensors (comme au pif : l'option tarifaire et la puissance souscrite) ne sont pas rapportés dans ZHA. Pour les rajoutés il faudrait faire une autre modification. Et pour le coup, pas sûr que ça soit accepté puisque ça ne servirait que pour le Zlinky_TIC.

Voilà, j'espères que c'est plus clair :ok_hand:

EDIT : Dans l'état actuel des choses, il y a 3 choses à attendre qui sont, dans l'ordre :

pdecat commented 2 years ago

@N0ciple apparent_power remonte parfaitement et se met à jour tout seul, merci ! image

pdecat commented 2 years ago

La correction de l'unité Wh en kWh fonctionne aussi parfaitement et la mise à jour se fait toute seule également.

À noter, je vois ceci dans les logs :

2021-11-20 10:30:10 WARNING (Recorder) [homeassistant.components.sensor.recorder] sensor.lixee_zlinky_tic_electrical_measurement_apparent_power has unknown unit VA
2
max5962 commented 2 years ago
  • u ZLinky_TIC soit dispo (pour la partie actualisation automatique)

Une nouvelle version est disponible ou vous avez modifié votre instance locale ?

pdecat commented 2 years ago

Une nouvelle version est disponible ou vous avez modifié votre instance locale ?

Il s'agit d'un environnement de développement local.

N0ciple commented 2 years ago

La correction de l'unité Wh en kWh fonctionne aussi parfaitement et la mise à jour se fait toute seule également.

À noter, je vois ceci dans les logs :

2021-11-20 10:30:10 WARNING (Recorder) [homeassistant.components.sensor.recorder] sensor.lixee_zlinky_tic_electrical_measurement_apparent_power has unknown unit VA
2

Oui effectivement, l'unité Volt-Ampère existe mais je crois qu'elle n'a pas été ajouté comme une unité de puissance, ce qui explique le warning. Mais ça n'empêche pas le bon fonctionnement je crois. La documentation ne donne que les Watts comme unité de puissance : https://developers.home-assistant.io/docs/core/entity/sensor/

@pdecat avec la modif du quirk en local, même l'index de conso en kWh est bien updaté automatiquement ? Pour ma part je croyais que c'était le cas mais en fait c'était juste mis à jour au redémarrage de HA ou en requêtant la valeur à la main.

seblang commented 2 years ago

Bonjour j'ai acheté un module ZLinky_TIC que j'ai recu recemment mais je n'arrive pas a avoir la conso ! Il a été reconnu comme le votre dans le module zigbee de HA mais après je n'ai pas vraiment compris comment vous avez pu avoir la conso instantannée! dsl je suis pas un psecialiste....une petite explication ou tuto serait cool merci d'avance a vous

N0ciple commented 2 years ago

Bonjour @seblang,

Toutes les personnes ici (moi y compris) qui ont des infos que vous n'avez pas ont modifié les fichiers en local à la main pour avoir de nouvelles fonctionnalités.

La bonne nouvelle c'est que nous avons fait en sorte que ces modifications soient intégrées dans home assistant. Cependant, depuis que ces modifications ont été intégrées dans le code de home assistant, il n'y a pas eu de mise à jour de publiées.

Si tout va bien, dans la prochaine version de home assistant (2021.12.0 j'imagine), la puissance apparente soutirée sera disponible. Il y a également un quirk qui permettra entre autre de faire la conversion Wh vers kWh pour l'indexe de consommation; Cependant, je ne suis pas sûr que ce quirk sera intégré dans la prochaine version de home assistant, il faudra peut-être attendre encore un peu.

Et pour finir, l'indexe de consommation ne se met pas à jour tout seul. Je crois que ça sera réglé dans le prochain firmware sur ZLinky_TIC. Mais là encore, il faudra attendre encore peu qu'il soit publié.

pdecat commented 2 years ago

@pdecat avec la modif du quirk en local, même l'index de conso en kWh est bien updaté automatiquement ? Pour ma part je croyais que c'était le cas mais en fait c'était juste mis à jour au redémarrage de HA ou en requêtant la valeur à la main.

La mise à jour automatique fonctionnait bien au début presque toute la journée du 20 novembre, puis ça s'est arrêté, et ça a re-fonctionné pendant ~4 heures le 21 et ~2 heures le 23 : image

Le début de chacune de ces périodes semble correspondre aux redémarrages de mon instance HA.

seblang commented 2 years ago

Hello merci pour ce retour et surtout pour le boulot que vous avez fait.

Possible de partager les modifications à faire manuellement (et ou) en attendant l. Éventuelle mise à jour de Ha et du quirk?

Autre question j'ai cru comprendre qu'il faut être que le linky soit en standard et non en historie.... Du coup faut demander à enedis le changement.

Bon dimanche à tous Seb

ElieDeloumeau commented 2 years ago

@pdecat avec la modif du quirk en local, même l'index de conso en kWh est bien updaté automatiquement ? Pour ma part je croyais que c'était le cas mais en fait c'était juste mis à jour au redémarrage de HA ou en requêtant la valeur à la main.

La mise à jour automatique fonctionnait bien au début presque toute la journée du 20 novembre, puis ça s'est arrêté, et ça a re-fonctionné pendant ~4 heures le 21 et ~2 heures le 23 : image

Le début de chacune de ces périodes semble correspondre aux redémarrages de mon instance

Même problème ici, ça vient du firmware ou de zha ?

seblang commented 2 years ago

@N0ciple

La version 2021.12.0 vient de sortir pouvez vous me confirmer si la modification et le quirk y sont intégré. Cordialement Sébastien

N0ciple commented 2 years ago

Bonjour @seblang,

Désolé de ne pas vous avoir répondu sur les modifications à faire, je pensais que la nouvelle version de home assistant arriverait bien plus tôt !

La version 2021.12.0 intègre bien le nouveau sensor pour la puissance apparente, et le quirk qui corrige l'unité de l'index de consommation (en tout cas pour ce qui est du tarif "base"). Ce dernier est maintenant bien en kWh.

Le seul souci qui reste est le fait que l'index de consommation ne s'actualise pas tout seul. Il me semble que le problème est connu et qu'il faut attendre un nouveau firmware de @fairecasoimeme.

Pour info, le sensor electrical_measurement qui rapporte la puissance consommée en W n'est pas disponible bien que le sensor existe, il rapportera donc toujours -32768. Le compteur Linky ne donne pas cette information (puissance active) mais la puissance apparente (qui elle est maintenant disponible). Vous pouvez donc le désactiver dans l'interface 👌.

Le sensor electrical_measurement_rms_voltage devrait fonctionner si vous avez un Linky en mode standard. S'il est en mode historique, cette information n'est pas remontée (et ça affichera 65535 en continu. Mon Linky est en mode historique donc je n'ai pas pu tester. Si vous constatez un problème d'unités, n'hésitez pas à le signaler, on pourra toujours modifier le quirk pour corriger l'unité.

seblang commented 2 years ago

Bonjour

Est ce que les informations du cluster 0xFF66 sont remonté dans zha ? Dans z2m ces informations ne remonte pas. D'avance merci Bonne semaine Seb

N0ciple commented 2 years ago

Bonjour @seblang,

Je ne crois pas que les infos de ce cluster remontent, en tout cas pas comme un sensor et ZHA ne permet pas de requêter via un service la valeur d'un cluster en particulier. Peut-être qu'avec le quirk de @pdecat ça sera possible d'y acceder "à la main" via le menu gerer les clusters mais pas de manière simple je pense.

max5962 commented 2 years ago

Hello @fairecasoimeme , Des nouvelles de la mise à jour du firmware permettant une remontée régulière de l'ndex ?

La version 2021.12.0 intègre bien le nouveau sensor pour la puissance apparente, et le quirk qui corrige l'unité de l'index de consommation (en tout cas pour ce qui est du tarif "base"). Ce dernier est maintenant bien en kWh.

Le seul souci qui reste est le fait que l'index de consommation ne s'actualise pas tout seul. Il me semble que le problème est connu et qu'il faut attendre un nouveau firmware de @fairecasoimeme.

Merci beaucoup :) maxime

ElieLiabeuf commented 2 years ago

La version 3.0 a été release (https://github.com/fairecasoimeme/Zlinky_TIC/releases/tag/V3.0) et d'après le change log ("Fix config report bug on cluster 0x702") elle devrait corriger l'issue https://github.com/fairecasoimeme/Zlinky_TIC/issues/24. J'ai flashé mon Zlinky_TIC, le numero de version est bien passé a 3.0.

Malheuresement cela ne semble pas corriger le problème d'update du "metering_summation_delivered" : image

Le "electrical_measurement_apparent_power" semble bien fonctionner lui : image

max5962 commented 2 years ago

Merci pour le test @ElieLiabeuf Une idée @fairecasoimeme @N0ciple ?

fairecasoimeme commented 2 years ago

je vais refaire des tests de mon côté dès que j'ai du temps, mais il me semble que le config report fonctionne sur cet attribut.

N0ciple commented 2 years ago

J'ai mis à jour en version 3.0 en flashant manuellement. Home assistant continue de rapporter Firmware: 0x00000001. En requêtant à la main le bon cluster j'ai pu vérifier que la mise à jour s'était bien faite et que j'étais bien en version 3.0.

J'ai reconfiguré et même supprimé puis rajouté le Zlinky et je confirme que je n'ai toujours pas d'actualisation de l'indexe chez moi.

J'ai une prise connectée (Innr SP120) chez moi qui marche aussi en Zigbee, et l'indexe de conso n'est pas actualisé automatiquement non plus (en tout cas, pas sur une période de quelques minutes où j'ai testé, alors que les autres infos étaient actualisées). Il semble qu'il y avait un problème sur ZHA avec ce sensor : https://github.com/home-assistant/core/issues/59081

Mais je n'ai pas vraiment compris si le problème venait de l'appareil et son firmware ou bien de l'intégration.

Peut-être que ceux qui utilisent d'autres intégrations savent si la mise à jour se fait automatiquement pour eux ou pas maintenant (ping @ralmn)

N0ciple commented 2 years ago

En attendant, il est possible de forcer l'actualisation "à la main" avec un script.

La première chose à faire et d'avoir un token d'acces longue durée. Pour se faire, allez sur votre instance home assistant, cliquez sur votre photo de profil tout en bas à gauche, puis allez tout en bas dans la section Jetons d'accès de longue durée. Cliquez sur Créer un jeton, donnez lui un nom puis cliquez sur ok. Le jeton apparait. Copiez le et gardez le bien précieusement jusqu'a ce que l'on l'insère dans le script puisqu'il ne réapparaîtra pas ! Ne partagez pas ce jeton ! il permet d'accéder à votre instance home assistant sans mot de passe.

Ensuite il faut créer un script, par exemple dans un fichier hass_zlinky.py:

import asyncio
import websockets
import json
import datetime

auth_payload = {
  "type": "auth",
  "access_token": "votre-token-acces-longue-durée" # A modifier
}

querry_payload = {
    "ieee": "identifiant-ieee-de-votre-zlinky",   # A modifier
    "endpoint_id": 1,
    "cluster_id": 1794,
    "cluster_type": "in",
    "attribute": 0,
    "type": "zha/devices/clusters/attributes/value",
    "id": 1
}

SLEEP_INTERVAL = 20    # en secondes

async def hello():
    while True:
        try:
            async with websockets.connect("ws://<ip+port-de-home-assistant>/api/websocket") as websocket:  # a changer !
                await websocket.recv()
                await websocket.send(json.dumps(auth_payload))
                await websocket.recv()
                await websocket.send(json.dumps(querry_payload))
                await websocket.recv()
            await asyncio.sleep(SLEEP_INTERVAL)
        except Exception as e::
            print("Error")
            print(e)
            await asyncio.sleep(SLEEP_INTERVAL)

asyncio.run(hello())

N'oubliez pas de changer :

Pour que le script s'exécute sans soucis, il faut installer websockets (ne pas oublier le "s" ! sans le "s" c'est un package différent. Ça peut se faire comme ça : pip install websockets

Maintenant il faut faire tourner le script, vous pouvez faire simplement python hass_zlinky.py et vous devriez voir les valeurs se mettre à jour dans home assistant. Cependant pour faire tourner le manière automatique ce script, vous pouvez faire comme ceci (attention ça ne marche que sur Linux): Il faut commencer par installer tmux comme ceci : sudo apt install tmux. Je ne rentre pas trop dans les détails mais il s'agit d'un utilitaire pour faire touner des programmes dans un terminal "détaché" : le programme continue de tourner en arrière plan même si on ferme le terminal.

(petit cours express : pour lancer un tmux on peut faire tmux new-session -s ma_session. Pour quitter sans l'interrompre il faut faire ctrl + b puis d. Pour voir les sessions qui tournent, il faut faire tmux list-sessions .Pour revenir dans une session il faut faire tmux a -t ma_session, pour tuer une session, une fois dedans il faut faire ctrl +b puis & ou x et confirmer avec y.)

On peut lancer le script dans un tmux et il tournera donc même si tous les terminaux sont fermés. Il faut taper :

tmux new-session -d -s zlinky_updater 'python3 /chemin/absolu/vers/le/script/hass_linky.py'

(n'oubliez pas de changer /chemin/absolu/vers/le/script par le chemin correspondant)

Ensuite le mieux est de lancer ce script dès le démarrage de l'ordi qui le fera tourner dans un tmux. J'utilise cron avec l'instruction @reboot. Il fau faire contab -e pour rentrer en mode edition, puis ajouter la ligne suivante :

@reboot sleep 120 && tmux new-session -d -s zlinky_updater 'python3 /chemin/absolu/vers/le/script/hass_linky.py'

C'est important de laisser le sleep !

Naturellement il faut que l'ordi reste allumé pour que ça fonctionne. C'est pourquoi c'est une bonne idée de faire cette manip sur le serveur qui fait touner home assistant !

Voilà l'astuce que j'ai trouvé pour mettre à jour les valeurs de l'indexe. C'est un peu pénible à mettre en place mais ça marche bien. J'ai remarqué quelque fois cependant que durant quelques minutes, le Zlinky renvoyait 0 ce qui fausse un peu les valeurs. @fairecasoimeme j'imagine que c'est un problème côté Linky ? Pour info j'ai remarqué que ça se produisait assez souvent vers 3h du matin mais ça m'est aussi arrivé vers 8h.

Pofilo commented 2 years ago

Hello ! Plutôt que de lancer le script dans un tmux, on peut aussi simplement utiliser &.

Le symbole & permet de faire tourner la commande en arrière plan comme le montre le man bash:

If a command is terminated by the control operator &, the shell executes the command in the background in a subshell. The shell does not wait for the command to finish, and the return status is 0.

pdecat commented 2 years ago

J'ai mis à jour en version 3.0 en flashant manuellement. Home assistant continue de rapporter Firmware: 0x00000001

J'ai également fait la mise à jour aujourd'hui et Home Assistant affiche bien la nouvelle version :

image

pdecat commented 2 years ago

Pour rafraîchir certains attributs, il est également possible d'utiliser https://github.com/mdeweerd/zha-toolkit et d'invoquer le service zha_toolkit.execute via une automatisation basée sur l'heure:

- id: read_zlinky_summation_delivered_every_minute
  alias: Read ZLinky_TIC summation delivered every minute
  description: ''
  trigger:
  - platform: time_pattern
    hours: '*'
    minutes: /1
    seconds: '0'
  condition: []
  action:
  - service: zha_toolkit.execute
    data:
      ieee: 01:23:45:67:89:10:11:12
      command: attr_read
      cluster: 1794
      attribute: 0
      endpoint: 1
  mode: single
MichaelBitard commented 2 years ago

Merci beaucoup pour le script @N0ciple .

Je ne comprends pas pourquoi on ne peut pas faire appel au service plutôt :

service: zha.issue_zigbee_cluster_command
data:
  ieee: MONIEEEE
  endpoint_id: 1
  cluster_id: 1794
  cluster_type: in
  command_type: server
  command: 0
N0ciple commented 2 years ago

Merci @Pofilo, effectivement c'est plus simple avec &. J'utilise pas mal tmux par ailleurs donc j'ai pas vraiment réfléchis mais c'est vrai que dans ce cas c'est pas nécessaire de sortir un truc aussi avancé !

@pdecat Merci je savais pas que ça existait ! effectivement ça évite de faire un script et c'est plus simple aussi ! Pour ce qui est du firmware c'est étrange... J'ai fait la mise à jour en flachant avec un FTDI, pas en OTA. J'imagine que tu as fait pareil ? Quand je requête le l'attribut 0x4000 (SWBuildID) du cluster 0x0000 j'ai 4000-0003 (3 comme version 3 je pense) alors que la doc qui n'a pas encore été mis à jour indique que c'est normalement 4000-0001 (comme version 1 j'imagine). C'est pour ça que je pense que ça a bien été mis à jour.

@MichaelBitard Je crois ne suis pas sûr mais j'avais regardé et il me semble que issue_zigbee_cluster_command c'est pour envoyer une commande (comme on/off), mais pas pour requêter une info. Tu peux essayer d'envoyer la commande via la console développeur mais tu verras que ça n'actualise pas la valeur de l'indexe (en tout cas chez moi) :wink:

pdecat commented 2 years ago

Pour ce qui est du firmware c'est étrange... J'ai fait la mise à jour en flachant avec un FTDI, pas en OTA. J'imagine que tu as fait pareil ?

J'ai fait la mise en OTA avec ZHA: https://github.com/zigpy/zigpy/wiki/OTA-Device-Firmware-Updates

pdecat commented 2 years ago

Je ne comprends pas pourquoi on ne peut pas faire appel au service plutôt :

Le service zha.issue_zigbee_cluster_command ne permet pas de lire un attribut. Ce qu'il faudrait, c'est le pendant de zha.set_zigbee_cluster_attribute, zha.get_zigbee_cluster_attribute mais ça n'est pas implémenté dans ZHA.