jjacques68

concernant mon problème, j'ai identifié la cause précise de tout mon bordel...

Lors de l'analyse des log du refreshState, pour sauver ces log en base de données, j'avais un un filtre qui me permettait justement d'éviter la redondance des infos.

Pour une raison inconnu ce filtre ne fonctionnait plus après la version 5.152. (c'est comme si les log avait été typé différemment... bref)

Je l'ai modifié et tout est rentré dans l'ordre.

pour ceux que ça intéresse :

quand on fait appel à une méthode d'un QA depuis un autre QA, une ligne s'affiche dans les log : "onAction [..., ..., ...]"

1. alors avec le refreshState, je capte un log d'un QA quelconque.
2. J'envoi ce log dans un autre QA pour le mettre en base de données.
3. cette opération génère un nouveau log avec le onAction[...]
4. et je re-capte ce log (mais c'est le même en fait, il a le même contenu !!) que je renvoie vers le QA pour le mettre en base, qui me régénère un nouveau log onAction (toujours le même contenu) ... ... ... = loop sans fin
5. ça, plus les autres logs des autres QA, la box s'écroule en quelques secondes (la mainLoop d'analyse du refreshState tourne toutes les 50ms).

Mon filtre permet justement de ne pas traiter les log contenant le mot clé "onAction" (qui sont totalement inutile dans ce cas)

Et le problème est réglé.

suis deg car... ben avant ... ça marchait ... !!

Alors...

Ils ont ré intervenu une 3ème fois, avec les développeurs.

Le problème est réglé.

Un QA était à l'origine.

Ils ont désactivé le QA et c'est OK.

Sauf que c'est LE QA qu'il fallait pas désactivé   

Il analyse le refreshState (un GEA perso en gros) qui déclenche tout ce qu'il y a à déclencher ...

Donc je mène mon enquête...

Ce QA récupère AUSSI les logs de la box (debug, trace, warning, error) pour les envoyer en base de données.

Mais depuis une mise à jour précédente, ils ont changé qqch dans leur manière de traiter le debug car c'est ça qui me faisait freezer la box.

J'ai une redondance sans fin des infos, car quand je traite la première info de log du resfreshState, une nouvel ligne dans le debug se mettait en place (indépendant de ma volonté ??? je sais pas pourquoi ???)

en gros ça fini comme ça : (enfin ça fini jamais)

le chiffre est l'ID 48xxx est l'ID du log

[15.05.2024] [18:58:02] [DEBUG] [QA_759_RERESHSTATES V2]: 48095 onInit
[15.05.2024] [18:58:02] [DEBUG] [QA_759_RERESHSTATES V2]: 48096 48095 onInit
[15.05.2024] [18:58:02] [DEBUG] [QA_759_RERESHSTATES V2]: 48097 48096 48095 onInit
[15.05.2024] [18:58:02] [DEBUG] [QA_759_RERESHSTATES V2]: 48098 48097 48096 48095 onInit
[15.05.2024] [18:58:02] [DEBUG] [QA_759_RERESHSTATES V2]: 48099 48098 48097 48096 48095 onInit
[15.05.2024] [18:58:03] [DEBUG] [QA_759_RERESHSTATES V2]: 48101 48099 48098 48097 48096 48095 onInit
[15.05.2024] [18:58:03] [DEBUG] [QA_759_RERESHSTATES V2]: 48102 48101 48099 48098 48097 48096 48095 onInit
[15.05.2024] [18:58:03] [DEBUG] [QA_759_RERESHSTATES V2]: 48103 48102 48101 48099 48098 48097 48096 48095 onInit
[15.05.2024] [18:58:03] [DEBUG] [QA_759_RERESHSTATES V2]: 48104 48103 48102 48101 48099 48098 48097 48096 48095 onInit
[15.05.2024] [18:58:03] [DEBUG] [QA_759_RERESHSTATES V2]: 48105 48104 48103 48102 48101 48099 48098 48097 48096 48095 onInit
[15.05.2024] [18:58:03] [DEBUG] [QA_759_RERESHSTATES V2]: 48106 48105 48104 48103 48102 48101 48099 48098 48097 48096 48095 onInit
[15.05.2024] [18:58:03] [DEBUG] [QA_759_RERESHSTATES V2]: 48107 48106 48105 48104 48103 48102 48101 48099 48098 48097 48096 48095 onInit
[15.05.2024] [18:58:03] [DEBUG] [QA_759_RERESHSTATES V2]: 48108 48107 48106 48105 48104 48103 48102 48101 48099 48098 48097 48096 48095 onInit
[15.05.2024] [18:58:03] [DEBUG] [QA_759_RERESHSTATES V2]: 48109 48108 48107 48106 48105 48104 48103 48102 48101 48099 48098 48097 48096 48095 onInit
[15.05.2024] [18:58:03] [DEBUG] [QA_759_RERESHSTATES V2]: 48110 48109 48108 48107 48106 48105 48104 48103 48102 48101 48099 48098 48097 48096 48095 onInit
[15.05.2024] [18:58:03] [DEBUG] [QA_759_RERESHSTATES V2]: 48111 48110 48109 48108 48107 48106 48105 48104 48103 48102 48101 48099 48098 48097 48096 48095 onInit
...

et la je n'affiche rien du log, imaginez le message en plus !! 

Donc je comprends toujours pas ce qu'il se passe avec ces log,

ça marchait très bien avant !

Je continue à creuser,

c'est pas très compliqué pourtant, et je vois pas où ça peut foirer...

Mais je sens bien que pour archiver mes log, il va falloir le faire depuis les QA qui le nécessite et plus depuis le RefreshState...

En attendant je n'archive plus ces logs...

deuxième tentative du support sans succès.

Mon soucis va être remonté chez les développeurs... selon leur dernier message.

Donc 2 possibilités, où quelqu'un se penche sérieusement sur le problème ou il tombe dans les oubliettes...

A suivre...

moi problème toujours pas réglé, le support va essayer une deuxième fois de s'y mettre... il m'a contacté hier...

A suivre...

Le 24/04/2024 à 19:56, TitiXsi a dit :

Cette merdouille ... Il y a plusieurs version de Chipset sur ces HC3 ?

si y a un lien, ça va être marrant l'avenir...

par contre j'ai pensé...

c'est ok tant qu'on accède à l'interface web de la HC3, c'est à dire qu'il faut qu'elle démarre correctement !

s'il faut passer par la page recovery, le problème que je citais précédemment reste le même !!

Je viens de voir ça sur la doc de Fibaro : 

J'y étais pas du tout... 

Première intervention du support technique sur ma box cette aprem, sans succès.

J'ai du refaire un recovery.

Il va re essayer un autre jour... 

Suite à mes soucis de mise à jour de la box, je relance le sujet de vouloir restaurer une version backupée par notre système de backup auto.

On a avait parlé dans ce topic ici : 

sauf que là je constate que ça ne marche plus...

J'ai beau compressé le .bin .fbi en .7z, ou de bêtement modifier l'extension (on sait jamais), il refuse de prendre le fichier pour le restaurer !!

Avant il le prenait, j'avais un message d'erreur à la fin du process mais le recovery fonctionnait !!

ça craint ça !

ou alors je m'y prends mal ?

PS : pour le moment je m'en sors sans, car j'utilise le systeme A/B pour les restaurations, mais je sens bien qu'un moment ça va foirer...

j'ai posté sur le forum officiel, on verra.

J'ai testé le reset du Zigbee, ça n'a rien changé  

je me demande si ça vient pas du zigbee...

parce que la première minute y a pas de soucis. 

c'est après que ça part en vrille...

Et le zigbee ne démarre pas tout de suite justement...

oui demain je vais poster sur leur forum...

il rame à mourir leur forum ce soir !!

si j'ai un moment, je reset le zigbee et re-teste la mise à jour...

Je commence à m'inquiéter un peu...

c'est la 2ème mise à jour que j'essaye de faire sans succès...

La mise à jour se fait bien, mais après les CPU s'affolent à un point que plus rien ne réagit.

Même l'interface WEB devient inutilisable.

C'était la même chose avec la version précédente.

Et le recovery depuis l'IHM plante. Suis obligé de passer par les boutons  de la box...

Vais je devoir rester en 5.152.24 ???

Il y a 9 heures, Lazer a dit :

il faudrait identifier la commande dans ton onInit qui plante

déjà ça, le bon vieux tag : 

__TAG = string.format("QA_%s_%s",self.id, self.name)

Il y a 8 heures, henri-allauch a dit :

local TempoInit = tonumber (self:getVariable("V_TempoInit") ) or 0

lire une variable ne passait déjà pas...

comme tu as dit @henri-allauch, j'ai encapsulé les instructions dans un timeout...

Oui j'ai pas précisé, je parle de variables du QA.

Tous mes QA ont aussi du code dans le onInit(), tous fonctionnent à part 2 ??

Hier soir  j'ai  mis justement un timeout de 10 s dans un de ces 2.

Et ce matin ça a bien démarré...

Je faisais déjà ça avec les QA qui gère les socket TCP...

étrange...

C'est comme si au démarrage c'était mode panique 

Hello tout le monde ! j'espère que vous allez bien !!

J'ai une petite question...

Dans un QA, la fonction

function QuickApp:onInit()

s'exécute toujours bien au démarrage du QA ? ça n'a pas changé ?

et donc...

également au démarrage de la box ?

Je demande car je constate que pour certain QA, il se comporte exactement comme il le faut lors du reboot d'un QA, 

mais PAS au démarrage de la box.

Dans mon QA en question, les lignes de codes sont justes, ignorées !!

Aucune trace dans les log, aucun message d'erreur.

Je viens lire le contenu du variable et celle-ci n'est pas lue. 

Je répète, que ça arrive que au démarrage de la box... Si je redémarre le QA, il y a aucun problème.

Vous avez une idée ?

merci  d'avance pour vos retours...

Le 28/03/2024 à 22:33, Nico a dit :

Oui mais les 68 ça reste des faux alsaciens...

je m'absente quelques jours et voila c'est le bordel !!!   

mouai enfin quand même, entre la box et l'appli mobile, on fait un bon de 1 an en arrière là, si pas plus...

moi j'ai du revenir en arrière avec cette mise à jour !

la box rebootait toutes les 20 min !!

moi le me manque toujours des QA dans la nouvelle appli...

nan, chez moi pas la peine 

de mes souvenirs, tu ne dois pas activer le push.

Mais activer l'option "SEND DATA ON STATUS CHANGE" sur la page précédente, avec le port qui va bien.

comme ça dès que qqch chance dans l'ipx, il enverra tout le paquet à la HC3.

Et le QA s'occupe de faire le tri.

Dans cette version, je n'ai plus l'erreur "Zigbee Error", 20 min après le reboot de la box... bien :) !!

mise à jour faite.

RAS pour le moment...

à l’instant, TitiXsi a dit :

Et si tu laisses l'id d'origine ?

j'ai essayé... il est complètement inexistant dans la BDD !!