Lazer

Absolument

Ca m'a l'air sympa tout ça. Continue de nous faire rêver PS : c'est "baveux et mou" ( ) parce que tu inclus les images dans le message, et le forum réduit la résolution. Il faut les mettre préalablement dans la galerie pour que ça soit beau.

oui ce n'est pas le 183 mais l'un des modules Enfants du Plugin Netatmo qui pose souci. SI tu regardes bien le code de la boucle, on parcours tous les modules enfants

En effet, étrange. Et si tu testes manuellement le fibaro:getName(183) dans un autre VD, ça fait pareil ? Sinon essaye cette technique de contournement : local deviceName = fibaro:getName(id) or "???"

J'adore En résumé, connaissant le contexte : bonjour j'ai une HC2, et c'est pas normal, l'utilisation RAM est maitrisée :2: Il faudra s'y faire, les problèmes de RAM sont en passe d'être résolus. Ce qui est étonnant c'est que tu sois encore en 4.080 alors que les améliorations ne sont qu'en 4.082. M'enfin tant mieux pour toi EDIT : 48h de uptime, RAM ULTRA STABLE en 4.082, un truc de fou, heureusement que j'ai mon graph pour y croire

Parce que ton FGMS doit maintenir son état pendant 30s. Voir la doc, je n'ai plus en tête. Ensuite dans ta scène, il faut d'abord faire un getvalue() et agir en fonction.

Est-ce que tu peux activer la variable debug=yes dans le bouton Devices ? Ensuite tu verras plein de choses, dont le device ID qui fait planter le getName. Ensuite regarde le JSON (/api/devices/ID) du module en question. On dirait qu'il n'a pas de nom, ou un nom invalide.

1/ Justement !!!! On sait que la main loop merde depuis toujours (c'était le cas en v1, en v3, et donc en v4), et là tu me dis que tu as une boucle qui interroge un périphérique IP (Eco-devices, IPX, etc... bref peu importe l'appareil). Donc tu es en plein dans le cas où tu sais pertinemment que ça va planter. STP ne vient pas te plaindre après.... Perso le script Eco-Devices, trouvé sur un blog, c'est le premier script LUA que j'ai mis en oeuvre sur ma HC2 il y a 2 ans et demi. Ca n'a pas loupé, 10 jours après il était planté. J'ai donc cherché, et compris que la main loop était amenée à planter systématiquement dans ce cas de figure précis (= 1 requête http dans la main loop). Donc il n'en faut pas plus pour trouver une autre solution. Tu écris une scène qui clique sur un bouton du VD et le tour est joué. Mon meilleur exemple : Domocharts. Terminé on n'en parle plus, on arrête de se plaindre, on passe à autre chose et on avance. Après je suis allé plus loin, en m'inspirant des techniques des Main Loops de Krikroff. Tu prends ses VD Sonos ou Freebox par exemple. C'est la recette que j'ai appliqué à mon VD Surveillance Station, il effectue plusieurs requêtes HTTP par minute, et il est ultra stable. Pourquoi ? Tu savoir que la main loop, comme son nom l'indique, est une boucle infinie. Dons en fait, ton code est exécuté en boucle, sans cesse. Fibaro a juste introduit une sécurité, un Sleep de 3s. Donc si tu déclares une variable, à chaque passage dans la boucle, tu la redéclare, Si en plus ta variable que tu redéclare à chaque passage est le contenu d'une requête IP, ça alloue bcp de RAM. Donc ta mémoire augmente vite, le garbage collector du LUA n'a pas le temps de faire le ménage, donc ta mémoire utilisée devient trop grosse et ta main loop plante (par sécurité, avant de planter tout le système.... l'isolation des processus des VD a toujours bien fonctionné sur la HC2). La technique de Krikroff justement, c'est de déclarer la variable en global, et à chaque passage dans la boucle, on ne la redéclare pas. Si maintenant ça variable est un objet LUA qui comprend des variables et des fonctions, tu fais tenir tout ton code dans une seule variable, qui ne sera pas réalloué à chaque passage => Gain de performance et de mémoire. Terriblement efficace, plus aucun plantage !!!! Et oui la programmation c'est pas simple..... c'est plus complexe que de prendre les 3 premières lignes de LUA trouvées sur le forum ou un blog tiers. Tu comprendras que pour les devs Fibaro, c'est la même chose en 10^10 fois pire. Imagine un peu Microsoft avec Windows qui a été critiqué pendant des 10zaines d'années pour les mêmes raisons. Ils sont finalement parvenu à livrer un OS ultra stable, qui résiste à tous les programmes mal codés par les dévs du dimanche que nous sommes. En attendant, quand on développe, qu'on soit devant ou derrière le système, il faut s'appliquer et ne pas systématiquement rejeter la faute sur les autres, surtout quand le bug est connu de longue date (là je parle de la main loop) 2/ C'est quoi un timer ? Une scène en mode bloc ? Tu as déjà converti une scène en mode bloc en LUA pour voir à quoi ça ressemble ? C'est de la merde. Donc une fois que tu sais ça, tu abandonnes les scènes en mode bloc, et tu codes un truc en LUA propre, ou si tu ne sais pas / n'a pas le courage de faire, tu utilises GEA. 3/ Tu as très certainement un module sur ton réseau Z-Wave qui fout la grouille, car il a été mal inclu. Toutes les fois où j'ai vu ce problème sur le forum, et que l'utilisateur a fini par le résoudre tout seul, ça a été simple : isoler tous les modules un par un, jusqu'à isoler le coupable, puis l'exclure, le reseter, et l'inclure proprement. Visiblement certains modules sont des candidats idéals : Aeon Labs, Fibaro RGBW, Swid, etc. Justement tu devrais commencer par exclure tes Swid pour voir, c'est un bon début. En ce qui concerne le Motion Sensor, 99% des problèmes remontés sur le forum sont un problème d'interface chaise/clavier => La doc est ultra complète, il faut la lire plusieurs fois pour comprendre les interactions entre les différents paramètres. Si ton capteur ne te voit pas, il y a peut être un souci de blind time. Ca tu le constateras facilement avec la diode du capteur. Il y a déjà eu de nombreuses discussions à ce sujet sur le topic dédié, que tu peux aussi relire si tu en as le courage, mais tu devrais prendre le temps pour arriver à tes fins. 4/ La limitation d'instance est une sécurité, justement à cause des scènes mal codées par les utilisateurs, et on en a vu plusieurs exemples sur le forum. Pour le coup, je trouve que Fibaro a eu parfaitement raison de limiter le nombre d'instances, et la valeur par défaut = 2 est juste parfaite, sauf pour GEA qui peut être amené à traiter un plus grand nombres d'actions simultanément du fait que cette seule scène gère tous les modules de la maison, par définition. 5/ C'est pour cela que je n'ai domotisé aucune ouverture, trop de risque de sécurité, et pas à cause de Fibaro, un bug ou une faille informatique est si vite arrivé, quelque soit la box. J'ai déjà réfléchi à comment je fais domotiser mon garage, ça va être assez sécurisé, je ferai un topic sur le sujet je pense. Des trucs ultras simples : des modules que nous avons tous, avec des scénarios ultra basiques d'ouverture/fermeture de volets et terminé. Pas de scripts LUA écrits à la va-vite, qui planteront inévitablement (cf bla-bla du dessus). Bref, de la domotique pour Mme Michu, ce qui doit bien représenter 99,99% du public. J'aime bien la comparaison avec le monde de l'informatique. Qui a fait du DOS ? Nous, parce qu'on est des powers users en avance sur notre temps (technologiquement parlant). L'informatique ne s'est démocratisée dans le foyer de Mme Michu qu'avec l'arrivée d'Apple, parce que l'interface est ultra simple, et ultra limitée aussi (l’utilisateur ne fait que ce que le constructeur a décidé). En domotique on appelle ça Somfy. Et le revendeur a l'expérience des modules qui posent problèmes, donc il évitera de vendre à ses clients les modules à mauvaise réputation (toujours les mêmes : Aeotec, Swid, Qubino, etc). En gros, en modules, Fibaro ce sont les meilleurs. Aucun risque avec ça. Pour info le vendeur/installateur auquel je pense n'est pas PITP2, et il n'installe que des HC2 depuis 3 ans car c'est la seule box (dans le cas de figure de la domotique de Mme Michu) avec laquelle il n'a aucun problème. Oui vous avez bien lu, et il a fallu que je lui fasse répéter 2 fois pour le croire. Donc encore une fois, je maintiens qu'outre les bugs du code de Fibaro, nos instabilités sont dues à nos scripts LUA et nos modules mal inclus et/ou firmware buggé. EDIT : en fait j'ai fait un long discours sur le LUA, mais ce qu'il faut retenir c'est : ce n'est pas les scripts complexes qui font planter la box, mais ce sont les scripts trop simples !!!! Oui c'est paradoxal quand on ne sait pas programmer, mais quand on creuse un peu le sujet, on s'aperçoit que les 3/4 d'un code source sont de la gestion d'erreurs et d'exceptions. Ce qui permet de rendre le script plus stable.

Avant le soft reconfigure, tu peux juste commencer par un truc ultra simple => re-sauvegarder les paramètres, ce qui va avoir pour effet de contacter le module (penser à réveiller le module si il est sur pile). J'ai constaté que certains attributs du JSON se mettaient à jour à ce moment là . Je n'ai pas poussé plus loin la comparaison des JSON avant/après pour savoir si un soft-reconfigure est nécessaire. Dans la pratique, je n'ai fait des soft-reconfigure que pour des modules qui me posaient problème (dont une fois un soft reconfigure qui avait fini en 503, puis 2 reboot avant qu'il ne se termine.... donc méfiance). Celle-là j'ai hésité à la faire hier soir quand j'ai partagé mon uptime de 28 jours Merci d'avoir relevé

J'ai 60 modules Z-Wave, plusieurs scènes et VD, et des fake modules EnOcean. Le tout depuis la v3, il y a 2 ans et demi, sans avoir jamais réinstallé ma box. Au final, elle est àpeu près stable, en tout cas plus stable que beaucoup de retours d'expérience que je peux lire ici. Je pense qu'il y a du vrai dans ce que chacun pense, les bugs viennent du code Fibaro, de la DB, mais surtout des scripts lua de chacun. On sait que le code de Fibaro de check rien, donc si on fait une erreur de script, ID de module, etc, alors ça débouche sur un 503. À ceux qui ont des 503 àrépétition, commencez par vérifier vos scripts ça ira beaucoup mieux. C'est pas normal car le code de Fibaro devrait gérer ces cas d'erreurs, mais malheureusement ce n'est pas le cas donc il faut s'adapter. Pour les cas extrêmes qu'on ne maîtrise pas, il y a le watchdog. J'ajoute que j'ai eu des retours d'expérience de revendeur/installateur qui ont déployé des 10zaines et des 10zaines de HC2 , qu'ils mettent jour àdistance depuis des années pour le compte de leur clients, et c'est rock stable, pas un plantage. Pourquoi ? Parce qu'il n'y a pas de script LUA tordu qui font n'importe quoi. Alors oui, nous on n'achète pas une HC2 pour allumer ses lumières avec son smartphone, mais ça suffit àbeaucoup de clients. Mais surtout, ça démontre que nos script LUA mal codés sont la cause principale des plantages (avec la non gestion des erreurs par le code de Fibaro, mais làdessus on voit qu'ils progressent.....tout doucement) En ce qui concerne le JSON des modules, oui Fibaro àfait évoluer les propriétés dans la DB, mais n'a pas forcé une mise àjour des modules existants. Je ne sais pas la raison, mais il vous suffit de refaire une configuration du module pour qu'il prenne toutes les nouvelles propriétés. Et hop vous avez une DB àpeu près propre, sans avoir besoin de repartir à0.

je ne sais pas, j'ai toujours 2 instances sur mes scènes, sauf GEA qui est au maxi à10

@jojo tu m'as fait peur, je viens de faire un test de backup manuel et c'est OK. Tu es sur que tu es bien passé en 4.082b et que tu n'es pas sur une demi-beta ?

Ah oui vu comme ça c'est pas idiot. 3 minutes de gagnées au reboot, c'est pas mal. Et puis c'est surtout le backup pré-update qui est utile, celui là ils l'ont laissé. Par contre quand je vois tous ces changements, faudrait vraiment qu'il nous fasse des changelogs complets la prochaine fois, car on passe notre temps à essayer de découvrir les nouveautés

Idem, sur le coup l'autre soir j'ai pensé que ma clé USB avait cramé pendant la mise à jour, puis j'ai oublié d'aller vérifier ça. Bon je ne suis pas le seul alors, ça doit être "normal". C'est toujours le même problèmes avec leurs devs. Ils codent des fonctions au kilomètre, sans vérifier les codes retours des fonctions appelées, sans libérer la mémoire allouée, ou dans le cas présent, ne vérifient pas la validé de l'ID du module concerné. Donc fatalement ça plante. Et comme leur code doit être truffé de ce genre de bugs, ça fait 1 an qu'ils passent leur temps à débugger, au lieu d'avancer (parce qu'ils ne me feront pas croire que griser les scènes inactives ou indiquer le Last Breach sous les modules ça leur a demandé 1 an de travail.)

C'est quand même toujours aussi hallucinant ces différences de comportement d'une box àune autre ! Jojo j'admire ton calme face àtous ces 503

Et vous savez quoi ? Les fuites mémoires ont disparu :13: :13: :13: :13: :13: :13: :13: :13: :13: :13: :13: :13: :13: :13:

A mon avis, ton GEA n'y étais pour rien et fonctionnait très bien. Ce que tu constates, c'est que plus aucun ordre Z-Wave ne passait, donc je vote pour un plantage du moteur Z-wave. C'est rare, mais ça arrive parfois. De mémoire c'était plus fréquent en 4.070 (ou dans ces environs là ). J'ai fait 28 jours en 4.080, avant que les plantages ne commencent à cause de la mémoire pleine. Comme la 4.082 venait de sortir, j'ai fait la mise à jour puis reboot.

En fait, je suis à 300s, soit 5 minutes, et ce délai de réveil est confortable pour la prise en compte de la nouvelle consigne de température. Pour info voici la courbe d'utilisation de la batterie de mon SRT321. De décembre à Novembre, ça fait précisément 11 mois de durée de vie des piles, c'est très correct. Par contre je ne me souviens plus si j'étais à 300s ou 900s à l'époque, car j'étais sur piles. Mon module est maintenant alimenté par des fausses piles, donc plus de problème

Le coup classique: les plantages de scène et autres VD.Installe mon watchdog pour redémarrer automatiquement les scènes plantées.

Malheureux Je n'utilise plus de scène en mode bloc depuis longtemps Le SRT 321 fonctionne parfaitement avec le panneau de chauffage pour ma part. De mémoire pour qu'une scène en mode bloc fonctionne avec des conditions de temps, il faut bien cocher les cases "start with home center" et "scène active" Mais quoi qu'il en soit, c'est un module à pile. Donc il faut attendre au maximum le temps du réveil pour qu'il prenne en compte la nouvelle consigne.

La différence entre le 321 et le 323, c'est le relai intégré dans le 323. J'ai le même bug sur le SRT321 depuis les premières v4, impossible de changer la valeur de réveil Pour le module du milieu, je ne sais pas.

Presque 25h sans planter : root@fghc2:~# uptime 22:30:33 up 1 day, 53 min, 1 user, load average: 0.01, 0.01, 0.00 Admirez la charge CPU entre 0 et 0.01 Y'a que les fuites mémoires qui sont toujours présentes pour ma part

Oui des nouveautés sympa dans l'interface : barre de titre fixe, et scènes désactivées grisées, c'est chouette je trouve

Si la clé USB est aussi HS, on ne cherchera plus plus loin => SAV revendeur.

Bon j'ai mon anémomètre..... posé dans le salon ! Très utile Je vais aller acheter un mat pour antenne parabollique et le fixer àl'arrière du garage je pense, làoù j'ai déjàmis le pluviomètre. Par contre, on en est où avec ce plugin ? Il ne supporte toujours pas l'anémomètre ? Vous utiliser un VD (lequel) pour remonter les infos ?