Pas de remontée Heures creuse ou heures pleines avec le TIC Zigbee ZLinky

Plugins Protocole domotique
8

Hello
Merci beaucoup du retour
le module est alimenté par le compteur…
J’ai transmis tout ce que m’affiche le log quand je clique sur log dans les paramètres avancés de l’équipement.
Par contre, c’est du HP, je reçois du HCHP en heures pleines et du HCHC en heures creuses. Le nom de ces commandes à rallonge est bien mystérieux.
J’ai déjà contacté le concepteur, mais je n’ai pas eu de réponse pour l’instant.

Mais j’ai vu que d’autres personnes avaient ce module… Et avaient fini par recevoir l’information… D’où ma question de départ.
Merci encore @rennais35000 et merci d’avance aux autres

1 « J'aime »
9

Bonjour,
j’ai aussi le même module sur le plugin zigbee, avec une clé Conbee II.
Et même constat : les infos remontent bien SAUF l’indication HP/HC.
La période appelle bien la partie 1::1794::32

10

Hello @Arnaud_69
Merci de ce retour.
En étant égoïste, je dirais que c’est un peu rassurant de ne pas être tout seul. Mais au final, c’est très enquiquinant.
Et pourtant, les postes que j’ai lus avant de faire celui-ci semblaient dire qu’après avoir rencontré le même problème, ça s’était mis à fonctionner.
J’ignore au bout de combien de temps, ni s’il a fallu faire quelque chose.
Le fabriquant, relancé aujourd’hui, ne m’a pas (encore) répondu.
Bien entendu, on peut faire sans cette information :
1°) En interceptant l’arrivée d’une info HCHC puisqu’il semble que seule l’info modifiée soit transmise. Mais en fonction du cron, il est aussi possible de recevoir à la fois un HCHP et un HCHC au moment du changement. On peut s’en sortir parce qu’on connait les heures de changement, mais c’est encore de l’à peu près.
2°) En utilisant une entrée d’agenda indiquant les HC/HP (ou une variable ou un virtuel…). C’est ce que je fais aujourd’hui, mais ça crée un décalage, l’impulsion EDF n’étant pas systématiquement à l’heure précise.

Du coup je vais continuer à essayer de savoir pourquoi cette info n’est pas transmise.

Ma question d’origine reste ouverte, soit retour d’expérience de tous ceux qui possèdent ce module, soit info technique des experts qui passent par ce forum.
Merci d’avance

1 « J'aime »
11

Hello
Ma question reste ouverte…
Le fabriquant de la clé m’a répondu qu’il n’était pas le développeur du plugin (sic) et que donc il ne savait pas !!!
Pas mal, non ?
Personne ayant cette clé pour me dire si ça fonctionne ou pas pour eux ? Je ne peux pas accepter une telle réponse de la part du fabriquant, mais il me faudrait des billes…
Merci d’avance

12

Hello
Suite à une nouvelle relance, je vous joins une nouvelle réponse du fabriquant dans laquelle il explique pourquoi il pense que le problème vient du plugin.

Il n'y a aucun problème de remontée. Le module n'envoie pas de lui même les infos, il faut lui demander tout simplement.

Les logs que vous regardez sont les logs du plugins, donc après traitement du plugin.

Le linky envoie l'impulsion mais la téléinformation n'est pas pro active, elle envoie en permanence les données mise à jour, le ZLinky_TIC les reçoit et les met à la disposition du zigbee.

En conclusion, si vous voulez avoir les données, il faut les demander au module ZLinky_TIC.

Je crois que je ne vais pas m’en sortir si un dev ne passe pas par là pour m’aider.

Je ne sais pas qui est responsable, je sais que fixer mes HP/HC en fonction d’un calendrier est une solution bancale. Cette nuit j’ai reçu l’impulsion dans le cron de 1h56 (au lieu de 2h00) et celle des HP dans celui de 6h56 (au lieu de 7h00).

Moi, je n’ai hélas pas les compétences techniques pour dire à l’un ou à l’autre qui a tort ou raison.
je fais appel une nouvelle fois aux techniciens, je ne veux bien entendu pas taguer Loic puisque nous sommes sur un forum d’entraide.

Merci d’avance

1 « J'aime »
13

Bonjour,
J’ai le même soucis.
Avec les derniers éléments que tu as fourni, j’ai tenté la manipulation suivante :
Dans le plugin sur l’équipement
image
Configuration du module
Onglet Action => Lecture d’un attribut

image
image987×390 23.1 KB

Et j’ai eu un retour.
Par contre je ne sais pas si ça passera automatiquement en HC le moment venu mais au moins la commande n’est plus vide

14

Hello @kaktusatomik
Merci pour ce retour porteur d’espoirs.

J’ai eu ton message exactement 3 minutes avant le passage en HC chez moi (en principe 14h00, dans la réalité 13h55).
J’ai lancé ta manip qui m’a retourné HP exactement 5 secondes avant que Telegram (programmé pour cela), ne m’envoie un message pour m’annoncer que je venais de passer en heures creuses - j’ai créé un virtuel qui se met à jour par scénario quand le cron du module me renvoie des modifications de mes index d’heures creuses à la place de celles de l’index d’heures pleines.

Du coup j’ai refait à nouveau la même manip sur Tic metering attribut 32, mais ça me donne toujours HP (alors que mon virtuel heureusement est bien en HC).

Donc, ça ne suffit pas. Je ne sais pas à quoi correspond 1794-ZLinkyTicmetering, 32, mais puisqu’il s’agit d’une info, je ne sais pas où le plugin la récupère, mais elle est fausse.
Dans l’équipement, la commande « Periode tarifaire en cours » est toujours à HP - et même, peut être que le distinguo est important : "HP… "(avec deux points, je ne sais pas pourquoi ça en affiche 3 dans ce message)

Est-ce que ça confirmerait ce que dit le fabriquant, que le problème vient du plugin ?

D’autres idées pour avancer ?
Merci d’avance

15

Bonjour,

Pouvez vous montrer les infos
sur les commandes HCHC et HCHP

Le constructeur précise pour le mode historique

#c5f015 HCHC 0x0702 0x0100 RO Uint32 9 car Wh Index HCHC 0
#c5f015 HCHP 0x0702 0x0102 RO Uint32 9 car Wh Index HCHP 0

les valeurs sont en hexa il faut les mettre en décimal dans le plugin

on devrait donc trouvé 2 commandes avec ces valeurs

1::1794::256
et
1::1794::258

16

Bonjour @olive
Merci pour l’intérêt porté à ma question.
Il me semble que c’est correct dans les commandes du plugin :

  • 1::1794::256 pour le HCHC
  • 1::1794::258 pour le HCHP

HCHC et HCHP
HCHC et HCHP1901×137 20 KB

Mais quel est le rapport entre les index (qui remontent bien) et la valeur de la commande « Periode tarifaire en cours » qui ne remonte pas ?
Est-ce que c’est le plugin qui de rait calculer cette valeur directement à partir des valeurs d’index ?

merci

17

Ok c’est donc du PTEC dont vous parlez ?

PTEC 0x0702 0x0020 RO String 4 car - Periode tarifaire en cours

1::1794::32

c’est un string donc bien choisir une info autre

18

Oui c’est bien ça :+1:

la commande est bien en info/autre
image
Cette information ne semble pas remonter en même temps que les indexes, d’après le fabriquant il faut l’interroger si j’ai bien compris. D’où mon test avec l’onglet action de l’équipement.

19

Ha ça voudrait dire que cette commande ne fait pas partie du poolling ?

si ça fonctionne pas
le contournement est simple
2 scenario et une commande virtuel

  • declencheur sur HCHP met a jour l’info du virtuel avec " heures pleines "
  • declencheur sur HCHC met a jour l’info du virtuel avec " heures creuses "
20

Oui ça y ressemble.
Je ne sais pas si le mécanisme d’Auto-actualisation est prévu pour palier à ce problème

21

Je ne peut vous aider plus car j’ai pas de HP/HC …

22

Pas de soucis, merci :slight_smile:
Peut être que Phyllox n’a pas attendu les 5 minutes du cron avant de forcer la relecture de l’attribut.
Je vais laisser tourner, on verra demain si ça a changé dans la nuit.

1 « J'aime »
23

Hello
Oui j’ai attendu et refait plusieurs fois. En plus j’ai un cron à 2min…
Cec dit, je ne comprends pas vraiment le mécanisme qu’il faudrait appliquer… Un refresh ?

Je suis preneur d’infos sur ce fonctionnement (ou de liens de lecture)

Pour le scénario j’en ai fait ( un seul) sur les 2 événements… Et pour tenir compte des crons qui reçoivent en même temps une modif HP et une HC, je teste avant le changement la durée depuis le dernier changement…

Mais c’est du palliatif, devoir créer un virtuel et un scénario parce que quelque chose ne fonctionne pas, ça n’est pas normal

En tous cas, merci pour le support

24

Pour ma part la valeur change bien.

J’ai juste désactivé le Cache, fait un « Rafraichr les informations » avant de refaire la lecture de l’attribut et j’ai bien eux mon changement de valeur j’étais en HP et je suis passer en HC

25

Hello @Tarlak

Effectivement en décochant : autoriser le cache (option à laquelle je n’vais jamais prêté attention jusqu’à maintenant), quand je fais action, 794:ZLinkyTICMonitoring, valeur 32 et valider, la valeur change bien (à cette heure ci : HC… (avec deux points pas trois, impossible d’écrire 2 points ici)

C’est bien, mais en pratique, comment faire pour forcer la lecture de cette valeur pour qu’elle alimente la zone « Periode tarifaire en cours » ?

C’est moins grave depuis que j’ai mon virtuel et mon scénario, mais j’aimerais bien comprendre pourquoi le plugin ne le fait pas d’autorité.

Merci

26

Ha ca je suis bien d’accord, vu que l’équipement est capable de le récupérer j’aimerai bien aussi pouvoir me passer d’un virtuel et d’un scénario pour le faire :). Je ne trouve pas moyen de forcer ça à la main, à moins peut être de pouvoir le faire via un bloc code dans un scénario, mais bon ça fera quoi qu’il arrive un scénario à mettre en place au lieu que ce soit automatique

27

J’ai creusé un peu la question.
Voici ce qui est envoyé lors de l’exécution du cron

[2021-12-13 21:18:08]DEBUG : http://127.0.0.1:8089/device/attributes type : POST
[2021-12-13 21:18:08]DEBUG : {"ieee":"00:15:8d:00:05:be:7f:8c","endpoint":1,"cluster":1794,"cluster_type":"in","attributes":[0,256,258,260,262,264,266,32],"manufacturer":null,"allowCache":0}
[2021-12-13 21:18:08]DEBUG : [Garage][ZLinky_TIC] refresh
[2021-12-13 21:18:08]DEBUG : http://127.0.0.1:8089/device/attributes type : POST
[2021-12-13 21:18:08]DEBUG : {"ieee":"00:15:8d:00:05:be:7f:8c","endpoint":1,"cluster":65382,"cluster_type":"in","attributes":[1,2,4,5,6,7,8],"manufacturer":null,"allowCache":0}
[2021-12-13 21:18:08]DEBUG : [Garage][ZLinky_TIC] refresh
[2021-12-13 21:18:08]DEBUG : {"devices":{"00:15:8d:00:05:be:7f:8c":{"1":{"1794":{"0":{"value":"0","cluster_name":"ZLinkyTICMetering"},"256":{"value":"6595373","cluster_name":"ZLinkyTICMetering"},"258":{"value":"4090002","cluster_name":"ZLinkyTICMetering"},"260":{"value":"0","cluster_name":"ZLinkyTICMetering"},"262":{"value":"0","cluster_name":"ZLinkyTICMetering"},"264":{"value":"0","cluster_name":"ZLinkyTICMetering"},"266":{"value":"0","cluster_name":"ZLinkyTICMetering"}},"2820":{"1288":{"value":"1","cluster_name":"Electrical Measurement"},"1295":{"value":"340","cluster_name":"Electrical Measurement"},"2312":{"value":"65535","cluster_name":"Electrical Measurement"},"2568":{"value":"65535","cluster_name":"Electrical Measurement"},"1290":{"value":"90","cluster_name":"Electrical Measurement"},"2314":{"value":"65535","cluster_name":"Electrical Measurement"},"2570":{"value":"65535","cluster_name":"Electrical Measurement"},"1293":{"value":"-32768","cluster_name":"Electrical Measurement"}},"65382":{"1":{"value":"","cluster_name":"Manufacturer Specific"},"2":{"value":"0","cluster_name":"Manufacturer Specific"},"4":{"value":"0","cluster_name":"Manufacturer Specific"},"5":{"value":"0","cluster_name":"Manufacturer Specific"},"6":{"value":"0","cluster_name":"Manufacturer Specific"},"7":{"value":"0","cluster_name":"Manufacturer Specific"},"8":{"value":"0","cluster_name":"Manufacturer Specific"}}}}}}
[2021-12-13 21:18:08]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::1794::0 => 0 convert to 0
[2021-12-13 21:18:08]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::1794::256 => 6595373 convert to 6595373
[2021-12-13 21:18:08]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::1794::258 => 4090002 convert to 4090002
[2021-12-13 21:18:08]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::1794::260 => 0 convert to 0
[2021-12-13 21:18:08]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::1794::262 => 0 convert to 0
[2021-12-13 21:18:08]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::1794::264 => 0 convert to 0
[2021-12-13 21:18:08]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::1794::266 => 0 convert to 0
[2021-12-13 21:18:08]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::2820::1288 => 1 convert to 1
[2021-12-13 21:18:08]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::2820::1295 => 340 convert to 340
[2021-12-13 21:18:08]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::2820::2312 => 65535 convert to 65535
[2021-12-13 21:18:08]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::2820::2568 => 65535 convert to 65535
[2021-12-13 21:18:08]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::2820::1290 => 90 convert to 90
[2021-12-13 21:18:08]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::2820::2314 => 65535 convert to 65535
[2021-12-13 21:18:08]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::2820::2570 => 65535 convert to 65535
[2021-12-13 21:18:08]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::2820::1293 => -32768 convert to -32768
[2021-12-13 21:18:08]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::65382::1 =>  convert to
[2021-12-13 21:18:08]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::65382::2 => 0 convert to 0
[2021-12-13 21:18:08]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::65382::4 => 0 convert to 0
[2021-12-13 21:18:08]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::65382::5 => 0 convert to 0
[2021-12-13 21:18:08]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::65382::6 => 0 convert to 0
[2021-12-13 21:18:08]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::65382::7 => 0 convert to 0
[2021-12-13 21:18:08]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::65382::8 => 0 convert to 0

On observe ici que l’on demande le refresh de 8 champs [0,256,258,260,262,264,266,32]
et que l’on a le retour des 7 premiers uniquement. Et que le dernier est le 32 (le PTEC, celui qui nous intéresse ici)

Si l’on fait un appel via la procédure décrite plus haut, on voit que l’on a bien un retour sur l’attribut 32

[2021-12-13 20:43:58]DEBUG : {"ieee":"00:15:8d:00:05:be:7f:8c","endpoint":1,"cluster":1794,"cluster_type":"in","attributes":[32],"allowCache":1,"manufacturer":null}
[2021-12-13 20:43:58]DEBUG : [{"32":"HP.."},[]]

J’ai essayé de trié dans l’ordre les id des attributs et je reçoit bien le résultat pour la 32 mais plus pour la 266 (la dernière).

J’en déduis donc que l’on ne peut pas demander l’actualisation de plus de 7 attributs par requêtes.

J’ai essayé de découper en plusieurs requêtes (par lots de 7)
Voici le résultat

[2021-12-13 21:34:07]DEBUG : http://127.0.0.1:8089/device/attributes type : POST
[2021-12-13 21:34:07]DEBUG : {"ieee":"00:15:8d:00:05:be:7f:8c","endpoint":1,"cluster":1794,"cluster_type":"in","attributes":[0,256,258,260,262,264,266],"allowCache":0}
[2021-12-13 21:34:07]DEBUG : [Garage][ZLinky_TIC] refresh
[2021-12-13 21:34:07]DEBUG : http://127.0.0.1:8089/device/attributes type : POST
[2021-12-13 21:34:07]DEBUG : {"ieee":"00:15:8d:00:05:be:7f:8c","endpoint":1,"cluster":1794,"cluster_type":"in","attributes":[32],"allowCache":0}
[2021-12-13 21:34:07]DEBUG : [Garage][ZLinky_TIC] refresh
[2021-12-13 21:34:07]DEBUG : http://127.0.0.1:8089/device/attributes type : POST
[2021-12-13 21:34:07]DEBUG : {"ieee":"00:15:8d:00:05:be:7f:8c","endpoint":1,"cluster":2820,"cluster_type":"in","attributes":[1288,1295,2312,2568,1290,2314,2570],"allowCache":0}
[2021-12-13 21:34:07]DEBUG : [Garage][ZLinky_TIC] refresh
[2021-12-13 21:34:07]DEBUG : http://127.0.0.1:8089/device/attributes type : POST
[2021-12-13 21:34:07]DEBUG : {"ieee":"00:15:8d:00:05:be:7f:8c","endpoint":1,"cluster":2820,"cluster_type":"in","attributes":[1293],"allowCache":0}
[2021-12-13 21:34:07]DEBUG : [Garage][ZLinky_TIC] refresh
[2021-12-13 21:34:07]DEBUG : http://127.0.0.1:8089/device/attributes type : POST
[2021-12-13 21:34:07]DEBUG : {"ieee":"00:15:8d:00:05:be:7f:8c","endpoint":1,"cluster":65382,"cluster_type":"in","attributes":[1,2,4,5,6,7,8],"allowCache":0}
[2021-12-13 21:34:07]DEBUG : [Garage][ZLinky_TIC] refresh
[2021-12-13 21:34:07]DEBUG : {"devices":{"00:15:8d:00:05:be:7f:8c":{"1":{"1794":{"0":{"value":"0","cluster_name":"ZLinkyTICMetering"},"256":{"value":"6595373","cluster_name":"ZLinkyTICMetering"},"258":{"value":"4090059","cluster_name":"ZLinkyTICMetering"},"260":{"value":"0","cluster_name":"ZLinkyTICMetering"},"262":{"value":"0","cluster_name":"ZLinkyTICMetering"},"264":{"value":"0","cluster_name":"ZLinkyTICMetering"},"266":{"value":"0","cluster_name":"ZLinkyTICMetering"},"32":{"value":"HP..","cluster_name":"ZLinkyTICMetering"}},"2820":{"1288":{"value":"1","cluster_name":"Electrical Measurement"},"1295":{"value":"320","cluster_name":"Electrical Measurement"},"2312":{"value":"65535","cluster_name":"Electrical Measurement"},"2568":{"value":"65535","cluster_name":"Electrical Measurement"},"1290":{"value":"90","cluster_name":"Electrical Measurement"},"2314":{"value":"65535","cluster_name":"Electrical Measurement"},"2570":{"value":"65535","cluster_name":"Electrical Measurement"},"1293":{"value":"-32768","cluster_name":"Electrical Measurement"}},"65382":{"1":{"value":"","cluster_name":"Manufacturer Specific"},"2":{"value":"0","cluster_name":"Manufacturer Specific"},"4":{"value":"0","cluster_name":"Manufacturer Specific"},"5":{"value":"0","cluster_name":"Manufacturer Specific"},"6":{"value":"0","cluster_name":"Manufacturer Specific"},"7":{"value":"0","cluster_name":"Manufacturer Specific"},"8":{"value":"0","cluster_name":"Manufacturer Specific"}}}}}}
[2021-12-13 21:34:07]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::1794::0 => 0 convert to 0
[2021-12-13 21:34:07]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::1794::256 => 6595373 convert to 6595373
[2021-12-13 21:34:07]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::1794::258 => 4090059 convert to 4090059
[2021-12-13 21:34:07]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::1794::260 => 0 convert to 0
[2021-12-13 21:34:07]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::1794::262 => 0 convert to 0
[2021-12-13 21:34:07]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::1794::264 => 0 convert to 0
[2021-12-13 21:34:07]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::1794::266 => 0 convert to 0
[2021-12-13 21:34:07]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::1794::32 => HP.. convert to HP..
[2021-12-13 21:34:07]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::2820::1288 => 1 convert to 1
[2021-12-13 21:34:07]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::2820::1295 => 320 convert to 320
[2021-12-13 21:34:07]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::2820::2312 => 65535 convert to 65535
[2021-12-13 21:34:07]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::2820::2568 => 65535 convert to 65535
[2021-12-13 21:34:07]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::2820::1290 => 90 convert to 90
[2021-12-13 21:34:07]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::2820::2314 => 65535 convert to 65535
[2021-12-13 21:34:07]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::2820::2570 => 65535 convert to 65535
[2021-12-13 21:34:07]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::2820::1293 => -32768 convert to -32768
[2021-12-13 21:34:07]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::65382::1 =>  convert to
[2021-12-13 21:34:07]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::65382::2 => 0 convert to 0
[2021-12-13 21:34:07]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::65382::4 => 0 convert to 0
[2021-12-13 21:34:07]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::65382::5 => 0 convert to 0
[2021-12-13 21:34:07]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::65382::6 => 0 convert to 0
[2021-12-13 21:34:07]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::65382::7 => 0 convert to 0
[2021-12-13 21:34:07]DEBUG : Search attribut for 00:15:8d:00:05:be:7f:8c logicalId : 1::65382::8 => 0 convert to 0

Les 2 requêtes partent : une de 7 attributs et une de 1 et nous avons bien le résultat.

La modification apportée concerne le fichier zigbee.class.php
ligne 1002

    foreach ($datas as $endpoint => $data) {
      foreach ($data as $cluster => $attributes) {
        foreach (array_chunk($attributes, 7) as $key => $chunk) {  
          try {
            zigbee::request($this->getConfiguration('instance', 1), '/device/attributes', array(
              'ieee' => $ieee,
              'endpoint' => $endpoint,
              'cluster' => $cluster,
              'cluster_type' => 'in',
              'attributes' => $chunk,
              'allowCache' => 0
            ), 'POST');

            log::add('zigbee', 'debug', $this->getHumanName() . ' refresh');
          } catch (\Exception $e) {
            log::add('zigbee', 'info', $this->getHumanName() . ' ' . $e->getMessage());
          }
      	}
      }
    }
2 « J'aime »