Lazer

OK merci pour l'information. Est-ce qu'il y a une autre fonction pour voir les voisins des modules ? Cela permettrait de créer une table de routage du réseau.

oui pareil les fonctions me suffisent, après il suffit de se coder le truc en LUA. par contre, faut bien que le panneau de diagnostique Z-Wave serve à quelque chose un jour, donc c'est à Fibaro de présenter les données joliment sur ledit panneau. Surtout pour une box qui met autant l'accent sur le visuel......

moi je trouve ça sympa, et j'espère que ça ne s'arrêtera pas àcette fonction, mais qu'on aura un vrai graphique et/ou tableau (comme ils font déjàtous chez eedomus, zibase, jeedom...)

bah vu que y'a pas les plugins, et qu'on n'aura jamais les templates Qubino, tu veux que ça soit quoi d'autre ? ça ne m'étonne pas, et ça peut être utile pour optimiser une installation qui n'a pas suffisamment de modules, ou si tu as un module éloigné àl'autre bout du jardin.

Bon je crois bien que les nouvelles fonctions annoncées seront liées au diagnostique du réseau Z-Wave.... local devicetotest = xxx local loops = 2 fibaro:call(devicetotest, "rangeTestStart", loops) et : fibaro:call(devicetotest, "rangeTestStop") Source : http://www.domotique-fibaro.fr/index.php/topic/9243-test-z-wave-range/

"rangeTestStart" looks like an hidden command. And you are running an unavailable alpha version. It seem's that you know the HC2 internals better than us

What kind of server to you have for your database ? I have a lot of devices, and my database is less than 200MB, I have very good performances when extracting data. I am running on a Web shared hosting. Your server may have very very low performances.

ouh làlà, la complexité ce n'est pas la fonction string àutiliser, mais ce que tu mets dedans : des expressions régulières. Je ne suis pas spécialiste des regex..... làtu ne te lances pas dans l'aspect le plus simple de la programmation

Non, c'est tout à fait normal. Parce que quand tu fais un telnet à la main, ce que tu vois à l'écran n'est pas ce que tu tapes à l'écran, mais ce que le switch t'envoie. Autrement dit, le switch te fait un retour visuel d'absolument tous les caractères que tu tapes. Quand je disais page précédente que le telnet est le protocole le plus basique qui soit, où chaque caractère est transmis tel quel dans la trame TCP, tu dois maintenant commencer à comprendre.... Donc il faut que ton script LUA tienne compte des caractères qu'il a envoyé, afin de ne pas en tenir compte dans la réponse.

héhé, mettre le code dans une fonction et les commandes dans un tableau, c'était l'étape suivante que j'allais te proposer, tu m'as devancé

A ma connaissance, c'est du "on dit", information obtenue par un revendeur bien informé. Je n'ai pas fouillé le forum pour aller voir.

Sorry, it is not possible to exclude specific devices from being collected wihin the virtual device. The only way to exclude devices is to hide them in the graphical interface.... But you won't be able to see them anymore in your GUI.

Voilà tu as tout compris Tu vois qu'il y a encore un peu de boulot avant d'arriver à un script stable.... mais c'est faisable. Dans un premier temps, il sera impossible de traiter tous les cas d'erreur possible. Donc tu peux simplement arrêter l'exécution de ton script si tu n'obtiens pas la réponse que tu attends, et te déconnecter proprement. Ensuite, tu relances (par exemple avec GEA ou ce que tu veux) tout le processus jusqu'à obtenir l'action désirée (activation/désactivation du wifi)

ah désolé, j'avais pas fait attention à la 2nde version. En effet il y a bien les read(), mais ce qu'il manque c'est un string.match() pour vérifier que tu as bien la réponse attendue avant d'envoyer le write() suivant. Bref, faut que ton programme se comporte exactement de la même façon qu'un humain, qui attend d'avoir le prompt avant de donner une nouvelle instruction. Ca me tenterai bien d'écrire une classe LUA pour faire toute cela proprement (et surtout de façon générique, afin de faire du telnet sur n'importe quel équipement), mais je manque un peu de temps....

Bravo Si tu faisais des read(), tu pourrais attendre d'avoir le retour de ton équipement, et éviter de balancer les write() en aveugle. Donc ça te permettrai aussi de te déconnecter proprement à la fin. Parce que tel quel, même si ça fonctionne, c'est super crade. Et si tu rajoutes des sleep(), tu ne vas faire qu’expirer la "mocheté" du code Ne te prends pas la tête sur le setreadtimout(), laisse la valeur telle quelle ça devrait suffire (sauf si ton équipement est trop long à répondre, auquel cas il faut allonger le timeout)

Pas sûr qu'ils répondent, il n'y a jamais eu d'annonce officielle du développement d'un nouveau produit.....

ah ce n'est pas du CLI, ce sont des menus..... ils sont nuls chez Netgear Bon c'est pas grave, le principe est le même, il suffit d'enchainer les séquence de menu et tu arriveras au résultat voulu

Si tu as les commandes, dans les grandes lignes c'est facile depuis la HC2, car le telnet a l'avantage d'être un protocole en texte clair : ce que tu vois à l'écran, c'est ce qui est envoyé littéralement dans la trame TCP. Dans les grandes lignes, il faut que tu utilises les fonctions : Net.FTcpSocket() tcpSocket:setReadTimeout tcpSocket:write() tcpSocket:read() tcpSocket:disconnect() Il y a plusieurs exemples de cette fonction sur le forum (mon Network Monitor, certains modules de Krikroff (Sonos, Freebox, etc...)) Pour la logique, dans les grandes lignes : - lire le prompt - écrire le login - lire la demande de password - écrire le password - attendre le prompt - écrire la commande que tu as identifié pour activer et désactiver la Wifi - se déconnecter

OK, mais dans ce cas, ce ne sont pas les games qui ont le plus à gagner avec un SSD : - les jeux ont plus besoin de CPU+GPU que de SSD - les jeux sont tellement gros qu'ils ne tiennent pas sur un SSD... à moins d'avoir les moyens de se payer des SSD énormes Non, en grand public, le principal intérêt des SSD c'est pour l'OS. En pro, c'est pour la base de données.

avec les modules fantomes (ou fake device), tu ne peux avoir que des capteurs. Pour les volets, il faut les plugins. EDIT : et ça me serait bien utile pour gérer les lumières sur l'IPX800 également

Cette discussion tombe à pic, car je viens de récupérer une carte Fusion I/O 320 Go de flash sur bus PCI-Express x4 128000 IOPS Latence : 50 micro-secondes Débit max : 735Mo/s Ma seule crainte c'est la consommation par rapport à un SSD.... donc à tester avec un Wall Plug sur le serveur.

Tous les constructeurs rejoignen toutes les alliances. Cela leur permet d'avoir un pied dedans, pour voir ce qui se trame, et ne pas louper le cocher au cas où. Jusqu'à présent, le EnOcean, au delà de ses promesses marketing, n'a quasiment rien prouvé sur le terrain.... donc en l'état je vois mal Fibaro se lancer dedans (même si j'y croyais au départ). A mon avis, on aura une HC3 avec le support de Homekit avant d'avoir de l'EnOcean dedans. /boule de crystal

@mprinfo : oui je pense aussi que c'est le Store pour les Plugins qui a fait prendre du retard, je ne pense pas qu'ils veuillent laisser la fonctionnalité trop libre

Pareil sur Sebcbien pour EnOcean.... cette techno sera réellement intéressante quand ils auront fini leur fusion avec Zigbee. Et puis les quelques modules que j'ai fonctionnent très bien avec FHEM, finalement il faudrait les Plugins perso pour une intégration native. Donc même avis que Nico Les Plugins perso

Ce matin, je suis parti au boulot, 5 minutes après le robot aspirateur s'est déclenché et a commencé le ménage. Ce soir je vais rentrer. - Qu'est-ce que tu as fait aujourd'hui chéri ? - J'ai fait le ménage - ... Finalement la domotique ça a du bon..... le jardin attendra