Dgille

oui, d'où le grand nombre de sockets en fin vie. Donc provisoirement, ce n'est pas la source principale de nos problèmes. C'est à la fois rassurant (pour la bonne gestion des sockets) et inquiétant (sur la source des plantages). Merci pour ton aide

J'étais sur le même article. Mais 1100 connexions "en fin de vie" sur 4 minutes max , cela indique quand même une forte activé sur les sockets et les limites hautes sont toujours à 1024, je suis à 4096 sur une centos. il faudrait vérifier les ESTABLISHED, pas impossible que l'on frole les 1024 régulièrement.

Peux tu essayer un ulimit -Ha pour avoir les valeurs max ? merci

Oui, pas normal, sur une centos 7, gros serveur d'application chez moi, le netstat me donne moins de 50 sockets ouvertes. Pas de raison qu'une HC2 en ait besoin d'autant....

Oui, mais le GC du lua fera le ménage après un timeout tcp, donc imaginons de multiples connexions http (sur tcp) jamais fermées, le GC interviendra après le timeout,en ajoutant son propre délai d'activation. Il n'est pas non plus impossible que Fibaro ait modifié les paramétres du noyau linux pour limiter la conso mémoire, je ne suis pas root sur ma box, mais c'est un point àvérifier. Tu sais aussi que le nb total de descripteurs est partagé avec les fichiers, du point de vu de linux, pas de différence entre un handle de fichier et un handle de socket. Tout çàme laisse penser que les plantages de process et coredump associés sont peut être la conséquence de cette surconsommation. Ce n'est qu'une hypothèse, mais ma petite expérience linux me fait penser àcela.

Merci pour ces infos, effectivement, en parcourant le forum, on a l'impression que les fuites mémoires sont responsables de tout nos problèmes, ce qui n'est pas le cas, en tout cas, de ma petite expérience sur HC2. Je suis d'accord sur le fait qu'on ne règlera pas les problèmes àla place de Fibaro, l'idée est plutôt de trouver des solutions de contournement (je vais regarder ton watchdog) et/ou des bonnes pratiques (fermer les sockets), qui permettent d'obtenir un peut plus de stabilité. Je pense que l'on en reparlera dans quelques temps

Merci pour ta réponse, les connexions TCP sous jacentes finissent pas tomber, c'est entendu. De mémoire, c'est 2 heures sur un pile TCP/IP classique. Je ne sais pas à quelle interval le GC du lua entre en action. Théoriquement, si un grand nombre de connexions sont établies dans un délai court, sans fermeture, on peut saturer l'OS. Je vais tester la fermeture de la socket pour voir si cela améliore la stabilité de la box. Sur le fond, je suis d'accord, Fibaro ne fait pas son boulot correctement, mais mes derniers plantages sont survenus avec mon de 20% de mémoire (user, hors buffer) utilisée. J'explore donc toutes les pistes.... Encore merci.

Bonjour à tous, j'avais posé la question dans le forum "pour les nuls", mais sans réponse, je me permets de reposer la question dans le bistrot... pour les pros du lua.... Dans tous les exemples du forum, lors de l'utilisation de l'api net.Fhttp permettant de contacter nos objets connectés préférés (eco device, sonos, netatmo,etc), je ne vois jamais de code de fermeture de la connexion http. Dans tous les autres langage de programme, c'est le cas, pour éviter de consommer un descripteur de connexion et de provoquer in fine le blocage de linux. Comme nos HC2 ne sont pas des modèles de stabilité, et les problèmes de mémoire semblant être éliminés(ou réduits) dans les dernières versions, je me demande si le fait de ne pas fermer ces connexions ne consommerait pas les handles disponibles... merci pour vos réponses !

Bjr, je ne veux pas être désagréable, mais ils ont intérêt àfiabiliser la V4, cela serait dommage d'avoir un bouton d'urgence qui génère une erreur 503 ou un freeze de la box, bien que cela puisse être considéré comme une urgence...

Oui, j'avais vu le message de did, mais cela ne correspond pas àmes observations, d'où ma remarque. Le gradient de t° entre le haut et le bas d'un ballon n'est surement pas le même entre un 100L et un 300L. L'idée n'est pas de calculer la durée du cycle, mais bien la nécessité de chauffer, pas exemple en sautant un cycle si la conso est inférieur à10,20,30 %. Au delà, effectivement, fonction du positionnement du ballon (dans une zone de vie ou pas), de la qualité du ballon et de la température ambiante, on devra prendre une décision différente. Vaste sujet je disais....

Bjr, le plus fiable serait de mesurer la température de sortie. Dans un ballon, l'eau chaude est en haut. Mesurer le température au niveau de la résistance n'est pas fiable. Une autre solution est de positionner un compteur gianola à l'entrée (ou à la sortie) et de déclencher le cycle de chauffe après la consommation de x% de la capacité du ballon. Vaste sujet..... donc bon courage.

Bonjour, je confirme, box planté si l'on sollicite trop homebrige.

Bonjour, un autre point important a remonter est l absence de visibilité sur les évolutions du produit. Une communication régulière sur les évolutions prévues serait vraiment intéressante. Et une version vraiment stable de temps en temps aussi.... Et le support des modules qubino.... Et j arrête là...

+1 voire +2

Pas dans mon cas. Je l'ai créé manuellement et ensuite plus de problème. Je teste le plug in http pour le moment dans le cadre de mon activité professionnelle. je testerai le plug fibaro ce week @ home....

Bjr, le dossier /home/pi/.homebridge doit être créé manuellement , ensuite ça roule... Perso, je suis reparti d'une wheeezy toute propre. J'avais commencé le test en partant d'une image domoticz avec homebridge installé, mais le plugin fibaro ne tourne pas (pb de version de nodejs,etc...) PS: bien penser à avoir un RPI à la bonne date et heure, sinon cela génère pas mal d'erreurs sur les certificats https.

Bonjour, le plus simple serait d'utiliser le sysmographe du FGMS, bref, coller l'oeil de sauron à la porte. Tu détecteras aussi l'ouverture.

Bjr, tu peux également essayer de réaliser une capture wireshark pour t'assurer que la box émet bien la trame et voir la réponse du device. il te faudra intercaler un bon vieux hub ou un switch avec un port en mirroir.

Bonsoir, je viens de les installer, avec la 4.058b. Ils fonctionnent, mais pas de template. La sonde de temperature ne semble pas reconnue. Wait and see...

Je confirme, les modules sur piles ne sont pas relais sauf exception. Ils doivent être inclus en communication directe avec la box. Il faut ajouter des modules zwave alimentés en permanence pour étendre la portée ou acheter un extender zwave, mais pour le prix, autant acheter un wall plug par exemple.

L'un d'entre vous a t il testé les filtres LEA Netfilter NANO ? Efficace ?

Bonsoir, de mon coté, j'ai eu des problèmes avec l'alimentation de la HC2 qui perturbe les freeplug. C'est généralement lié àla qualité des alimentations àdécoupage. Il faut donc idéalement connecter la HC2 sur une prise (et une ligne) distincte de celle des adaptateurs CPL pour garantie le débit max sur ceux-ci.

Quand j écrivais a méditer, je ne pensais pas que cela irait si loin ....

Juste pour fournir un dernier élément sur les virtuals appliances, il y a des vms prêtes à l'emploi chez bitnami et turnkey linux avec un nginx préinstallé. De plus, il y a un mécanisme de mise à jour automatique des composants linux, donc coté sécurité, c'est déjà une bonne base. Ajoute à cela un peut de filtrage par nom de domaine et geo ip et tu as quelque chose de pas mal coté sécuirté et que tu maitrises. En résumé, pour l'utilisateur sans compétence linux, l'accès à distance via Fibaro est un bon compromis. Si vous voulez de la performance (à distance) et maitriser la solution, vous savez ce qu'il vous reste à faire. @D-GK, pour rester dans le volet paranoia, y a t il plus de risque lors d'une intrusion physique (=voleur), ou lors d'une intrusion virtuelle (=piratage)... A méditer

L'un n'exclue pas l'autre, j'ai déjàdes plantages avec une mémoire à45% Ce n'est pas comme si il n'y avait qu'un seul problème avec cette box , mais on l'aime qd même...