Dgille

La beta 4.151 corrige le probleme des panneaux de chauffage pour info.

Je confirme, c est corrigé.

Cela depend de ta programmation, si tu changes la consigne entre minuit et 5h, le panneau retourne une consigne incorrecte. J ai mis un exemple sur le sujet heating panel d OJC.

Cela met un peu de piment dans la platitude d une vie monotone...l excitation de l update fibaro, c est mieux que...

Ils annoncent la correction des panneaux de chauffage, yes. J installe et vous confirme cela demain.

Oui, c'est vrai, mais cela a le mérite de la simplicité. on reporte le problème sur l'application. Un navigateur web ouvre plusieurs connexions TCP simultanément (pour charger généralement les images en // du texte), et TP Link annonce plusieurs stratégies de répartition de charge. Donc, au quotidien, cela peut améliorer les choses. Mais une application faisant tout passer dans une seule connexion TCP sera probablement limitée au débit d'une des liaisons. Dans le cas d'une vidéo, il est effectivement probablement qu'une seule socket sera mise à contribution. On peut faire mieux, mais c'est plus cher et plus compliqué. Je suis moi même dans le monde du réseau, et je n'imagine pas une seconde mettre en place ce genre de chose à la maison, trop usine à gaz. Mais pourquoi pas dans l'entreprise.

Bonjour, au delà du DO IT YOURSELF, toujours plaisant, il y a des solutions simples et pas chères. http://www.tp-link.fr/products/details/cat-4910_TL-R470T+.html Un petit routeur Multiwan à 50 € (sur amazon) qui fera le boulot simplement, possibilité d'agréger 4 liens.

Bonjour à tous HC2-025300 - 08/2015

Bug créé chez Fibaro. wait and see.

Merci, effectivement, il y a quelque choses de pourris au royaume des panneaux :). Je précise que j'ai constaté cela même sans changement manuel. Je pense que les développeurs Fibaro ont modifié les panneaux (extension de la nuit jusqu'à 5h du mat) après une longue soirée arrosée, et ne calcule pas correctement l'horaire associé pour la température (en tenant compte de la journée d'avant ou d'après selon les cas).

Bonjour à tous, super boulot, j'avais un module qui faisant la même choses, mais en moins bien. Top. Par contre, je ne sais pas si vous êtes confrontés au problème, il semble rester un bug dans le panneaux de chauffage depuis quelques versions (y compris les dernières bétas) Si vous prenez ce panneau par exemple: {"id":6,"name":"Rez de Chaussée","properties":{"monday":{"morning":{"hour":6,"minute":30,"temperature":15.0},"day":{"hour":16,"minute":0,"temperature":19.0},"evening":{"hour":22,"minute":30,"temperature":15.0},"night":{"hour":4,"minute":0,"temperature":19.0}},"tuesday":{"morning":{"hour":6,"minute":30,"temperature":15.0},"day":{"hour":16,"minute":0,"temperature":19.0},"evening":{"hour":22,"minute":30,"temperature":15.0},"night":{"hour":4,"minute":0,"temperature":19.0}},"wednesday":{"morning":{"hour":6,"minute":30,"temperature":15.0},"day":{"hour":16,"minute":0,"temperature":19.0},"evening":{"hour":22,"minute":30,"temperature":15.0},"night":{"hour":4,"minute":0,"temperature":19.0}},"thursday":{"morning":{"hour":6,"minute":30,"temperature":15.0},"day":{"hour":16,"minute":0,"temperature":19.0},"evening":{"hour":22,"minute":30,"temperature":15.0},"night":{"hour":4,"minute":0,"temperature":19.0}},"friday":{"morning":{"hour":6,"minute":30,"temperature":15.0},"day":{"hour":16,"minute":0,"temperature":19.0},"evening":{"hour":22,"minute":30,"temperature":15.0},"night":{"hour":4,"minute":0,"temperature":19.0}},"saturday":{"morning":{"hour":6,"minute":45,"temperature":19.0},"day":{"hour":9,"minute":45,"temperature":19.0},"evening":{"hour":23,"minute":0,"temperature":15.0},"night":{"hour":4,"minute":0,"temperature":19.0}},"sunday":{"morning":{"hour":6,"minute":30,"temperature":19.0},"day":{"hour":16,"minute":0,"temperature":19.0},"evening":{"hour":22,"minute":30,"temperature":15.0},"night":{"hour":4,"minute":0,"temperature":19.0}},"handTemperature":0.0,"handTimestamp":1509725422,"vacationTemperature":0.0,"currentTemperature":15.0,"rooms":[1,2,3,4,10,117,132]},"created":1510423601,"modified":1510423601} Vous constaterez que le champ "currentTemperature" retourne la mauvaise valeur entre minuit et 5:00. J'ai le problème sur tous les panneaux qui décident de chauffer avant 5h du matin. Je dépose un ticket sur bugzilla si vous confirmez le problème.

Cela peut se faire en snmp, via un put, c est plus technique, mais il faut positionner une communaute en lecture ecriture, trouver l OID du port dans la Mib. C est peut etre plus simple depuis un syno que depuis la hc2.

Oui, et bientôt, on aura une HC 3 bluetooth avec la V5 qui pemettra d'utiliser tout cela (après 200 à 300 versions béta).

Bonjour à tous, je ne sais pas si c'est le bon topic, ni si cela mérite un topic dédié, je vous livre donc un petit retour d'expérience. Depuis la version 4.063, la stabilité de ma jeune box laisser à désirer. Des fuites mémoires régulières m'obligeait à un reboot régulier de la box tous les 3/5 jours. Alors que l'énervement m'envahissait et que la box se tenait au bord de la fenêtre retenue uniquement par le cable ethernet, j'ai décidé de la rooter pour investiguer (merci à Lazer pour les petits cailloux blancs). Après petite analyse, mon problème venant finalement du plugin onkyo fibaro. Chez onkyo, il est possible d'activer ou de désactiver l'écoute sur le réseau ethernet (pour pilolter l'allumage par exemple), au prix d'un conso de quelques dizaines de watts en permanence. Ne l'utilisant pas tous les jours, j'avais désactivé la fonctionnalité. Le plugin onkyo sur la hc2 semble tenter de communiquer en permanence avec l'ampli et au bout de quelques jours, le process "Luaenvironnement" pour les connaisseurs s'emballe et consomme de la mémoire jusqu'à saturation.... Conclusion provisoire, dans vos VD/Plugin, assurez vous que vos devices cibles IP soient toujours joignables.... Dire que je doutais de mes VD et de mon code LUA, le problème venait donc de Fibaro. Après réactivation sur l'onkyo (ou suppression du plugin), stabilité retrouvée à 21 % de mémoire depuis plusieurs jours.. C'est inespéré et je re aime (temporairement) ma box. A toutes fins utiles.

Avec son look de bouton d'arrêt d'urgence, je lui collerai bien une scène de reboot de la box..... En fait, il sont cohérents chez Fibaro, ils fournissent une 4.090 pas si stable et le moyen de la redémarrer facilement .

Bonjour à tous, maj en 4.090 sans problème, pas de 503, rien, mémoire ultra stable pendant 4 à 5 jours.... et en moins d'une heure, passage à plus de 85 % de ram... Heureusement, j'ai modifié le VD de diagnostic pour redémarrer tout seul après un petit message. (je peux le publier si cela intéresse quelqu'un). Donc cette version est clairement mieux que les précédentes, mais il y a encore du travail....

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 !

Excellent, mais je vais attendre la superstable de Fibaro, ou la superbéta au choix avant de me lancer......

Vous n'avez pas pensé àmettre un FGS et une hc2 dans vos voitures, je suis déçu. Une petite scène et ça reboot la voiture en mode automatique...

Bonjour à tous, un petit retour d'expérience suite aux échanges ci dessus. Pour repréciser le contexte, je suis toujours en 4,063b. Avec plantage (erreur 503) de la box tous les 4/5 jours au début de la discussion. Suite aux échanges avec Lazer( encore merci pour le tps passé), j'ai rebalayé mes VD pour fermer proprement mes sockets. Aujourd'hui, j'ai un uptime de plus de 350 heures (14/15 jours) sans reboot (yes!!). Le seul VD qui plante régulièrement et qui est relancé par le watchdog de Lazer, c'est la remontée emoncms sur internet. je vais encapsuler la fonction dans un pcall pour voir si cela améliore les choses. De ma fenêtre, cette fermeture des socket a quand même bien stabilisé la box. Cela dit,o n parlera de vrai changement quand elle tiendra 3 à 4 mois sans reboot.... A suivre donc.

Bjr, j'ai également des lenteurs sur l'accès àdistance, sans faire la maj, donc cela ressemble plutôt àdes lenteurs sur les serveurs de rebond fibaro.

On ne peut pas tout avoir pour rien, et le critère cloudless n'est qu'un critère parmi d'autres (pour moi en tout cas). L'important, c'est d'avoir le choix. Mais tu es dans le vrai coté organisation, tout reste à construire. L'informatique s'invite dans beaucoup de domaines, la domotique fait appel à plusieurs domaines techniques (électricité, plomberie, configuration voire programmation) et nos vénérables artisans électriciens n'ont pas encore pris le virage, même si certaine PME s'y mettent. Ces sont des métiers en mutation, comme l'automobile, ou les "mécanos" devront bientôt (si ce n'est pas déjà le cas) avoir de bonnes connaissances en informatique. C'est aussi un axe de développement pour les domotique-store, domadoo, etc.... Il n'y a plus qu'à ....

Bonjour à tous, je rejoins l'avis de Lazer. Idéalement, Fibaro devrait proposer un contrat de maintenance, même minimal en terme de coà»t, mais avec un engagement de service, c'est à dire un délai max de traitement des bugs, des problèmes matériels, etc.... On va confier de plus en plus de chose à notre box et la vrai question c'est combien de temps acceptons nous d'être sans chauffage, eau chaude, etc.... en cas de panne ? De ma fenetre , le bon modèle c'est d'avoir le choix: on ne confie rien de sensible et le support est gratuit, pas d'engagement de délai la box est sensible, on paie (le moins possible) , mais avec la garantie d'être dépanné en cas de problème.

Super, en sachant aussi qu'au total, linux ne peut pas gérer plus de 65535 handles, avec ton test, 60 vd (mal écrits, c'est vrai), plus les besoins propres à la box, on peut arriver au bout je pense. Ma conclusion provisoire est donc qu'il faut quand même apporter un soin particulier à l'écriture des scènes et VD en lua (mais c'est valable pour tous les langages), et ne pas faire n'importe quoi; On peut aussi essayer de modifier cette limite de 1024 handles/process, mais si c'est mal écrit, cela ne fait que repousser le problème. Pour les VD, je me dits aussi que cela milite en faveur d'une main loop appelée régulièrement plutôt qu'une boucle infinie..... et on a quand même intérêt à fermer les sockets en cas d'usage intensif de net.fhttp. Par contre, cela conforte ton opinion sur les développeurs fibaro, le net.fhttp devrait renvoyer une erreur en absence de handle au lieu d'un coredump :angry: C'est peut être un point à leur remonter. voilà , on a au moins quelques bonnes pratiques merci pour te temps passé sur le sujet, je suis convaincu que c'est la source d'une bonne partie des soucis remontés, même s'il y a surement d'autres problèmes, on peut leur faire confiance.

Ok, merci. donc , si tu as l'occasion de faire de test en lua en tant que client, interrogeant un objet connecté en http, sans fermer la socket, voire les deux tests simultanément. Pour mettre en évidence l'éventuelle mauvaise gestion de ces connexions par le HCserver, le test pourrais consister à occuper les 1024 handles (c'est la valeur max d'après le ulimit -Ha), et si l'API en a tant besoin, on provoquera peut être le plantage.