Lazer

Sujet fermé. Ici c'est la section "Nouveau ? Présentez-vous", inutile de préciser à quoi elle sert..... Pour les demandes de support, merci d'ouvrir un nouveau sujet sur la sous-section Support de la section concernée (dans le cas du FGR, c'est donc "Actionneurs & Ouvrants (Portail, volets...)")

De mieux en mieux, maintenant j'ai le message suivant qui apparait de temps en temps dans la fenêtre en haut de l'écran : [23:21:45] COMMAND_FIRMWARE_UPDATE MD STATUS_REPORT: NodeID: EDIT : je ne suis pas le seul, et personne ne lui a répondu : http://z-wave.ru/forum/fibaro-hc2/6108-rgbw-problemma-v-hc2.html

- On ne calcule qu'une seule fois le nombre d'éléments dans la table (opérateur # ) et on stocke dans une variable locale - Les boucles "for" par "incrément de 1" sont plus rapides qu'en utilisant "ipairs", lui-même plus rapide que "pairs" Bon après ça se joue à pas grand chose, faut vraiment faire du benchmark sur de très grosses boucles pour sentir la différence. Et même si le ipairs est un peu plus lent que l'incrément par 1, il permet d'alléger l'écriture, et donc la compréhension du code, donc ça a ses avantages quand même.

jojo, ma technique de "append" (que je n'ai pas inventé mais trouvé avec l'aide de mon ami Google...) permet d'ajouter un élément àun tableau existant, quand tu ne connais pas àquel indice tu en es. Je voulais juste partager une technique supplémentaire qui peut être utile dans certain cas (je l'utilise massivement dans Domocharts)

Bon bah moi qui suis toujours en v4.056 "stable", méchant plantage à l'instant..... alors que j'étais en train de jouer avec mon premier module RGBW et un ruban, et surtout en train de tester tous les programmes pré-enregistrés, tout d'un coup plus rien : le module ne semble plus répondre. Puis je me rend compte que plus aucun ordre Z-Wave ne passe, ni en émission, ni en réception. Détecteurs de mouvements, Dimmers, plus rien Je débranche le module RGBW, en vain. Je me connecte en SSH, dans les logs du moteur Z-Wave, les messages stoppés nets depuis 2 minutes..... donc je redémarre tous les services, et c'est pas mieux Inquiet, je reboote la box..... je me reconnecte à l'interface pas mieux Madame passe par là , et j'ai le droit à la remarque "mais pourquoi les lumières ne s'allument plus" (ah, en fin de compte elle y a pris gout puisqu'elle disait que ça ne servait à rien ) Là je suis en train de m'inquiéter pour la longue nuit à venir.... Et 2 minutes plus tard, en attendant sans rien faire, tout refonctionne J'ai rien compris.....

Et pourtant.... le plus performant c'est ça : local elements = #table for i = 1, elements do fibaro:debug(table[i][1] .. " - " .. table[i][2]) end

Il y a ça aussi pour ajouter des nouvelles lignes àune table existante, qui pourrait s'appeler table.append() : datas[#datas+1] = {} datas[#datas].id = 1 datas[#datas].name = 'toto' datas[#datas].value = 127

oui voilà

Bon du coup j'ai fusionné les sujets latoupie C'est plus simple pour suivre

à tout les coups, tu as le problème dont je parlais : les 2 codes essayent d'accéder à la variable en même temps. Dans la scène Domocharts, j'attends la minute pleine (00 seconde). Mais je ne comprends pas pourquoi tu fais de même dans ta scène compteur. Il suffit qu'elle tourne en permanence, et elle a juste besoin d'incrémenter éternellement les variables globales.....

@jojo : bravo ! @kioneoranga : attendre la prochaine version.....

Excellent ta modif de domocharts, c'est exactement comme ça que je comptais procéder J'ai pas lu en détail le code de ta scène compteur, mais ça me semble correct. Pour le décalage, comme expliqué sur l'autre topic, il est inévitable, même avec setTimeout. Si tu mets cette instruction en début de fonction, ce qui n'est pas ton cas car tu l'as mis à la fin. Mais la bonne solution, c'est de calculer le décalage et de compenser en ajustant la valeur du timeout.

Oui j'avais remarqué depuis le début que la scène se décale.... comme expliqué sur l'autre topic, à chaque tout, il y a les quelques millisecondes des instructions, plus le sleep(60000). Le setTimeout améliorerait un peu les choses, mais pas totalement, il y aura forcément un décalage également. La seule solution viable, est très simple : il faut calcul le décalage, et le compenser à chaque tour. Ca fait longtemps que je me dis qu'il faut que je modifie ma scène, mais je ne l'ai jamais fait.....

Tu as un plugin jeedom pour les Bose ?

Clairement, mettre la box dans une cabane au fond du jardin est une belle connerie, si tu me pardonnes l'expression. Il est évident que la box doit être au centre de l'installation, donc dans ton cas dans la maison. Comme souligné, je pense que c'est une méconnaissance du fonctionnement du Z-Wave de ta part, et que tu ne t'es pas posé les bonnes questions avant de te lancer dans l'installation. Mais rien de grave, tu as juste à déplacer la box, et le maillage réseau se reconstruira. Mettre des modules en hauteur sous les combles est effectivement une très bonne solution pour arroser idéalement le jardin. Bon après c'est sur que 60 mètres de distance, c'est pas gagné.... Dans ces cas là , typiquement la cabane au fond du jardin ou près de la piscine, il pourrait être judicieux d'installer une seconde box, telle qu'une HC Lite, configurée en mode passerelle de la box HC2 principale. Dans ce mode, tu as 2 réseaux Z-Wave distincts, chacun couvrant géographiquement son environnement immédiat. Grâce au mode passerelle, tous les modules sont vus par la HC2 maitre, donc tu peux centraliser totalement tes scénarios. Le seul pré-requis étant d'avoir un lien réseau IP entre les 2 box, donc il faut tirer un câble RJ45. Au pire, du CPL entre la maison et la cabane, et le tour est joué, pas besoin de gigabit pour cet usage. Enfin dans ton envie de changer de box domotique, je ne pense pas que ça soit une bonne idée.... Quand j'entends les retours à droite et à gauche sur les autres contrôleurs Z-Wave, je me dis que la HC2 est de loin la plus stable. Même les box qui ont bonne presse comme eedomus ou Jeedom semblent avoir pas mal de souci du coté du moteur Z-Wave. Tandis que la HC2, même si elle a des soucis du coté des bugs dans l'interface (dont on n'arrête pas de râler sur ce forum), il faut bien reconnaitre que le moteur Z-Wave est ultra stable, depuis la v4. C'est bien simple, depuis Mai 2015 que je suis passé sur la v4, je n'ai pas eu un seul noeud mort, ni aucune commande Z-Wave manquée. Donc difficile de dire si le répéteur Aeon Labs est réellement supporté ou pas par la HC2, mais on s'en passe très bien pour peu que le réseau soit intelligemment installé : box au centre de l'installation, et suffisament de modules répartis pour un maillage correct du réseau.

Je pense aussi que le prochain Sonos remplacé sera le Play 3. Je suis bien d'accord avec les Numériques, ça serait pas mal des commandes locales sur les enceintes..... malheureusement c'est un peu la tendance des objets connectés (Netatmo en tête) => le produit est inutilisable sans un smartphone à coté.

Je sais pas trop.... Juste un conseil, pour utiliser correctement les ports du CD et eSata externe, il faut le BIOS moddé avec les paramètres qui vont bien pour activer l'AHCI. Pas sur que ça soit ça ton problème, c'est juste une piste... Édit : valable pour le G7 uniquement.

J'ai noté la remise àzero dans ma todolist, mais ne soit pas pressé...

moi ce qui me gêne si tu gère toi même la remise à 0 de la variable, comment tu peux être sur que Domocharts sera synchronisé ? Je pense qu'en pratique tu vas perdre des tours. => c'est pour ça que je suggérais d'ajouter les instructions nécessaires au VD Domocharts pour qu'il remette ta variable à 0 juste après sa lecture. Le seul risque est que ta scène incrémente la variable pile entre le moment où le VD Domocharts lis la variable puis la remet à zero, mais le risque est faible, et je ne vois aucun moyen de résoudre ce problème sachant qu'on n'a pas de gestion des mutex (concept de programmation multi-thread) En plus de ton problème de sleep, car ta boucle met plus d'une seconde à s’exécuter (1s de sleep, plus quelques ms pour toutes les autres instructions) => le settimeout améliorerait beaucoup les choses

J'ai remarqué que ce n'était pas une bonne idée de faire des sleeps dans une scène quand tu introduits la notion d'asynchronisme avec net.HTTPClient(). En effet, la scène ne rend jamais la main au système, et les fonctions asynchrones ne démarrent jamais..... sauf quand le programme finit par se terminer, or avec ton "while true do" tu risques d'attendre longtemps. Donc il faut que tu revois entièrement la logique de ta scène pour permettre aux appels à net.HTTPClient() de s'exécuter. Pour cela, il faut remplacer tes sleeps tous les matins par des appels à setTimeout(), donc à des fonctions. C'est pour cela que ça t'oblige à revoir toute la structure du code. Regarde mon watchdog pour voir comment j'ai traité le problème : - le code ne se compose que de fonctions... - ... sauf à la fin, moins de 10 lignes de codes sont exécutés linéairement, puis le programme se termine - dans ces lignes, il y a un appel setTimeout(function() Check(intervalle) end, delay*1000) - donc tu cherches plus haut la fonction Check(interval) - dans cette fonction, tu vois toutes les instructions exécutées, y compris des appels à net.HTTPClient() - à la fin de la fonction Check(), on trouve l'appel suivant pour que la fonction se rappelle elle-même en asynchrone après un délai : setTimeout(function() Check(interval) end, interval*1000) - au moment où le timeout démarre, le système reprend la main, et les instructions httpClient:request précédentes qui étaient en attente peuvent démarrer Ce mécanisme d'appel de fonction récursif par l'intermédiaire du timeout est l'équivalent asynchrone d'un bon vieux "while true .... sleep() do"

Oui c'est la norme NF je crois qui l'impose. Mais évidemment, nos médias n'ont communiqué que sur l'obligation d'avoir un détecteur aux normes en mars 2015, mais pas de ce que ça impliquait (qu'il faut changer les piles, vérifier le bon fonctionnement du détecteur, etc...) Même le NEST a cette indication.

Punaise, presque le même titre que le tien, combiné avec ta première phrase : Rien À Voir Avec La Domotique : Les Adoucisseurs D'eau

Oui bien sur, je vois que Monsieur est connaisseur Mon code ne te sera d'aucune utilité, car j'interroge l'API HTTP LanBrowser de la Freebox (documentée ici), comme le fait déjà Krikroff dans ce Virtual Device pour les autres API. C'est ultra spécifique, et développé en interne par Free pour sa propre box, rien de plus. Toi tu vas avoir un challenge supplémentaire à surmonter : écrite la logique en LUA pour faire du Telnet (tu peux déjà oublier le SSH) sur le switch.

@PITP2 je connaissais une façon similaire de le dire : "je n'ai pas les moyens d'acheter le moins cher" J'ajoute que je ne suis jamais partisan de brancher des chinoiseries sur le 230V.... quand on voit que les modules Fibaro qui respectent les normes EU ont tendance à cramer, je vous laisser imaginer une chinoiserie sans aucune certification.... Déjà certaines alimentations qu'on reçoit avec des produits plus ou moins onéreux c'est limite, mais alors là ces modules contrefaits c'est clairement des produits de mauvaise qualité.

Je voudrais apporter mon expérience du jour par rapport à ce qui a été dit (et inscrit en première page du coup) : si le module n'est pas breached, et que la pile est morte, on peut quand même récupérer son FGK-101 pleinement fonctionnel sans passer par l'exclusion/inclusion. Voici ma méthode : - le module n'a plus de pile depuis 6 mois (ouais je sais, j'ai trainé....), donc il est bel et bien marqué comme nÅ“ud mort dans l'interface web. - le module FGK-101 en question est en version 2.1 (je précise cette info car j'ai reçu depuis un module plus récent en 2.5, donc le comportement peut avoir changé), et HC2 en v4.056 - dans l'interface HC2, je marque le module comme désactivé dans l'onglet Avancé (à faire pour les 2 modules : le détecteur lui-même, et son parent) - ouverture du capot du module, retrait de la pile déchargée, installation d'une nouvelle pile. Durant quelques secondes, le module est alors éveillé et prêt à répondre aux ordres du contrôleur Z-Wave - dans l'interface HC2 : réveil du module (en cliquant sur son icône barrée d'une croix), alors la communication s’établit bien - dans l'interface HC2 : ré-activation des 2 modules (le détecteur et son parent) - quelques tests avec le module, son état change immédiatement dans l'interface du HC2. - tout semble bien aller, sauf... que la box indique toujours la pile comme étant défectueuse : icône rouge qui clignote et API qui signale batteryLevel=255 - dans l'onglet Avancé du détecteur, je clique alors sur le bouton "Recharger les paramètres". Et là c'est magique, l'état de la batterie est bien lu. L'icône rouge disparait, l'API est bien mise à jour également, et tous les paramètres personnalisés du modules sont bien là , y compris l'intervalle de réveil que j'allonge toujours pour augmenter la durée de vie de la pile. Et surtout, je reçois des 10zaines de notifications GEA, car les triggers basés sur l'ID de ce module refonctionnent immédiatement (et oui, même l'ID est conservé, c'est pas beau ça )