Lazer

Je pense que c'est la même limitation que les posts sur le forum (2 ou 3 fois des topics ont été plantés àcause d'un copier/coller de code trop long)

Ok tiens moi au courant.

Aucun problème pour les commentaires, ce VD n'est pas très gros. Le seul désagrément (léger) c'est que ça ralenti le chargement de l'interface, surtout depuis un mobile, car il y a du texte inutile àcharger.

Excellent Krikroff, grand retour en fanfare J'adore l'exemple de trajet choisi

Non mais ils sont gentils chez Fibaro, à quoi ça sert d'avoir un hardware de folie si on ne peut pas faire bosser le CPU à plus de 10% sous peine de faire un core dump du process principal. Faudrait peut être qu'ils commencent par apprendre à coder avant de balancer des âneries pareilles. < / mode pas content >

Alors je vais devoir arrêter de ta parler En effet, je viens de copier/coller dans Notepad++.... et devine quoi.... c'est mal tabulé aussi En fait c'est simple, certaines lignes (telles que le "break") n'ont pas de tabulation, mais des espaces !!! Donc selon la largeur de la tabulation configurée dans TON Notepad++, ça s'affiche bien. Mais pas dans MON Notepad++, ni sur le forum. Voilà , Jojo maintenant j'arrête de te parler (temporairement )

voilà => "il y a une boucle if then de plus" Mais ce sont bien les tabulations foireuses qui rendent le code difficile à lire, et masquent la boucle if then de plus.

Il est au bon et au même endroit dans les 2 scripts de Jojo. Ce sont les tabulations foireuses qui t'enduisent d'erreur

J'ai l'impression que tu constates ce que j'ai constaté dans plusieurs entreprises dans lesquelles j'ai travaillé : beaucoup d'agitation, tout le monde est débordé, pour au final produire.... rien !! Non mais là on a quand même un nouveau module virtuel "update-to-date" qui devrait fonctionner quelques soit les conditions. Oui en fait je crois que c'est toutes ces tabulations mal placées qui ont causés les incompréhensions autour du break.

en effet, alors je garde l'idée dans un coin de la tête, mais c'est pas pour tout de suite.

donc y'a pas de raison qu'il ne fonctionne pas

Oui je sais il faut que je complète le premier post, je fais ça plus tard. Tu as toujours des idées tordues.... pour notifier quand l'appareil revient, c'est plus chaud, car il faut mémoriser le statut de chaque device, donc passer par un ou des variables globales. Ca va finir en usine à gaz.

Les codes HTTP en français pour les non anglophones : https://fr.wikipedia.org/wiki/Liste_des_codes_HTTP Et le hasard faisant bien les choses, une petite blague de geek, ça fait 1h que je cherche en vain ma chambre d'hôtel

Comme dis j'ai testé que la première partie du code du post 254, et le break est bien placé. J'ai donc pas testé le bouton d'analyse. Juste une généralité sur le "break", ça existe dans tous les langages, depuis le C jusqu'au LUA passant par le PHP et même le Visual Basic (renommé en "exit for"). Le pendant du break c'est "continue" qui permet de forcer le passage àla boucle suivante. Rarement utilisé, mais pratique quand l'occasion se présente.

Cool. Je précise que les Vg sont créés automatiquement.

Sebcbien j'ai testé ton 1er code du post #254 (celui qui éteint les lumières, car la section analyse ne m'intéresse pas) => ça fonctionne, avec le break là où il est placé, il éteint bien toutes les lumières. En revanche, il manque les shouldInclude() et shouldExclude() Le shouldInclude n'est peut être plus utile depuis qu'on détecte proprement l'interface "light" des devices, en revanche le shouldExclude() est bien pratique. On peut ajouter le test shouldExclude() à la condition suivante : if jsonTable[device].interfaces and not shouldExclude(jsonTable[device]) then

mouais, faudrait que j'ai le courage.... mais je parle pas russe (ou chinois parce qu'ils sont très forts aussi pour les trucs underground) je vous la filerai en privé, mais ça reste assez technique comme manip.

des plugins

Oui on parle d'Apple, et mprinfo en grand fan, accoure aussi vite J'en profite pour passer un message à Pascal : je serai en Lorraine en janvier.... au moins cette fois-ci je t'ai prévenu assez à l'avance j'espère @Jojo désolé de pourrir ton topic

oui en effet, avec la 3.590 j'avais fait plus de 180 jours sans plantage. Làelle a tenu 70 jours, je crois que c'est la plus longue période depuis que je suis en v4 (il faut dire que jusqu'au mois d'août, les mises àjours étaient plus fréquente..... j'espère qu'ils nous réservent une grosse surprise pour la prochaine update, depuis le temps)

Je suis en 4.056 depuis fin aoà»t. Aucun reboot depuis lors. Et bah ce soir, j'ai eu un beau 503 Service Unavailable :angry: Hum, il manque un process : root@fghc2:~# screen -ls There are screens on: 1571.Zwave (08/30/2015 04:08:20 PM) (Detached) 1578.LILIServer (08/30/2015 04:08:20 PM) (Detached) 1355.DbUpdater (08/30/2015 04:08:08 PM) (Detached) 1352.RemoteAccess (08/30/2015 04:08:08 PM) (Detached) 1360.Router (08/30/2015 04:08:08 PM) (Detached) 1251.GPIOServer (08/30/2015 04:08:00 PM) (Detached) 6 Sockets in /var/run/screen/S-root. Oh, plein de mémoire libre comme je n'en n'ai jamais eu autant : root@fghc2:~# free -m total used free shared buffers cached Mem: 993 283 709 0 12 196 -/+ buffers/cache: 73 919 Swap: 243 104 139 Aller, on redémarre tout ça (sans rebooter) : root@fghc2:~# /etc/init.d/fibaro-start restart Stopping periodic command scheduler: cron. HCServer: no process found LuaEnvironment: no process found RemoteAccess killed checkEthernet.sh: no process found GPIOServer started PluginManager: no process found LuaEnvironment: no process found --2015-11-08 22:04:14-- https://getkeys.fibaro.com/get_key_hc2.php?PK_AccessPoint=HC2-000000&HW_Key=... Resolving getkeys.fibaro.com... 109.95.152.66 Connecting to getkeys.fibaro.com|109.95.152.66|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 1675 (1.6K) [application/octet-stream] Saving to: `/tmp/id_rsa' 100%[==============================================================================>] 1,675 --.-K/s in 0.001s 2015-11-08 22:04:14 (1.31 MB/s) - `/tmp/id_rsa' saved [1675/1675] RSA key has been successfuly downloaded. /etc/init.d/fibaro-start: line 76: kill: (1553) - No such process /etc/init.d/fibaro-start: line 83: kill: (1557) - No such process Starting periodic command scheduler: cron. Ah voilà , le process HCServer est revenu : root@fghc2:~# screen -ls There are screens on: 14773.LILIServer (11/08/2015 10:04:31 PM) (Detached) 14764.Zwave (11/08/2015 10:04:31 PM) (Detached) 14472.Router (11/08/2015 10:04:16 PM) (Detached) 14492.HCServer (11/08/2015 10:04:16 PM) (Detached) 14469.DbUpdater (11/08/2015 10:04:16 PM) (Detached) 14467.RemoteAccess (11/08/2015 10:04:16 PM) (Detached) 14347.GPIOServer (11/08/2015 10:04:08 PM) (Detached) 7 Sockets in /var/run/screen/S-root. root@fghc2:~# ps -ef | grep HCServer root 14492 1 0 22:04 ? 00:00:00 SCREEN -dmS HCServer /opt/fibaro/HCServer root 14494 14492 11 22:04 pts/7 00:00:16 /opt/fibaro/HCServer Un peu de RAM utilisé, mais c'est très raisonnable : root@fghc2:~# free -m total used free shared buffers cached Mem: 993 365 627 0 35 153 -/+ buffers/cache: 176 816 Swap: 243 12 231 Je ne sais vraiment pas pourquoi le process principal (HCServer) plante ainsi, mais c'est lui qui consomme le plus de RAM. Alors est-ce qu'il est killé car il consomme trop, ou parce qu'il effectue une instruction interdite, ou autre, je ne sais pas. Je ne trouve rien dans les logs de Linux. Sachant que j'étais à 80% de RAM utilisée la dernière fois que j'ai regardé, c'est à dire environ 21h plus tôt. Maintenant, 1h après le redémarrage des services, je suis à 24% (Buffer+Used) Bilan de tout ça : des lumières qui ne s'éteigne plus (c'est comme ça que je me suis posé des questions) et 1h de trou dans mes graphiques. A noter que pendant ce temps là , la box clignote normalement (les 3 diodes habituelles, plus celle de Z-Wave par intermittence)

Ça existe en France, en fait toutes les gaines sont vendues avec le tire-câble métallique intégré. Et bah c'est bien nul, en général je l'enlève et je passe mon aiguille en nylon àla place. En effet, avec les doigts on n'a aucune prise sur le fin fil métallique, et si on l'enroule autour de la main, ça sectionne la peau, empêche le sang de circuler, une horreur. Même avec des gants. J'ai 2 aiguilles de longueur différente, un tube de yellow, et avec ça je vais partout. Pour accrocher le câble, on le dénude un peu, on fait une boucle, et du scotch marron de déménagement autour pour bien lisser l'ensemble.

Le FGBS est toujours réveillé, il participe au routage Z-Wave. Avec une pile de 9V, tu auras quelques jours d'autonomie, guère plus àmon avis.

Oui 200 c'est la réponse normale. Il y a plein de codes, le 404 est le plus connu (la page demandée n'existe pas).

ok, donc tu es confronté à un bug que je rencontre aussi sur tous mes VD. Si la variable response est trop grosse, alors la commande fibaro:debug n'affiche plus rien. En l'occurrence, ici ta variable response contient le contenu de la page Web de ton appareil. Donc ça peut être assez gros ! Tu n'as donc pas d'autre chois que de te tartiner l'apprentissage à la main, avec un telnet sur ton WDTV. Une fois connecté, il faut que tu tapes la commande suivante je crois : GET / HTTP/1.1 Euh, en fait je viens de penser, il y a plus simple. Avec ton navigateur, tu te connectes sur la page Web det on WDTV, tu regarde le code source de la page, et tu prends une chaine de caractère spécifique que tu pourras mettre dans ta variable DEVICES, colonne "Expected data".