Lazer

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".

Ca câble passe dans du 16mm, mais tu vas en chier si tu as des virages un peu trop serrés et que tu as de la longueur. Je te conseille du 20mm. J'arrive à passer 3 câbles dans une gaine de 25mm avec une bonne dose de lubrifiant Yellow, avec 1 personne à chaque extrémité de la gaine pour tirer et pousser (pour guider les 3 câbles bien parallèles), avec des rayons de courbure assez large. Les puristes de l'audio te dirons qu'on ne met rien avec (c'est pas pour rien que dans les câbles très haut de gamme, les 2 âmes de chaque paire sont séparés par plusieurs millimètres de gaine plastique). Après tu fais comme tu le sens

Nan mais t'as rien compris Nico. Le Mac c'est forcément mieux. Y'a même pas besoin d'argumenter.

J'essaye de regarder ça ce soir.

@jackd67000 : si tu arrives à négocier avec Fibaro, tu seras bien le premier ! Et vu qu'ils n'ont aucune envie de négocier, et que tu vas perdre ton temps avec des classes actions ou je ne sais quelle procédure juridique, y'a qu'une seule solution qui fonctionne avec ce genre de sociétés : c'est de balancer la procédure complète pour hacker la box sur un obscur forum russe. Au moins là t'es tranquille, tu rends service à tout le monde, et ça les fera peut être réfléchir à l'inutilité de leur protection (je dis bien que c'est inutile, car l'intelligence de la HC2 est dans le logiciel associé à la carte fille fixée sur la carte mère.... et la clé USB ne sert strictement à rien d'autre que faire des sauvegarde et recovery). J'essaye de te préparer une procédure dans la semaine, mais là je n'ai rien de complet, je doute que tu y arrives du premier coup. Tu peux déjà trouver une clé vierge de 4 Go ou plus.

T'as pas peur mprinfo de prendre ton Windows sur des sites de téléchargement.... le meilleur moyen de se chopper des trojans, sypwares, et autres backdoors.

Dans la condition suivante : -- HTTP elseif param[3] == "http" then Tu as les 3 lignes suivantes que tu peux décommenter pour "décrouvrir" les réponses attendues : --if debug then --fibaro:debug("errorCode=" .. errorCode .. " - status=" .. status .. " - response=" .. response) --end N'oublie pas de mettre la variable debug=true en début de script. Autrement, tu peux faire la découverte à la main, on utilisant un bête Telnet (via PuTTY ou en ligne de commande) sur l'IP et le port de la machine que tu veux tester.

Alors c'est que ta box n'est pas en bridge. Puisque tu le dis toi même, tu as 2 routeurs.

Vérifie que ton routeur Netgear autorise le routage en loopback. Parmi les box fournies par les opérateurs, la Freebox est la seule à le faire. Pour les routeurs tiers, j'imagine que c'est au cas par cas.

Suggestion d'optimisation : A la fin de la condition suivante : if jsonTable[device].interfaces[interface] == "light" then je propose d'ajouter un : break afin de sortir de la boucle englobante : for interface = 1, #jsonTable[device].interfaces do Et donc gagner des cycles d'horloge Ce qui donne : ... if jsonTable[device].interfaces then for interface = 1, #jsonTable[device].interfaces do if jsonTable[device].interfaces[interface] == "light" then local DeviceValue = tonumber(jsonTable[device].properties.value) if (DeviceValue and DeviceValue > 0) or (jsonTable[device].properties.value == "true") then --fibaro:debug(" id: "..jsonTable[device].id.." is "..jsonTable[device].name.." type: "..jsonTable[device].interfaces[interface]) --fibaro:debug(" value: "..jsonTable[device].properties.value..". Turning Off") compteurLumieres = compteurLumieres + 1 debug("lumière : " .. jsonTable[device].name .. " ("..jsonTable[device].id..")" ,"red") if compteurLumieres <= 10 then fibaro:call(selfID, "setProperty", "ui.Lum"..compteurLumieres..".value", jsonTable[device].name .. " ("..jsonTable[device].id..")") end end break end end end ...

Maintenant tu comprend en partie pourquoi beaucoup de monde migre sur Jeedom. C'est quelque chose que Fibaro ne voit pas venir avec leur politique d'autistes. Si j'ai hacké la clé, je peux t'envoyer la procédure en privé, mais j'espère que tu maitrises Linux et la compilation de librairies. C'est pas vraiment simple àfaire.

Bon bah voilà c'est cool tout ça Et oui, tu vois finalement je n'étais pas le seul à être largué C'est chaud de bosser à 3 en même temps avec tous les messages croisés. Enfin on y est arrivé c'est l'essentiel. Je suis fatigué, au dodo

J'ai publié la version 1.10 en première page. J'espère qu'il n'y a pas d'erreur.

euh... quoi ? Mon test qui te semble étrange sert justement àéviter de tout éteindre