[KiwiHC16] Perte complete de 3 prises BliTZOIF (Briques)

[KiwiHC16]

Suite à des inclusions multiples, j'ai 3 prises complément "Briques":

• 2 clignotent: le relai interne, claque rapidement toutes les x secondes. HS ?
• 1 ne repond plus aux solicitations sur le bouton physique : on ne peut plus controller le relai, ni faire d inclusion. HS ?

HS ? Toutes en 2 jours ? Abeille qui envoie une séquence qui les rend HS ?

Pas le début dune piste, investigations à venir.

(J'en ai au moins 4 qui fonctionnent très bien par ailleurs.)

[KiwiHC16]

[KiwiHC16]

Info sur l une qui fonctionne sur mon réseau:

[KiwiHC16]

Prise 1:

• Appui sur bouton lateral pour que la led passe en rouge
• Toutes les 16s, elle passe à Off pendant 1/4 de s puis On. Ca donne l impression qu'elle reboot...
• SI appui 7s sur bouton alors que Led Rouge, alors led bleue apprait fixe pendant 1 à 2s (Elle devrait flasher), puis relai claque, Led rouge revient et bleue éteinte
• Zigate en mode inclusion et jamais aucune trame zigbee venant de la prise
• Si Led rouge éteint alors rien ne se passe. Mais peut etre toutes le 16s ca "reboot" mais comme le relai est off et led off on ne voit rien se passer.

[KiwiHC16]

Prise 2:

• Idem Prise 1

[KiwiHC16]

Prise 3:

• rien ne bouge.

[tcharp38]

Tu as remarqué que tu étais sur le canal 15 d'apres tes logs? Peut etre une incompatibilité ?

[KiwiHC16]

Oui, j ai vu. Mais le comportement des prises qui "reboot" toutes les 16s c est meme avec zigate éteinte.

Je viens d'en ouvrir (détruire) une et le composant radio est ZT2S: https://developer.tuya.com/en/docs/iot/zt2s-module-datasheet?id=Kas9gdtath9p0 et pour flasher le code: https://developer.tuya.com/en/docs/iot/overview-of-download-firmware-and-authorization?id=Ka4zcqfo0eb5u

[tcharp38]

Mais tu dis que 3 prises sont HS en meme temps ? C'est statistiquement pas possible ca

[KiwiHC16]

Mon idée est que lors de la reconnaissance des prises, Abeille envoie des configurations que les prises n aiment pas, elles mettent ca en PROM et apres c est le bazar. Aucune preuve, aucun log. Juste un feeling par rapport au moement du plantage des prises. ET pourquoi ces trois là et pas les autres que j'ai ? Le probleme c est que je ne trouve pas comment les "réveiller"...

[tcharp38]

Incroyable ! Ca veut dire pas de HW reset sur ces prises ? Peut etre en les laisser debranchées un moment ?

[KiwiHC16]

Rien de visible au niveau hard (Rien n a brulé, ...) Tout semble Ok.

Aucune piste pour l instant.

[KiwiHC16]

Je clos car pas de lien direct avec code Abeille et la chance de trouver la raison est quasi nulle. Si je trouve des infos, je partagerai.

[KiwiHC16]

Premiere observation à vérifier, dans le modele il semble qu'une valeur manque, est ce que le code Abeille le gere ?

changeVal=

La valeur est visiblement manquante dans le message zigbee.

[KiwiHC16]

configureReporting2

[tcharp38]

Oui c'est un sujet que je voulais creuser mais avant tout ... la spec se comprend comment ?

Ces paramtres sont optionnels à priori

Une idée ?

[KiwiHC16]

Je viens de la perdre sur cette commande. Je l ai passé de configureReporting à configureReporting2 dans le modele. Sur zigbee, ca par en vrille, la prise fait un volume incroyable de "report", puis rien puis "reset" toutes les 16s sans plus qucun message zigbee.

[KiwiHC16]

Ca balance des routes requests alors que je n ai que la zigate et la prise sur ce reseau.

Ne reagit plus avec le bouton sur le coté.

Ne repond plus à aucune commande demandée par Abeille. En fait la zigate fait un route request n'a pas de reponse, et donc n envoie pas la commande.

Finalement repond sur le bouton physique mais un appui long provoque led bleu mais pas de clignotement de celle ci et pas de beacon/Leave sur zigbee.

Je debrance et rebranche, elle fait des Route Request et des Link status donc elle est vivante mais ne repond plus à rien.

[tcharp38]

Quelle est la signature de cette prise ?

[KiwiHC16]

Bon sans acces au FW, c est mort. Je laisse tomber !

[tcharp38]

Comment ca .. une autre morte ?

[KiwiHC16]

TS011F__TZ3000_amdymr7l

[tcharp38]

Tu peux refaire une autre inclusion ou c'est mort ?

[KiwiHC16]

Oui une autre. Il faudrait pouvoir faire un reset PROM mais je n ai pas trouvé comment faire.

[KiwiHC16]

Est l accumulation de configuration qui prove ce bug ? Je veut dire que ces prises ont toutes fonctionné une premiere fois d'apres ma mémoire. Puis lors d"une inclusion ou configuration comme celle ci, je les perds.

[tcharp38]

Merde. Bon pour info de ce à quoi je pense.

Le "changeVal" est pour moi (d'apres la spec) optionnel. Donc si on donne rien dans le model on transmet rien. Ce qui fonctionne pour la plupart des cas. Peut etre que la... tu as besoin d'une valeur. Donc il faut l'ajouter au modele.

Tu as compris quel configureReporting foutait la merde ? Il y en a 3 dnas le modele actuelle: 0006-0000, 0B04-0508, & 0B04-050B

[KiwiHC16]

Je viens de la perdre sur le dernier: 0B04-050B apres avoir fait les deux autres.

[KiwiHC16]

Elle vient de le balancer un volume de report !!!

[KiwiHC16]

"params": "clustId=0B04&attrType=21&attrId=0508&minInterval=0000&maxInterval=0000&changeVal="

Une piste les min et max sont à 0000 !!!!

Elle serait dans une boucle infinie. J essaye de lui balancer un reset Usine.

J a ajouté un autre prise qui prend les messages en routeur mais ne parvient pas à les livrer à la prise en défaut.

[tcharp38]

Oui souvent le cas. Valeur par defaut

Mais effectivement wireshark n aime pas si changeVal ne vaut rien

Donc pour ce cas 0508, soit RMSCurrent, tu peux mettre 5mA => donc changeVal=5

[KiwiHC16]

Elle ne repond pas !!!

[tcharp38]

Tu as reconfiguré avec un changeVal ?

[tcharp38]

Pour info je pousse à l instant une modif pour "configureReporting2" Par defaut si pas renseigné le changeVal sera mis à 0, suivant le bon format d'attribut. Wireshark est content en tout cas

[KiwiHC16]

La prise ne repond plus à aucune commande pour l instant.

Toutes les 16s au moment ou le relai claque, elle envoie une salve de report.

Pour l instant la piste est min = max = 0 et elle boucle au point de reboot toutes les 16s.

Mon probleme est qu elle ne semble plus pouvoir accepter de commandes zigbee, car sur le sniff elle ne repond jamais.

[KiwiHC16]

Il faudrait interdire min = max et forcer un min < max par mesure de securité dans configureReporting2

[KiwiHC16]

La zigate et la prise font des routes requets mais aucunes des deux ne repond à l autre .... !!!

[tcharp38]

Pas d'accord avec l'idée de mettre une verue dans le code, qui ne suive pas la spec. A faire par module si besoin mais ca n'a jamais été mis en evidence.

Et tu mettrais quoi ?

[KiwiHC16]

Pas d'accord avec l'idée de mettre une verue

Quelle verue ?

[tcharp38]

Haaaaaa

min=0000 max=0000 c'est acceptable des lors que tu as un changeVal Suis con mais comme ca oui ca fait du sens. J'imagine que wireshark n aurait rien dit si min ou max etaient non nuls

Donc la derniere correction qui met le changeVal à 0 doit regler ce cas

[tcharp38]

Pas d'accord avec l'idée de mettre une verue

Quelle verue ?

Forcer un max > min.. Si dans le code c'est une verrue

[KiwiHC16]

En fait il faut avoir un max > 0, c est le plus important, sinon ca veut dire que le FW doit faire un report en premanance, immédiatement, des infos. Et min par definition doit être <= max. Pour moi ce n est pas une verrue c est verification de base, une verification de consistences des informations utilisateur.

min: le FW ne doit pas faire de rapport plus souvent que toutes les min secondes pour ne pas saturer le reseau. max: le FW doit faire un rapport ou moins toutes les max secondes pour avoir une information pas trop vieille.

[KiwiHC16]

Donc la derniere correction qui met le changeVal à 0 doit regler ce cas

Ca n a pas de sens. changeVal doit être au minimum de 1. C est le critere pour provoquer la generation d un rapport. Sur un binaire il faut au moins 1 d'écart, mais 1 sur une mesure de puissance qui fluctue tout le temps il var rapporter tout le temps. Donc par exemple uniquement sur 10 W de variation.

[KiwiHC16]

Pour wireshark, je confirme qu il ne decode pas le valChange. Je me souviens de cette observation il y a qq années. J ai bien les valeurs dans les raws data de wireshark mais pas dans le décodage.

[KiwiHC16]

Test avec prise OSRAM: Min = 10 et Max = 30

Sans rien faire, report toutes les 30s (d apres wireshark 27s.):

Et si On/off tout le temps sur le bouton lateral de la prise (bouton physique) toutes les 10s (Wireshark dit 10s):

Ca fonctionne bien comme prévu.

• Donc max à 0 n a pas de sens avec le risque de tomber dans un bug FW de l eq.
• Min doit être inferieur à max.
• Val doit être != 0.

Pour moi ces verifications doivent être dans le code. ( C est pas de verrue, c est des verifications de bon parametres).

Je pense que si nous ne faisons pas ces tests on prend le risque d envoyer des valeurs illogiques au FW et tomber sur des cas non testés et planter les eq comme mes prises.

A moins qu ils soient indqué que la valeur 0 desactive la fonction report associé à : min, max ou val.

Est-ce que la norme dit quelque chose sur les valeurs acceptables ?

[KiwiHC16]

Test avec prise OSRAM: Min = 0 et Max = 0 et val = 1 => rien de remonte si aucune activité. Et remonet sur chaque appuie sur bouton physique .

Ce qui voudrait dire que la valeur 0 desactive la fonction report associé à : min, max

Donc mes plantages de prise sont autre-chose que je ne trouverai jamais donc elle vont finir à la poubelle et il me faut trouver des prises qui fonctionnent correctement ;-(

[tcharp38]

Ok je résume ma compréhension du moment et ce qui devrait etre pour un "configureReporting" correct

• min=0000, max=0000 => changeVal obligatoire >= 1. On met 1 par defaut et non pas 0 et erreur si 0 dans ce cas ou voir dernier cas note: 0000=no limit
• min=max=0000 fait toujours du sens SI ET SEULEMENT SI changeVal défini donc >= 1
• min=xxxx => retour d'erreur si max < min. changeVal n'est plus obligatoire
• d'apres la spec on peut quand meme faire un configureReport.. sans AUCUN de ces parametres donc je propose que si min=max=0000 on ignore ces champs donc aussi changeVal (qui si il est passé doit etre 0 sinon erreur)

Tu serais en ligne avec ca ?

[KiwiHC16]

Je vais essayer de trouver les doc zigbee sur le sujet pour etre sure de suivre leur recommandations. Je reviens vers toi quand je trouve quelque chose. Je propose de ne rien changer pour l instant.

Sinon pour mes prises, je vais prendre les bonnes vieilles Xiaomi plug EU qui font le boulot à priori, elles sont en 10A et pas 16A mais c est quffisent dans la grande majorité des cas. Pour Tuya c est poubelle pour moi.

[KiwiHC16]

2.4.7.1.2   Direction Field
The direction field specifies whether values of the attribute are be reported, or whether reports of the attribute are to be received. 

If this value is set to 0x00, then the attribute data type field, the minimum reporting interval field, the maximum reporting interval field and the reportable change field are included in the payload, and the timeout period field is omitted. 

The record is sent to a cluster server (or client) to configure how it sends reports to a client (or server) of the same cluster.

 If this value is set to 0x01, then the timeout period field is included in the payload, and the attribute data type field, the minimum reporting interval field, the maximum reporting interval field and the reportable change field are omitted. The record is sent to a cluster client (or server) to configure how it should expect reports from a server (or client) of the same cluster. All other values of this field are reserved

Dans notre cas: Direction Field = 00, il faut min, max, valchange et pas timeout Si Direction Field = 01, seulement TimeOut

[KiwiHC16]

2.4.7.1.5   Minimum Reporting Interval Field
The minimum reporting interval field is 16-bits in length and shall contain the minimum interval, in seconds, between issuing reports of the specified attribute. If this value is set to 0x0000, then there is no minimum limit, unless one is imposed by the specification of the cluster using this reporting mechanism or by the applicable profile.

Min: 2 octets , en secondes Si 0000 pas de min.

[KiwiHC16]

2.4.7.1.6   Maximum Reporting Interval Field The maximum reporting interval field is 16-bits in length and shall contain the maximum interval, in seconds, between issuing reports of the specified attribute. If this value is set to 0xffff, then the device shall not issue reports for the specified attribute, and the configuration information for that attribute need not be maintained. (Note:- in an implementation using dynamic memory allocation, the memory space for that information may then be reclaimed). 

= Temps Max entre deux rapports

Max: 2 octets en secondes si 0xFFFF pas de rapport et l'équipement peut oublier la configuration.

[KiwiHC16]

2.4.7.1.7   Reportable Change Field The reportable change field shall contain the minimum change to the attribute that will result in a report being issued. This field is of variable length. For attributes with 'analog' data type (see Table 2.15) the field has the same data type as the attribute. The sign (if any) of the reportable change field is ignored. For attributes of 'discrete' data type (see Table 2.15) this field is omitted

Changement minimum sur la mesure qui provoque un rapport. La taille depend du type de parametre mais pas clair.