Lazer

Le problème du support, c'est que Fibaro cible les particuliers, et pas les professionnels. Dans un domaine que je connais bien, l'informatique d'entreprise, le matériel (ou logiciel) est vendu avec une maintenance payante année par année. Au bout de 5 ans on en a pour plus cher de maintenance que de matériel/licence. Mais cela fait toute la différence, pour le prix tu as un vrai support qui est disponible, compétent, fait remonter le problème au niveau 2, 3, ou jusqu'aux développeurs s'il le faut, et chaque problème est obligatoirement résolu, sinon le dossier n'est pas fermé (j'ai eu un dossier qui a mis presque un an à être résolu....) Selon le contrat de maintenance payé, le support se fera en 24/7 avec engagement de temps de prise en compte (voire engagement de temps de résolution, même si c'est rarement respecté) Un support gratuit ne pourra jamais atteindre ce niveau de service..... donc Fibaro ne pourra jamais assurer un support pro tant que ça sera fait gratuitement. Il est compréhensible que le support Fibaro ne soit pas à la hauteur, et je suis même étonné qu'ils acceptent de réparer des box par renvoi en Pologne plusieurs années après leur achat par l'utilisateur.

dans l'interface Web, il y a une icone qui donne la température du module. Donc après, en fonction de ce que tu as installé comme application sur tes tablettes, tu peux récupérer cette info (imperihome, fibaro, etc)

qu'appelles tu "contrôle de température" ? Ce n'est qu'une sonde qui ne fait que remonter des valeurs vers la box, il n'y a aucun contrôle possible;

ah si y'a le double clap, ça change tout

Lol j'étais en train de me faire la même réflexion, et le temps de l'écrire j'ai vu ta réponse arriver

oui mais pas tout de suite.... car j'ajuste le module en fonction de mon propre besoin (donc déjà c'est pas dit que ça convienne à tout le monde), mais aussi en fonction de comment je découvre la réaction de ma PAC à la thermodynamique de la maison. La température chute de jour en jour, et hier je te disais qu'elle faisait un cycle de dégivrage toutes les 3h la nuit, et bah maintenant je viens de regarder pour aujourd'hui, c'est un cycle par heure ! Donc c'est plus du tout pareil, il va falloir que j'ajuste des paramètres pour prendre ça en compte, et essayer de ne pas trop forcer sur la PAC, quitte à remettre en route un convecteur d’appoint dans un coin (à défaut de pouvoir domotiser la cheminée....) Bref, déjà que ça ne me convient pas à 100%, donc je ne peux pas encore partager cela..... à mon avis ça sera prêt à la sortie de l'hiver (mais au moins ça sera au top pour le suivant ) Reste que l'été prochain il faudra ajouter la gestion du mode climatisation (=refroidissement) afin que le VD soit complet.....

Il n'en n'a pas besoin, il envoie un ordre à la clim. C'est la clim qui se débrouille pour réguler. C'est exactement comme pour un module Qubino Fil Pilote : il envoie un ordre, mais il ne faut aucune régulation.

Le jour où c'est compatible HC2, j'en prend plusieurs de ce dimmer DIN. Oui faut creuser cette histoire de template..... à mettre sur la todo-list ! Pascal : J'ai vu un nouveau topic sur Gédon sur le forum, je vais aller voir ça

forcer peut être, je n'ai pas cherché car : - la précision à1°C près, totalement inexploitable, donc information inutile - mon ZXT est placé près du plafond, làoù la mesure de température n'est pas représentative - dans le salon, j'ai déjàun ST814, une Netatmo, un Motion Sensor, et un Smoke Sensor, donc les mesures de température, àforce, je ne sais plus quoi en faire

je répond quand même : j'ai la même température depuis 6 mois, donc tu peux encore attendre

au collège, en cours de technologie, j'avais bricolé un tel module. Tout content de le ramener chez moi, je le branche, je joue avec la soirée, c'est cool. Le lendemain, je suis retourné à l'école, je soir en revenant la lumière était allumée. Depuis il traine au fond d'un tiroir (ou à la poubelle, je ne sais plus, ça fait des années que je ne l'ai pas revu). Ce sont des gadgets pour épater les potes, mais ce n'est pas fiable du tout. L'avantage avec la domotique, c'est que tu peux te servir des conditions (présence, etc) pour décider d'allumer effectivement la lumière ou non..... mais sans ça, la détection du clac de base est vraiment trop aléatoire

non mais la sonde de température du ZXT 120 ne remonte pas la température régulièrement, c'est un fait connu et reconnu Cela n'en fait pas un mauvais module pour autant, sa fonction première est de piloter une clim, et il le fait très bien, pour peu qu'on arrive àconfigurer le bon code pour sa propre clim. J'ai eu un premier modèle que j'ai du faire remplacer en garantie (problème de "batterie" bien qu'il était alimenté sur secteur). Le remplaçant fonctionne tous les jours depuis plusieurs mois, c'est ultra fiable, j'en suis super content

oui tout à fait chris6783 @yuhe tu n'étais même pas obligé de lire/écrite la clé entière. Seule la recopie du contenu du répertoire "backups" de la clé suffit (avec l'explorateur de fichiers standard de ton OS), normalement tout le reste est identique.

j'ai l'impression que les autocollants sont génériques, et ne sont pas spécifique à Diagral.... mais rien de certain. De toutes façons, la marque est parfaitement visible si tu as une sirène extérieure.

Si la boite est déjà posée, découpe avec outil multifonction (type Fein) Si la boite n'est pas encore posée, découpe avec un outil type Dremel Ensuite, si le mur est en béton/parpaing/brique, un coup de perfo dedans et c'est réglé. PS : le fer à souder, t'as pas intérêt de toucher les fils :/ et puis ça pollue grave !

> il y a plusieurs version du FGMS-001 ou c'est juste le firmware qui change à l'interieur? Pas clair, il y a au moins le firmware qui change, je ne sais pas dire si le hardware a évolué ou pas > Ce firmware peut il etre mis a jour? Le firmware PEUT être mis à jour Mais, nous ne POUVONS pas mettre à jour le firmware Subtile nuance J'ai les tout premiers modèles, acheté la 1ère semaine de leur commercialisation, et ils fonctionnent très bien. Les erreurs rencontrées par les un et les autres sont avant-tout des problèmes de configuration..... il y a tellement de paramètre, qu'il faut relire plusieurs fois la doc pour comprendre.

Sur la VM Debian, création d'une page Web eco.html servie par Apache contenant un JSON basique (issu d'un Eco-Devices) : {"product":"Eco-devices","T1_PTEC":"HC..","T1_PAPP":1560,"T1_HCHP":11861401,"T1_HCHC":9250490,"T2_PTEC":"----","T2_PAPP":0,"T2_BASE":0,"INDEX_C1":3371475,"INDEX_C2":2829685} . Sur la HC2, création d'un VD avec un bouton contenant le code suivant : -- Test de charge fibaro:debug("Starting loop...") local selfID = fibaro:getSelfId() local ip = fibaro:get(selfID, 'IPAddress') local port = fibaro:get(selfID, 'TCPPort') local i = 0 while i < 1000 do local WEB = Net.FHttp(ip, tonumber(port)) local response, status, errorCode = WEB:GET("/eco.html?i="..tostring(i)) if tonumber(errorCode) == 0 and tonumber(status) == 200 and response ~= nil and response ~= "" then fibaro:debug("i="..i.." memory="..collectgarbage("count")) else fibaro:debug("Erreur : i="..i) end i = i + 1 --WEB = nil --collectgarbage("collect") end fibaro:debug("Loop finished") . Après enregistrement du VD, sous Linux, on récupère le PID du process associé au VD : root@fghc2:~# ps -ef | grep "PluginManager 15" root 1754 1 0 16:21 ? 00:00:00 /opt/fibaro/PluginManager 15 startMainLoop 0 0 ... De base, ce VD a déjà 26 descripteurs de fichiers ouverts : root@fghc2:~# ls /proc/1754/fd | wc -l 26 . On lance le test en appuyant sur le bouton du VD. Dans la fenêtre de debug : [DEBUG] 16:34:41: Starting loop... [DEBUG] 16:34:41: i=0 memory=32.888671875 [DEBUG] 16:34:41: i=1 memory=33.0341796875 [DEBUG] 16:34:41: i=2 memory=33.181640625 [DEBUG] 16:34:41: i=3 memory=33.3271484375 [DEBUG] 16:34:41: i=4 memory=33.474609375 ... [DEBUG] 16:34:43: i=992 memory=50.4111328125 [DEBUG] 16:34:43: i=993 memory=50.564453125 [DEBUG] 16:34:43: i=994 memory=50.7158203125 [DEBUG] 16:34:43: i=995 memory=50.869140625 [DEBUG] 16:34:43: i=996 memory=51.0205078125 Cela s'arrête brusquement à la 997ème itération, sans jamais arriver au message "Loop Finished". L’exécution est très rapide, cela ne prend que 2 secondes (donc environ 500 requêtes http par seconde, le LUA est décidément un langage très rapide, bien plus que le Shell). L'occupation mémoire du moteur LUA reste très contenue, ne montant qu'à 51 ko. Sous Linux, on observe l'apparition d'un core dump : root@fghc2:~# ls -l /core -rw------- 1 root root 9261056 Jan 19 16:21 /core Cela s'exécute tellement vite que je n'ai pas le temps de monitorer le nombre de fichiers ouverts, mais de toute évidence on atteint la fameuse limite de 1024 fixée par le ulimit du système (26 + 997 = 1023). Dans le code LUA, j'ai mis en commentaire les 2 lignes suivantes à la fin de la boucle while : WEB = nil collectgarbage("collect") Si on les décommente et qu'on relance le test, on constate que la RAM utilisée par le moteur LUA n'augmente pas et se limite à 30 ko. En revanche les performances sont bien inférieures, car on force le garbage collector à tourner à chaque passage dans la boucle. Mais surtout, le nombre de descripteurs de fichiers atteint quand même 1024, occasionnant quand même le crash du VD avant de terminer la boucle : [DEBUG] 16:21:25: Starting loop... [DEBUG] 16:21:25: i=0 memory=32.9609375 [DEBUG] 16:21:25: i=1 memory=30.333984375 [DEBUG] 16:21:25: i=2 memory=30.365234375 [DEBUG] 16:21:25: i=3 memory=30.365234375 ... [DEBUG] 16:21:27: i=993 memory=30.369140625 [DEBUG] 16:21:27: i=994 memory=30.369140625 [DEBUG] 16:21:27: i=995 memory=30.369140625 [DEBUG] 16:21:27: i=996 memory=30.369140625 . Enfin, si on sort la ligne local WEB = Net.FHttp(...) de la boucle while, pour le positionner avant d'entrer dans la boucle, il n'y a qu'un seul socket TCP utilisé durant tout le script, donc la boucle s'exécute parfaitement. Je suis allé à 10'000 itérations sans faire broncher la box, et c'est encore plus rapide (car il n'y a pas besoin de rouvrir un socket à chaque passage dans la boucle, opération de loin la plus longue sur la totalité des instructions présentes) Conclusion de ce test : Cela se confirme, on a donc bien une limitation à 1024 fichiers ouverts par chaque process (chaque VD, Scène, Plugin étant dans des process séparés). Avec ce petit benchmark; volontairement violent, on atteint en 2 seconde la limite, et donc le crash (core dump) du process lié au module virtuel. Le test suivant sera de faire un bench un peu plus représentatif de nos modules virtuels que nous utilisons couramment. C'est à dire d'exploiter la Main Loop et son sleep() de 3 seconde à chaque passage dans la boucle. Cela laissera le temps de monitorer les descripteurs de fichiers ouverts au niveau Linux, et de voir si la main loop ouvre les sockets plus vite que la pile TCP/IP les libère.

Comme je le disais, la config Apache est ultra standard (/etc/apache2/sites-available/default) : <VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/> Options FollowSymLinks MultiViews IncludesNOEXEC AllowOverride All Order allow,deny allow from all </Directory> ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ <Directory "/usr/lib/cgi-bin"> AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory> Alias /doc/ "/usr/share/doc/" <Directory "/usr/share/doc/"> Options MultiViews FollowSymLinks AllowOverride None Order deny,allow Deny from all Allow from 127.0.0.0/255.0.0.0 ::1/128 </Directory> # ProxyRequests On ProxyPass /api http://127.0.0.1:11111/api retry=0 Options +Includes AddType text/html .html AddOutputFilter INCLUDES .html </VirtualHost> La seule ligne intéressante, c'est le ProxyPass. Le process HCServer écoute bien sur le port 11111 : root@fghc2:~# netstat -aep | grep LISTEN | grep 11111 tcp 0 0 *:11111 *:* LISTEN root 4485 1350/HCServer . Je fais le test en LUA dès que possible. Par contre je suis en train de penser que mon test d'hier soir n'est pas représentatif du bug rencontré sur Homebirdge. Car je me suis contenté de surveiller le crash des process, mais le problème est différent avec Homebirdge ; apparemment, plus aucun ordre Z-Wave ne passe, donc ce n'est pas tout à fait pareil....

t'as un 486 DX2 66 MHz ? :huh: :huh:

Non Apache c'est bien les process httpd classiques, indépendants des développements Fibaro. Idem pour PHP. Je regarderai la conf demain, mais c'est du relativement standard de mémoire. HCServer c'est le processus principal de la box (en C compilé, donc on ne sais pas ce qu'il y a dedans). C'est un espèce d'ordonnanceur, qui va communiquer vers les process Z-Wave, le DB Updater, les VD, Scène, Plugins, etc... Ce HCServer est notamment responsable de l'API, pour rappel tout passe par l'API (nos scripts, nos commande LUA de type fibaro;call(...) setvalue(...) etc et aussi l'interface Web, les applis mobiles, etc). L'API est disponible via l'URL /api sur le port 11111 en localhost uniquement (proxy Apache local), et c'est le process HCServer qui écoute sur ce port, donc c'est lui qui traite toutes les requêtes. Lors de mon test de charge aujourd'hui, c'était bien le process HCServer qui était logiquement responsable de la majorité du %User CPU (et un peu de %Syst, car il fait des appels systèmes aussi) En effet pour Homebridge c'est assez mystérieux.... je ne l'utilise pas, mais il faudrait monitorer la box (en root bien sà»r) durant toute la phase de fonctionnement, jusqu'au crash. J'envisage 2 cas possible : - une augmentation d'un paramètre, qui finit par mener au crash (à priori on a exclu les sockets TCP et la RAM avec le test d'aujourd'hui, mais on est peut être passé à coté d'un autre paramètre critique) - le chaos, c'est à dire un développement anarchique purement Fibaro, qui fait que le bug se produit de façon aléatoire. Les requêtes répétées de Homebridge ne font qu'augmenter la probabilité d'occasionner ce bug. Mon test d'aujourd'hui également, peut être qu'en le laissant tourner une journée complète ça finirait par arriver.

Du coup, je propose de réinitialiser le compteur de message de Pascaldu54 à0. Vous êtes tout d'accord bien sûr ?

Test violent depuis un Linux : une requête http toutes les 30ms vers /api/devices : while [ 1 ] do curl --silent -u admin:password http://192.168.x.y/api/devices > /dev/null done A la louche, ça fait donc environ 30 requêtes à seconde. J'ai laissé tourné environ 10 minutes..... soit plus de 18000 requêtes HTTP ! Sur la HC2, le nombre de connexions en TIME_WAIT monte assez vite, puis se stabilise : root@fghc2:~# netstat -a | grep TIME_WAIT | wc -l 4188 root@fghc2:~# netstat -a | grep TIME_WAIT | wc -l 4232 root@fghc2:~# netstat -a | grep TIME_WAIT | wc -l 4075 root@fghc2:~# netstat -a | grep TIME_WAIT | wc -l 4622 root@fghc2:~# netstat -a | grep TIME_WAIT | wc -l 4338 Coté client (ma VM Debian), on a sensiblement le même nombre de TIME_WAIT. Aucun process n'a crashé, et en particulier le HCServer qui est responsable des 503 Unavailable Error : root@fghc2:~# screen -ls There are screens on: 1386.LILIServer (01/14/2016 06:26:47 PM) (Detached) 1383.Zwave (01/14/2016 06:26:47 PM) (Detached) 1335.Router (01/14/2016 06:26:43 PM) (Detached) 1327.RemoteAccess (01/14/2016 06:26:43 PM) (Detached) 1348.HCServer (01/14/2016 06:26:43 PM) (Detached) 1330.DbUpdater (01/14/2016 06:26:43 PM) (Detached) 1256.GPIOServer (01/14/2016 06:26:36 PM) (Detached) 7 Sockets in /var/run/screen/S-root. L'utilisation en RAM est totalement stable durant ce test (version 4.063 Beta) : root@fghc2:~# free -m total used free shared buffers cached Mem: 993 470 522 0 61 233 -/+ buffers/cache: 175 817 Swap: 243 0 243 Après : root@fghc2:~# free -m total used free shared buffers cached Mem: 993 469 523 0 61 231 -/+ buffers/cache: 176 816 Swap: 243 0 243 Bref, on peut y aller niveau charge sur l'API, la HC2 encaisse sans souci. Donc on en revient toujours au même : les crashs ne sont pas dus à une charge excessive, puisque notre HC2 ne fait rien en temps normal (charge CPU moyenne très largement inférieure à 10%, plutôt proche du pourcent.....) Demain je ferai le test inverse, en utilisant la HC2 comme client http. Il faut que je monte un Apache sur ma VM pour donner un peu de données à ingurgiter à la HC2. Si tu as une idée d'un autre test que je peux faire, c'est le moment

mprinfo est parti mais voici Pascaldu54, pro-jeedom

C'est moi ou le forum est ànouveau très lent en ce moment ?

Si j'ai le temps ce soir, j'essaierai de monter une maquette avec ma HC2 de test et mon serveur Xeon en face.... test de requêtes http massives dans un sens, puis dans l'autre, afin de voir si on arrive àcrasher la HC2.