Linky Mode (0xFF66/0x0300) renvoie parfois 0 (V12/V14)

[py-g]

Bonjour @fairecasoimeme

Je rencontre un problème avec la lecture de "Linky Mode" : Cluster 0xFF66 / Attribut 0x0300
Je reçois fréquemment la valeur 0 au lieu de celle attendue.
J'ai fait le test sur :

• ZLinky_TIC en V12 qui se trouve être en mode historique / triphasé
  La valeur renvoyée est la plupart du temps 2, ce qui est attendu. Mais de temps en temps elle renvoie 0
• ZLinky_TIC en V14 qui se trouve être en mode standard / monophasé
  La valeur renvoyée est la plupart du temps 1, ce qui est attendu. Mais de temps en temps elle renvoie 0 aussi.

Je me suis "amusé" à mettre un timer qui lit la valeur toutes les secondes et les 0 ne sont pas si rares.

Je suis étonné de n'avoir trouvé aucune trace de ce problème ailleurs, donc je n'exclus pas qu'il puisse y avoir un souci de mon côté, mais étant donné que tout le reste fonctionne parfaitement bien, je m'interroge...
Pour info, j'utilise une passerelle Zigbee ZB-GW03 sous Tasmota 14.2 et les autres opérations de lecture, config des reporting et réception des reports se passent bien.

J'en profite pour faire une suggestion.. Je ne sais pas si c'est possible, mais un rapport qui préviendrait d'un changement de période tarifaire serait le bienvenu et m'éviterait le seul polling que je suis obligé de faire.
En gros, PTEC en historique (mais est-ce possible sur des strings ?) et en standard NTARF, LTARF ou STGE (les trois révèlent un changement de tarif mais aucun n'est reportable)

Je suis à ta disposition pour plus de détails si nécessaire et plein de reconnaissance pour ton super boulot !

[fairecasoimeme]

Bonjour,
dans tes tests, as-tu des logs ? c'est uniquement en zigbee ou y a-t-il MQTT utilisé ?

Pour PTEC, c'est prévu dans la prochaine version. Concernant STGE, c'est déjà le cas, à chaque changement de valeur STGE est envoyé au coordinateur.

[py-g]

Bonjour,

J'avais loupé l'info concernant STGE... Super, un polling en moins ! Quant à PTEC, très bonne nouvelle pour la prochaine version !
Mon code est en Berry script et il s'agit de la réponse en zigbee, avant que le message ne soit envoyé en MQTT (ce que j'annule d'ailleurs dans ce cas de figure)
Il se déroule dans attributes_refined qui permet de parcourir les attributs d'un message reçu en zigbee.
En gros ça donne quelque chose comme ça pour la réception:

def attributes_refined(event_type, frame, attr_list, idx)
  if idx != zlinky_addr return end
  for i: 0..attr_list.size()-1
    # LiXee private
    if attr_list.item(i).cluster == 0xFF66 
      # FF66/0300 Linky Mode (historique/standard, monophase/triphase, production/consommation)
      if attr_list.item(i).attr_id == 0x0300
        print(">>>>>>>>>>>>>> Linky Mode:", attr_list.item(i).val)
      end
    end
  end
end

Et je teste en envoyant une commande de lecture sur timer du style
ZbSend {"device":"0x'+zlinky_addr_str+'","endpoint":"0x01","cluster":"0xFF66","read":"0x0300"}

Pour les logs, désolé je colle une image (pas simple à copier coller autrement)
Ici, c'est quand ça fonctionne:

Et là quand ça renvoie 0:

EDIT:
En parcourant les issues, je me suis demandé si certains problèmes n'étaient pas liés justement à la détection du mode comme ici par exemple.
L'exemple cité n'est peut-être pas bon, mais quoi qu'il en soit, quand on veut configurer automatiquement la communication avec le ZLinky_TIC, tout repose sur cette valeur associée à la formule tarifaire. Donc ça pourrait finalement concerner du monde.

[fairecasoimeme]

Bonjour,

Le mode est reinitialisé juste avant chaque traitement du groupe des messages Linky.
Pour le mode historique, c'est reinitialisé à 0 et en mode standard réintialisé à 1.

En mode historique, je comprendrais que si la demande du mode est faite juste avant le décodage (moins d'1 seconde entre la réinitialisation et le nouveau mode) il renvoit 0.
Par contre pour le mode standard, à aucun moment le ZLinky ne peut renvoyer 0. Le seul cas où s'est possible, c'est lors du démarrage de l'appareil où le résultat du mode peut prendre du temps.

[py-g]

Bonjour,

Je viens de vérifier à nouveau et malheureusement je constate bien le problème dans les deux modes.
Puisque ça semble possible en historique mais pas en standard (ce qui reste problématique à mon avis) je me suis penché plus particulièrement sur le mode standard.
Les lectures qui renvoient 0 arrivent groupées.
J'ai joué avec le délai entre deux lectures de la TIC et ça influe sur le résultat.
Ça me donne l'impression que ça se produit lorsque la lecture en zigbee (sur timer d'une seconde) se synchronise avec la lecture de la TIC, donc probablement à ce moment que tu décris comme le "traitement du groupe des messages Linky".
Et pourtant je fais bien les tests en mode standard (et sur la v14).

[fairecasoimeme]

Bonjour,

Je vais essayer de reproduire les tests et je vous tiens au courant.

[fairecasoimeme]

J'ai réussi à reproduire le phénomène je regarde ça et revient vers vous

[fairecasoimeme]

Apparemment le fait que en mode standard, le linkyMode passe à 0 c'est qu'il y a probablement un problème de démodulation du Linky et passe en test du mode historique.

Quand la démodulation est OK, j'utilise ZWGUI pour faire des requêtes en rafales sur le cluster 0xFF66 attribut 0x300 et jamais il ne passe à 0

Il faut vérifier que le ZLinky ne clignote pas toutes les secondes à certains moment (surtout quand vous détectez que le mode passe à 0)

[py-g]

Merci pour ces tests.
J'essaierai de regarder si le ZLinky clignote toutes les secondes quand le mode passe à 0.
Je ferai ça dès que possible, mais je ne suis pas au meilleur endroit actuellement pour bosser à proximité d'un Linky.
J'espère que je ne confondrai pas les clignotements attendus avec ceux que j'espère ne pas voir.. :)