Lazer

voilàpourquoi elements est un tableau. Il que que tu parcours le tableau elements avec un boucle for, afin de détecter tous les boutons de la même ligne (4 maxi)

Je ne sais pas ce que utilises comme navigateur, mais normalement les numéros de lignes ne sont pas copiés.

elements est un tableau, qui ne semble comporter qu'un seul élément. Essaye comme ceci : fibaro:debug(v2.elements[1].name)

On sait déjà grâce à mprinfo que les nouvelles HC2 sont fournies de base en v4, avec une clé USB Recovery contenant une v4. Je n'en suis pas certain, mais je crois que ces nouvelles images v4 intègrent une version un peu plus récente de Debian (c'est toujours une vieille v6, mais certains paquets ont l'air plus récent), et surtout le démon NTP est installé et configuré (donc permet de ne plus avoir les problèmes de synchronisation horaire qu'on a pu connaitre dans le passé). Donc si tu peux, il faudrait que tu mettes à jour manuellement ta clé Recovery pour intégrer cette nouvelle image v4, puis faire un recovery en v4, puis le dernier update, et ensuite commencer tes inclusions.

Clairement oui c'est l'occasion ou jamais de refaire une config propre de la HC2.

Pour un VD qui n'a rien dans le log, impossible de savoir. Pour une Scene, on n'a pas le souci car il suffit de faire un countScene. Une scène qui est censée avoir une instance en boucle infinie (car typique de GEA) aura forcément un countScene >= 1. Sinon, c'est qu'il a "core-dumpé", donc on save et il repart. Si un VD core-dumpe, comme le Sonos, les messages sont toujours présents dans son débug. Donc il suffit de chercher la dernière occurrence d'un message connu pour déterminer si son timestamp dépasse un certain intervalle, donc que le VD a potentiellement core-dumpé. Mon watchdog est presque prêt, avec pas mal d'options de personnalisations pour détecter les différents types de plantages.

Le scan serait une boucle facile à faire (grâce à la lecture du device via l'API), mais ça oblige à mettre ces quelques lignes de LUA dans chaque bouton, chaque main loop, et chaque scène qui va cliquer sur le boutons grâce à leur ID.... donc un peu lourd. Je suis d'accord, ça serait bien que Fibaro fasse évoluer cette fonction. Est-ce que ça leur a déjà été soumis ?

Normal, une restauration ne restaure que ta configuration.C'est le recovery qui permet de revenir àune version de logiciel inférieur.

Arf j'ai loupé ça désolé. (Ou alors je l'ai vu mais oublié.....)

Quoi, je m'absente un moment, et je retrouve Shad en v4 ? (enfin, qui essaye). Rien ne va plus

179€ + 13,99€ de frais de port avec seulement 2 Go, ce qui permet d'ajouter plus facilement de grosses barrettes de 8Go : http://www.minipriceexpress.com/informatica/servidores/servidor-hp-proliant-microserver-gen8-g1610t-1p-2-gb-u-b120i-nhp-sata-outlet/120593

Pourquoi tu dis ça ? GEA est l'exemple même de scène bien codé, qui va différencier l'autostart et les triggers, comme Steven a déjà pris le temps de l'expliquer à plusieurs reprises, et que je l'ai moi même rappelé page précédente pour expliqué la nécessiter d'augmenter la limitation d'instances sur GEA. En revanche, je pense que toi tu confonds un peu le countscene, l'autostart, les triggers, déclenchement manuel et la nouvelle limite à 10 instances de cette v4.058b. Si Fibaro a implémenté cette nouvelles fonctionnalité, à mon avis c'est pour 2 raisons : - je suppose qu'ils ont dépanné des tonnes de HC2 plantées ou trop lentes, car surchargées de scène "codées avec les pieds", qu'on n'a pas forcément vu sur le forum, sinon ça fait longtemps qu'on aurait dépannée ces pauvres utilisateurs qui nous auraient montré leur code. Et c'est tout bête : imagine une scène écrite par un utilisateur ne maitrisant pas les notions d'autostart/triggers, il suffit qu'il rentre la scène dans une boucle infinie à chaque trigger. Au bout de 100 triggers, tu as 100 boucles infinies qui tournent, je te laisse imaginer la tronche de la box.... - ça représente beaucoup moins de travail pour eux de brider les scripts des utilisateurs que de se remettre en cause et débugger leur propre logiciel. Ce dernier point m'amène à dire que cette nouvelle version ne corrige absolument pas les plantages (core dump) inexpliqués de scènes et VD, et ceci sans avoir d'erreur LUA, d'appels HTTP, ni de RAM surchargée. Faut bien comprendre que nos scripts LUA sont interprétés et exécutés par le moteur LUA standard, lequel est à son tour intégré dans du code à la sauce FIbaro. Et je maintiens que tous les bugs se situent dans le code écrit par Fibaro. Je ne suis pas développeur, je ne sais pas utiliser les outils de debugging sous Linux, et surtout je n'ai pas accès au code source, donc je serait bien incapable d'identifier et corriger les bugs. Mais pourtant c'est bien là qu'ils se situent, cela ne peut pas être autrement. De plus, vous remarquerez qu'en v3 on n'avait pas ces problèmes de RAM qui grossis sans cesse et de scènes/VD qui plantent sans raison apparente. Tient un exemple tout con : il y a quelques semaines, sur un autre topic, j'avais donné le nombre de threads en exécution simultanées du process principal (celui là même qui plante et cause l'erreur 503) => Et bah on était à plusieurs centaines. C'est complètement délirant, et n'importe quel développeur sait que quand on crée un thread, on le tue dès qu'on n'en n'a plus besoin. C'est pareil pour la mémoire, quand on alloue de la RAM, il faut ensuite la libérer. Sinon c'est le phénomène bien connu des fuites mémoires (qu'on rencontre surement sur la HC2 au vu de l'augmentation perpétuelle de la RAM). Bref, au risque de paraitre lourd, j'insiste : les développeurs feraient mieux de se pencher sérieusement sur leurs propres problèmes. Les dirigeants de FIbaro ne vont il pas sur les forums et plus généralement les blogs ? Ne voient ils pas que leur box n'a plus la cote ? Il serait temps de se réveiller..... au lieu de se regarder le nombril. C'est pourtant dommage, la HC2 est de loin la box qui a le plus de potentiel, une communauté d'utilisateurs dynamique avec de nombreux scripts partagés, perso j'y crois encore, et je n'ai pas envie de tout refaire sur une offre concurrente open source française....

Euh non, ça ne change rien ça. Le countscene peut te servir àprendre des décisions en fonction du nombre d'instances de la scène qui tournent déjàou pas. Cette nouvelle fonction est juste une limite qui permet de limiter les lancements abusifs de multiples instances de scènes, qui ont tendance àaugmenter la consommation de ressources et donc le plantage de la HC2. Pour une scène correctement développée (par exemple GEA), il n'y a pas de raison que ça change quoi que ce soit. Pour ce cas spécifique, il faut juste penser àaugmenter le nombre d'instances autorisées au lieu de 1 comme expliqué précédemment (1 autostart permanent, et 1 trigger minimum, ce dernier ayant une durée de vie très courte).

ouais mais pour ça faut qu'ils apprennent l'anglais, et pendant ce temps làils ne pourront pas développer

oui par scène visiblement. Plus que largement suffisant. finalement je trouve cette nouveauté pas mal. ceci dit, ils feraient bien d'optimiser leur code quand même.....

AH mais en fait c'est très bien fait la nouvelle fonctionnalité de limitation du nombre de scène. Dans l'onglet Général de chaque scène, il y a une liste déroulante "Max. running instances:" avec la valeur par défaut = 1 Il suffit de penser à paramétrer la valeur désirée entre 1 et 10, surtout pour GEA, il faudra au minimum 2. Car pour GEA, 1 instance en autostart (boucle infinie), et 1 instance temporaire par déclenchement instantané. Si plusieurs déclenchements instantanés simultanés, il faut augmenter le nombre max d'instances autorisées.

en fait j'ai quand même un doute sur la compréhension..... j'espère que la limitation c'est 10 instances d'une même scène, et pas 10 scènes différentes, auquel cas on est mal.

t'as vidé le cache je suppose ? c'est le premier truc àfaire.

Normalement, peu de risques d'avoir plus de 10 instances simultanées d'une même scène.... sauf scène codée avec les pieds.

Kiwi, Captain Igloo, la dernière v4.058 Beta supporte officiellement ce thermostat. Avez vous eu l'occasion de tester ?

Le changelog de la dernière v4.058 Beta annonce un plugin pour DENON HEOS 3/link.

M'a l'air pas mal cette version. Par contre : => ça veut dire qu'ils n'ont fait aucun effort sur l'optimisation de leur code, et qu'ils cherchent des moyens de contournement pour éviter les plantages. Donc en gros, va falloir investir dans une barrette RAM de 1 Go supplémentaire :/

Supportée en v4.058 Beta. @olivier828 : tu fais l'update et tu nous dis ce qu'il en est ? (je pense qu'il faudra exclure/réinclure le module)

Peut-être..... mais j'ai quand même pas beaucoup de règles (dans les 70), et surtout je n'ai pas que GEA qui plante. J'ai notamment le VD Sonos de Krikroff qui plante de la même façon (core dump sous Linux, aucun message de debug), donc les scènes comme les VD sont touchés. Donc le watchdog est inévitable, en attendant que Fibaro débugge son moteur d'exécution des scripts. L'étape d'après ça sera le watchdog au niveau de Linux pour ceux qui ont rooté leur box, afin de palier à l'erreur 503. Et là , on aura peut être enfin un système domotique fiable sur lequel on peut compter 24/7/365.

Concernant l'injection de code html dans les VD, c'est pas dis que FIbaro ne le bloque pas un jour. C'est ultra facile pour eux de faire une regex qui filtre tous les tags html; d'ailleurs ils le font pour l'appli mobile. Ca peut poser des problèmes de sécurité si on commence àinjecter du code Javascript.