Lazer

Ca ne changera rien ça, ce ne sont pas les 2 / 3 variables qu'on alloue dans un script LUA qui prennent de l'espace en RAM. D'autant plus que le garbage collector du langage LUA est censé faire son job. Je rappelle que nos scripts ne sont pas exécutés tels quels. Dans une main loop de VD, Fibaro encapsule notre script dans un boucle infinie while true do, avec un sleep(3000) L'ensemble est passé à l'interpréteur LUA, et encapsulé dans du code à la sauce Fibaro pour s'exécuter sur Linux, et permettre la communication entre les différents process. C'est le "code à la sauce Fibaro" qui pose problème. C'est à peu près la même chose pour une scène. En V3, les Scène n'étaient pas exécutées dans des processus indépendants, mais dans le process principal (HCServer). Déjà ça fait une grosse différence, ils ont tout réécris.

Non sur mes 2 box, la RAM met plus de temps àmonter, que ce soit en 4.056 ou 4.057beta ou 4.058beta Je maintient que c'est clairement des fuites mémoires qui font que le RAM utilisé augmente sans-cesse, et qui fait que certains process (VD, Scène, ou HCServer) finissent par planter. D'ailleurs je pense qu'ils ne plantent pas car il n'y a plus assez de RAM, sinon on aurait des messages du Kernel Linux dans les logs, et ce n'est pas le cas. Ils plantent certainement car ils font des opérations illégales, comme accéder àdes zones de mémoires non allouées. En corrélation avec les problèmes de fuite mémoire, je ne serai pas surpris qu'ils allouent et désallouent la mémoire au petit bonheur la chance....

C'est pas une information importante, mais pour info voici les occupations RAM juste après un recovery, avec une configuration vierge. Il n'y a pas vraiment de différence significative : v4.056 "Stable" : v4.058 Beta :

A la demande de Jojo, j'ai modifié le premier post avec la version 1.1 du script afin d'ajouter un paramètre restart=true|false afin de redémarrer le VD/Scène concerné, ou seulement envoyer une notification signalant qu'il faut le redémarrer manuellement. Plus quelques modifications mineures.

il est chouette le design, au moins si ça ne marche pas tu sais où tu peux te ... Blague à part, j'aimais bien le concept de radio réveil de la première version.... ça manque sur ma table de chevet la possibilité de piloter simplement tout le domicile.

Nan la v5 c'est pour le CES en janvier [emoji14]

Ça me paraît pas mal

D'après ce que j'ai constaté : - quand la RAM est pleine (>80% environ) => plantage du process principal de la HC2, donc Erreur 503, interface Web indisponible, on ne peut plus rien faire àpart rebooter physiquement la box - tout le reste du temps => plantage aléatoire de certains process (scènes ou modules virtuels) sans aucun message d'erreur apparent dans la fenêtre de debug car il s'agit d'un core-dump au niveau de l'OS Linux. On ne peut pas les prévenir, et on peut les redémarrer en faisant une sauvegarde du VD/Scène planté => mon watchdog est làpour ça.

Les fuites mémoires datent de la v4, et ça ne fait qu'empirer àmesure qu'ils ajoutent des nouvelles fonctionnalités. A priori on n'avait pas ces soucis en v3.

Nico je pense que c'est aussi ma RAM qui a du dépasser les 80 % quand j'ai eu mon erreur 503 il y a 15 jours. Par contre j'insiste, on peut faire autant de requêtes http qu'on veut. Dans un problème de fuite mémoire, c'est évident que plus on fait travailler le système, plus on accélère la venue des problèmes. Rien ne dit que ça soit spécifiquement les requêtes http qui fuient, ça peut venir de n'importe où. C'est àFibaro de régler leurs problèmes de fuite mémoire. On a acheté une box puissante, c'est pour pouvoir l'exploiter, et ne pas se brider.

je t'avoue que je ne sais répondre àaucune de ta série de question..... je n'ai jamais eu ces problèmes, je n'ai pas eu àcreuser le fonctionnement interne de la chose.

Si le datastore est corrompu, je ne sais pas comment le réparer.... Donc si c'est le cas, les VM sont perdues Par contre pour Xpenology ce n'est pas grave. Tu peux repartir sur un nouveau Xpenoboot, qui devrait retrouver toutes les données de ton disque.

Certes, mais après c'est le vieux débat qui revient : tu as installé une beta, donc il y a des bugs potentiels (et avérés). Je suis toujours sur la dernière version stable du mois d'août. C'est loin d'être parfait puisque j'ai des plantages de scènes/VD inexpliqués et une fois erreur 503, mais au moins le reste fonctionne (panneau de chauffage, trigger, etc). Oui la bière ça sera pour janvier euh attends, pourquoi au singulier [emoji14]

Moi aussi Je n'en n'ai pas encore fait le tour (et j'aimerais bien que Fibaro m'y aide un peu.....) Malgré ses problèmes, elle reste plus stable que des solutions concurrentes, et plus performante. C'est juste que pour 600€ et avec un marketing de ouf, on se permet d'être plus exigeant. Fibaro n'a pas les moyens de ses ambitions. Les utilisateurs de Jeedom pardonnent plus facilement ses lacunes actuelles, d'autant plus que c'est une solution qui évolue plus vite.

Ouais bah justement la Netatmo c'est une grosse verrue sur mon installation. Depuis que l'api météo de Yahoo déconne, je n'ai plus que la Netatmo pour remonter la température extérieure.... Pour combien de temps encore ? Je l'ai surtout acheté parce qu'elle m'a coûté 60€, j'estime qu'elle ne vaut pas son prix de vente. M'enfin la mode est au jetable, aujourd'hui tout le monde trouve normal d'acheter quelque chose qui sera remplacé très rapidement..... Y'a quelque chose qui me choque moi..... Le cloud c'est une magnifique opportunité pour les fournisseurs de produits d'associer du service et donc de contrôler légalement l'obsolescence programmée. Même dans le monde pro, certaines entreprises qui étaient parmi les premières àdématérialiser leur SI dans le cloud, sont en train de faire marche arrière.... Comme quoi, le cloud n'est pas la réponse àtous les problèmes, et il y a un marché pour les deux. Quant àla domotique, les offres des grands constructeurs c'est pour le grand public, qui ne connaît rien (et ne veut rien) connaître àla technique. Ce n'est pas du tout la même cible que les box domotique que nous connaissons. Avec nos box (quelque soit la marque) nous ferons toujours 10 fois plus que ce que fait la domotique àla Nest & co. C'est pas toi qui dira le contraire puisque tu assembles encore tes PC àla main.

Dans les propriétés du module, il y a une case àcocher pour l'activer/désactiver. Ce n'est pas possible de modifier les id.

Mprinfo Google ou Microsoft ou encore un autre, pour avoir une solution Cloud ultra limitée (cf Works with Nest), non merci très peu pour moi. Faudrait vraiment que les gars de eedomus se réveillent et comprennent qu'ils ont raté trop de clients avec leur box dépendante du cloud, sans ça ils auraient pu faire un malheur.

Ca devient ridicule cette histoire de http :angry: On a une box surpuissante, avec du LUA, justement pour pouvoir s'ouvrir au monde extérieur (les objets connectés notamment), et ne pas être limité aux périphériques Z-Wave nativement supportés. Au contraire, j'en ai de plus en plus des requêtes http, c'est justement ce qui fait l'intérêt de la HC2.

Ah mon avis, il n'y a aucun intérêt àsurveiller les scènes en déclenchement instantané àbase de trigger. Déjàpar nature, le trigger est aléatoire et n'intervient pas àintervalle régulier. Ensuite, une scène déclenchée par trigger àune durée de vie très courte, elle effectue sa tâche puis meurt. Donc si il y a un bug, c'est une erreur de logique de programmation, et cela plantera àtous les coups, et doit donc être corrigé immédiatement par le développeur. Le watchdog n'est pas un debugguer.

Pas certain que ce watchdog te permette de détecter des signes avant coureur..... ou alors si tu trouve une piste, faudra partager ! Tu peux utiliser le script de Jojo à faire tourner sur une machine externe type Synology afin de détecter le plantage de la HC2..... et qui envoie un email, car impossible de redémarrer la HC2 sans intervenir directement dessus.

Merci. Je n'avais pas encore pris le temps, mais je viens maintenant de mettre mon icône au début du topic. Pour toutes les scènes, je préfère inclure l'image dans le clap de cinéma, afin de bien différencier dans l'interface web les scènes (sur lesquelles ont n'est pas censé agir) des VD (sur lesquels on peut agir).

oui c'est faisable..... déjàce que tu peux faire, c'est activer le mode debug = true qui te permettra de visualiser un peu mieux ce qui se passe. Et dans ta scène/VD àsurveiller, tu crées volontairement l'erreur.

Jojo, je vais détailler cette histoire d'ERROR dans le 2nd post (d'ailleurs j'ai commencé à y ajouter quelques infos). Tu peux laisser type="ERROR" pour les scènes, mais cela sera sans effet tant que Fibaro ne ré-implémentera pas cette fonctionnalité. Pour le moment, ERROR n'existe plus que pour les Main Loop de VD. Donc, si tu as une Scène dont tu connais précisément le message d'erreur qui apparait aléatoirement, tu peux le mettre dans le paramètre no_match.text. Je sais que c'est le cas de Gazous pour l'une de ses scènes dans le topic "Catcher une erreur LUA" d'où est parti cette idée de watchdog. Et on peut dire que ce changement de comportement tombe au bon moment (enfin, je m'en serais bien passé.... mais il faut faire avec.... Fibaro, développeurs, régression, bug, tout ça quoi....) car j'étais justement en train de développer ce watchdog quand j'ai passé ma box de développement de la v4.057 à v4.058, tandis que ma box de prod est toujours en v4.056. Donc j'ai bien vu la différence. Ceci dit, pour une scène, je considère que le plus fiable est d'utiliser le paramètre count=1, car vous avez certainement 1 instance lancée en autostart avec une boucle infinie qui devrait tourner non-stop (cas connu de GEA). Remarquez que dans mon exemple, on a une double protection pour GEA, car on essaye également de matcher le text "Durée des traitements" qui apparait normalement toutes les 10 minutes.

C'est par là: [Tuto HC2] Watchdog Pour Scènes Et Modules Virtuels

De façon générale, pour surveiller efficacement les main loop de modules virtuels, il faut que chaque main loop affche un message prédéfini à intervalle régulier. En effet, pour une main loop on ne peut pas faire appel à la fonction countScene(), et il n'est donc pas possible de détecter le cas où le module virtuel fait un core-dump au niveau de l'OS Linux.... puisque lorsque cela se produit, aucun message d'erreur spécifique n'est affiché dans la zone de débug de la main loop. Dans le cas particulier du module virtuel Sonos Player de Krikroff, il faut activer l'option Tk.isTraceEnabled = true dans le code de la main loop (qui se trouve vers la fin) Pour les prochains modules virtuels qui seront développés, je suggère d'ajouter ce type de message récurrent si vous souhaitez pouvoir surveiller efficacement les main loop. Quelques captures d'écran : Autostart de la scène, puis 15 minutes plus tard, les Check s'enchainent toutes les minutes : Lancement manuel d'une seule vérification immédiate dans une nouvelle instance de la scène (pour cela, autoriser au minimum 2 instances pour cette scène, puis cliquer sur le bouton Démarrer) : Exemple d'une scène (GEA, ID n°14) dont l'instance qui s’exécute en boucle infinie a planté. Il y a 0 instances, donc redémarrage de GEA :