jjacques68

Hello tout le monde, on connait tous le graphique de charge du CPU du notre box : Je me pose la question suivante : Comment il sortent les % ?? Dans l'API "diagnostics" on ne trouve que : { "name": "cpu0", "user": "9243", "nice": "0", "system": "7611", "idle": "99314" }, Pas de % du coup, pour le calcul c'est quoi ?? (system) * 100 / idle c'est le seul truc qui se rapproche un peu des % affichées merci d'avance !!

je viens de vérifier les logs de la box internet, rien à signaler...

c'est tout bon, ça fonctionne bien avec la plage de déclenchement et flag ! merci @Lazer pour l'idée !!! Maintenant je vais continuer de surveiller ce freeze qui : est quotidien dure entre environ 3 minutes arrive le soir entre 20h45 et 21h30

bon, chose faite curieux de voir ce que ça donnera ce soir... Du coup j'ai mis 5 minutes de delta pour la plage, c'est beaucoup je trouve... ça veut dire aussi que le réveil du matin peut se mettre en route 5 minutes après l'heure programmée bon... vaut mieux ça que rien du tout ça m'était jamais arrivé encore...

c'est bon je suis dedans là !!! motivé motivé et puis plein le c... de travailler avec des variable de "type" heure (ex : "07:30"), je passe aux timestamp, beaucoup plus simple à exploiter...

bien vu ça !! mais il faut un flag pour dire que l'action a été traité, pour ne pas la refaire dans la même plage... EDIT : ou peut-être encore mieux : une queue liste d'action à faire... ben non !! ça changera rien au problème...

étrange oui... la durée du freeze, chez moi, est de 3 min. Qui correspond à la durée du reboot effectué par l'auto backup. Mais je confirme qu'elle ne reboote pas à ce moment !! (j'ai pas les log) ok, mais, si ça arrive quand une action doit être réalisée, ben cette action, on peut juste l'oublier !! dans le cas de la fermeture des volets le soir, ça crains !!! va falloir doubler le déclenchement des scénarios par sécurité séparé par x temps ? - nan mais là on y arrive plus !!

alors : ce soir, à nouveau un freeze de 3 minutes. mais bien plus tard que les précédents. A un moment où absolument rien devait se produire ! Donc on peut pas dire que ça vient de mes 2 QA cités plus haut... (ça m'arrange ) Mais alors que ce passe-t-il ? qqun à la possibilité de vérifier un éventuel freeze chez lui, à moment x de la journée ?

Hello tout le monde : un vieux sujet j'imagine ... étant gros consommateur de piles (on se demande pourquoi ), je me demande si on pourrait pas essayer de remplacer nos piles par des batteries rechargeables de ce style : Alors sur cette photo, ce serait pour remplacer 3 piles de type LR03. ça semble top ! un pack à recharger en usb !! Je trouve pas d'autres fabricant ??? ou modèle ?? ça aurait été génial si on pouvait avoir ça au format 2x ou 3x LR06/03 Il y aurait ce genre de chose : existe pour LR03 et LR06, pile 9V. Mais aucune idée de la compatibilité avec les devices, ainsi que de la qualité/durabilité... Dans mon cas, je pense aux module everspring et danfoss... J'ose pas parler des FGK / FGMS... Vous avez des avis ? des idées ? merci d'avance !

Promis je vous ferai un retour dès que le cas se présentera...

non, en tous cas j'ai pas eu les notifications comme quand elle reboote avec le backup auto. Ben y a rien qui m'arrête cette loop sauf si je vais manuellement mettre la QA (type binary) sur false. C'est de nouveau bien tordu mon histoire... J'ai mis du debug partout, j'ai testé à la mano, tout fonctionne, on verra ce soir en condition automatique... Mais franchement j'ai un doute...

ok !! I thought it Thanks for explains. I understand...

je me pose la question suivante, suite à des essais : (alors j'ai peut-être pas tout compris - en fait c'est certain ) est ce que c'est logique de mettre un pcall() dans ce cas : (j'ai ultra abrégé le code...) ce code est dans un QA dit "appelant"... il exécute une fonction nommée "myFunc" dans un QA dit "appelé" avec comme ID : myID function QuickApp:mainLoop() local status, err = true, "" status, err = pcall(function() fibaro.call(myID, "myFunc") end) if not status then self:error("Detail error : ", err) end setTimeout(function() self:mainLoop() end, self.timeLoop) end Je comprends pas trop l'intérêt de ce pcall() ici. Car quand je fais ce qu'il faut pour faire planter la fonction du QA appelée (donc myFunc()), l'erreur vient bien du QA appelé (myID) ! Dans le QA appelant, j'ai rien... donc status = true ?? Logiquement, je ne devrais pas avoir status = false et l'erreur qui remonte dans le QA appelant via la variable "err" ? La mainLoop continue de tourner... Merci pour vos lumières...

Alors voilà j'ai fini (avec webdev ) et j'ai exactement ce que je voulais voir !! Freeze complet de la box à 20:53:25 !! Aucun log qui remonte, aucun message d'erreurs nul part !! J'ai 2 QA qui doivent travailler à cette heure-là ! Dont un qui tourne en boucle... Donc ma recherche de bug est plutôt assez ciblé Sauf que comme dit, j'ai rien qui dit quoi que ce soit Est-il possible qu'un QA qui plante, fasse freezer la box, et qu'on ne le sache pas ? Et visiblement celui qui tourne en boucle ne s'est pas relancé tout seul !? - je croyais que les QA redémarrait tout seul !

Donc voilà, piles reçues, chargées, et mis en place dans ST815 d'everspring à ce jour. (habituellement je remplace les piles 2 / an - 3 x LR6) pas mal la qualité du produit, idem pour le cordon 4 en 1 pour charger les 4 piles en même temps... à suivre... Au premier soucis, ça dégage...

mouai... soit... ok... disons ça comme ça... Mais je suis d'accord, c'est pas le top...

SI... dans une baie informatique, sous l'escalier de la cave...

ça je l'ai déjà observé en effet. ben moi c'est au pire j'ai quelques modules en liaison directe Je vais retenter des reconstructions de route...

ça relance de vieux sujet on en avait déjà discuté, tu sais que j'ai toujours pas réussi à le faire !!! Je croyais que si, et bien non !!! J'ai un maillage que je trouve, perso, catastrophique !!! Après ça fonctionne... alors bon... Sans compter l'analyse faite avec le sniffer qui n'est pas en phase avec le maillage récupéré de l'API...

on verra ça, je vous dirais

c'est la version Zwave du module. Cela permet de tracer les anciens modules qui peuvent poser soucis. un module marqué comme "just link" veut dire que ce module est utilisé pour construire la route, entre le dernier module de la branche de l'arborescence dans laquelle il se trouve, et le contrôleur z-wave. "1 jump" et "2 or mode jump", c'est justement pour ce dernier module, cela nous informe du nombre de modules intermédiaires. exemple avec ta capture : ton module 55 apparaît en rouge car il a 4 module intermédiaire entre lui et le contrôleur. donc quand le contrôleur veut causer avec le module 55, il passe par ces 4 modules. Ces 4 modules sont donc juste des liens (pour le 55). c'est pas prévu, j'aime pas mémoriser les mots de passe...

Exacte, je me rappelle maintenant que tu le dis, je viens de retrouver le sujet

RAS pour le remplacement des batteries de l'onduleur... et la procédure en cas de coupure fonctionne toujours nickel , sauf 2 remarques : - un des ventilateur du witch POE fait un bruit de ouf au rallumage , donc je l'ai enlever pour le remplacer (c'était sûr ça, arrêté pendant 1 heure, le plastique a pas aimé ) - il faut vraiment que fibaro nous redonne la possibilité d'éteindre la HC3 par script !! J'ai du l'éteindre à la main !! vu que la fonction ne marche plus... PS : On fait quoi avec les anciennes batteries (4 x 6 v), à garder pour, un-jour-on-sait-jamais-des-fois-qu'il-y-ait-une-attaque-d'extraterrestres-covidé, ou déchetterie ?

mais tu as un messages d'erreur ou qqch ?

ben là comme ça... tu as la bonne IP, le bon user (l'adresse mail fonctionne aussi) et le bon mot de passe ?