Fly Posté(e) le 8 août 2021 Signaler Partager Posté(e) le 8 août 2021 Bonjour, Je débute totalement, et je vais repartir de la base, j'ai des milliers de questions, mais je pense qu'il faut aller par étape. Je me rends compte que je ne dois pas avoir réalisé certains paramétrages correctement. 1- Je comprends que chaque module physique peut avoir plusieurs fonctions (endpoint) et chaque fonction correspond à un module dans l'interface Fibaro : un parent (qui désigne le module physique), et des enfants (qui désignent les différentes fonctions). Normalement la plupart doivent être cachés dans l'interface car on ne s'en sert pas, de sorte à ne rendre visible que celui qui est utile. Mais comment savoir lequel est caché, et lequel ne l'est pas ???? Si je prends pour exemple mes volets roulants: Il y a le 53 module physique, et les endpoint 53.0, Volet 1, Volet Ch. Parents (c'est moi qui avait renommé celui-ci), et 53.2 Lequel doit être masqué, lequel doit être affiché ? Si je me fie à l'interface ENERGY, je vois: J'aurais donc tendance à dire que c'est le 53.0 que je dois afficher et que je dois renommer... Mais du coup, je vais perdre toutes mes scènes (bloc) et d'autres soucis sont à prévoir ? Merci bien, Fly Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 8 août 2021 Signaler Partager Posté(e) le 8 août 2021 Normalement, après l'inclusion, la HC3 cache automatiquement ceux qui sont inutiles. Si tu as un doute sur le module enfant à utiliser, c'est simple : tu agis avec les interrupteurs sur le module (ce qui va ouvrir/ferme le volet), et tu constates sur l'interface Web quel est l’icône qui a changé d'état => Alors tu sais que c'est ce module-là que tu dois conserver dans ton interface, et cacher tous les autres (mais encore une fois, normalement par défaut, les autres sont déjà cachés) Il y a une exception, c'est la télécommande, qui est affichée par défaut car elle permet de faire des scénarios simples en mode graphique. Perso je ne m'en sert pas, donc je cache systématiquement le module enfant de cette télécommande. Pour cacher un module, c'est simple, il y a une case à cocher dans les propriétés avancées de chaque module : Si tu ne vois pas les modules cachés, il y a une case à cocher en haut à droite (décochée par défaut) : En complément, on voit le parent et tous ses enfants dans l'onglet Général : Perso j'ai pris pour habitude de nommer le module parent avec la référence du produit, donc FGD-212 dans le cas présent. Sur cette capture d'écran, on voit bien mon module enfant principal qui contrôle la Lumière, puisqu'il s'appelle ainsi. D'ailleurs c'est le seul qui est visible dans l'interface, tous les autres sont cachés (et portent encore leur nom par défaut, je ne les ai pas renommés, pas besoin) Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fly Posté(e) le 9 août 2021 Auteur Signaler Partager Posté(e) le 9 août 2021 Il y a 16 heures, Lazer a dit : Normalement, après l'inclusion, la HC3 cache automatiquement ceux qui sont inutiles. Bonjour @Lazer merci pour ta réponse, mais je te confirme que dans mon cas, hélas, la HC3 n'a rien caché du tout, j'avais bien tous les items (avant que je n'en cache certains): J'ai caché les items que je pensais nécessaire à cacher et sur conseils de l'installateur (pro) présent, qui avait déjà enregistré tous les modules dans la HC3 quand tout est arrivé. Nous avons choisi de ne garder que "Role Roller Shutter 3". Il y a 16 heures, Lazer a dit : Si tu as un doute sur le module enfant à utiliser, c'est simple : tu agis avec les interrupteurs sur le module (ce qui va ouvrir/ferme le volet), et tu constates sur l'interface Web quel est l’icône qui a changé d'état => Alors tu sais que c'est ce module-là que tu dois conserver dans ton interface, et cacher tous les autres (mais encore une fois, normalement par défaut, les autres sont déjà cachés) Toujours dans le cadre de ma cuisine, j'ai appliqué ta méthode. C'est bien le ID66 qui change ("icône" avec volet ouvert ou fermé) quand j'appuie sur le bouton physique. Par contre si j'appuie sur l'icône du ID64, ça ouvre et ferme le volet, et ça met à jour l'icône #64 (mais pas #66). Du coup, j'en conclue que j'ai bien fait de cacher ID#63-64-65-67 et ne laisser que le ID#66 affiché: Mais par contre, j'ai toujours la mauvais info affichée sur le panneau "energy": 63.0 --> pourquoi ? Il y a 17 heures, Lazer a dit : Perso j'ai pris pour habitude de nommer le module parent avec la référence du produit, donc FGD-212 dans le cas présent. Merci beaucoup, je vais le faire, excellente idée, pour cela il faut que je retrouve les cartons au garage, car sur la facture, il n'y a que "module relais" et rien de plus, je dois chercher la référence exacte. J'ai 3 capteurs motion, 7 Roller Shutter 3 et 3 binary switch 2. Ma question #2 porte sur le scénario pour allumer une lumière quand on entre dans une pièce, et l'éteindre quand on en sort. J'ai trouvé comment faire, ça fonctionne mais si je reste dans la pièce sans bouger quelques secondes, la lumière s'éteint immédiatement. Je voudrais: - capteur détecte --> Lumière ON - Timer 30 secondes - si capteur détecte dans ce laps de temps, on relance le timer - capteur "safe" --> Lumière OFF Je n'ai pas réussi à le faire en BLOCK, j'ai tenté en LUA mais n'ai pas réussi, la seule solution que j'ai trouvé est de changer le paramètre #6 du capteur Motion pour le mettre à 30s. Là ça fonctionne comme je le souhaite. Est-ce la meilleure façon de réaliser cela ? Ma 3ème question portera sur le LUA car j'ai de gros soucis là-dessus, je fais un script qui fonctionne, et dès que j'y introduis des commentaires (-- ceci est un commentaire), le script ne fonctionne plus et je dois en refaire un... :-((( Mais allons y étape par étape car c'est pas très simple tout cela... Merci encore pour votre aide, Fly Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 9 août 2021 Signaler Partager Posté(e) le 9 août 2021 il y a une heure, Fly a dit : Mais par contre, j'ai toujours la mauvais info affichée sur le panneau "energy": 63.0 --> pourquoi ? Je ne sais pas... il y a une heure, Fly a dit : Ma question #2 porte sur le scénario pour allumer une lumière quand on entre dans une pièce, et l'éteindre quand on en sort. Je ne saurais pas te répondre, je n'utilise aucun scénario en mode bloc, j'utilise exclusivement GEA pour tous mes scénarios. Si tu ne connais pas GEA, c'est un script dispo sur le forum pour gérer des scénarios, du plus simple au plus complexe. Pas évident à prendre en main, mais ça permet de tout faire sans connaitre LUA, donc assez pratique au final. Mais si quelqu'un utilise le mode bloc, il saura peut être te répondre. il y a une heure, Fly a dit : Ma 3ème question portera sur le LUA car j'ai de gros soucis là-dessus, je fais un script qui fonctionne, et dès que j'y introduis des commentaires (-- ceci est un commentaire), le script ne fonctionne plus et je dois en refaire un... :-((( Alors là, il faudra partager ton code, et préciser si tu le fais tourner dans un QuickApp ou une Scène, le comportement est assez différent. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fredmas Posté(e) le 9 août 2021 Signaler Partager Posté(e) le 9 août 2021 (modifié) Il y a 2 heures, Fly a dit : Mais par contre, j'ai toujours la mauvais info affichée sur le panneau "energy": 63.0 --> pourquoi ? il y a une heure, Lazer a dit : Je ne sais pas... Moi non plus et en plus j'ai désactivé cette remontée d'infos d'énergie sur mes Roller 2, donc je ne peux pas t'aider en vérifiant... Il y a 2 heures, Fly a dit : Ma question #2 porte sur le scénario pour allumer une lumière quand on entre dans une pièce, et l'éteindre quand on en sort. J'ai trouvé comment faire, ça fonctionne mais si je reste dans la pièce sans bouger quelques secondes, la lumière s'éteint immédiatement. Je voudrais: - capteur détecte --> Lumière ON - Timer 30 secondes - si capteur détecte dans ce laps de temps, on relance le timer - capteur "safe" --> Lumière OFF Je n'ai pas réussi à le faire en BLOCK, j'ai tenté en LUA mais n'ai pas réussi, la seule solution que j'ai trouvé est de changer le paramètre #6 du capteur Motion pour le mettre à 30s. Là ça fonctionne comme je le souhaite. Est-ce la meilleure façon de réaliser cela ? il y a une heure, Lazer a dit : Je ne saurais pas te répondre, je n'utilise aucun scénario en mode bloc, j'utilise exclusivement GEA pour tous mes scénarios. Si tu ne connais pas GEA, c'est un script dispo sur le forum pour gérer des scénarios, du plus simple au plus complexe. Pas évident à prendre en main, mais ça permet de tout faire sans connaitre LUA, donc assez pratique au final. Mais si quelqu'un utilise le mode bloc, il saura peut être te répondre. Je n'utilise plus le mode bloc depuis que j'ai quitté la HCL pour la version du 3. Désormais tout en LUA, et petit à petit je réduis le nombre des scènes en faveur de QA. Quoiqu'il en soit, je dois installer un FGMS-001 dans les jours/semaines pour allumer systématiquement un escalier fermé et sans fenêtre (exemple proche du tien du coup). Et même si de mon côté ce sera fait en LUA dans une scène ou dans un QA, si personne ne t'a donné la réponse entre temps j'essaierai de faire des essais en mode bloc pour essayer de t'aider. Mais comme tu l'as compris, ce ne sera pas tout de suite. En attendant, ton paramètre 6 doit répondre apparemment à ton besoin, mais sur un laps de temps prédéfini et donc ne couvrira pas tous les cas de vie. A mon avis le mieux est donc de le maitriser dans ton code, que tu restes dans la pièce durant 2s ou 2min, afin de surveiller les détections, lumière allumée ou pas. Il y a 2 heures, Fly a dit : Ma 3ème question portera sur le LUA car j'ai de gros soucis là-dessus, je fais un script qui fonctionne, et dès que j'y introduis des commentaires (-- ceci est un commentaire), le script ne fonctionne plus et je dois en refaire un... :-((( Mais allons y étape par étape car c'est pas très simple tout cela... il y a une heure, Lazer a dit : Alors là, il faudra partager ton code, et préciser si tu le fais tourner dans un QuickApp ou une Scène, le comportement est assez différent. Pareil, car il n'y a pas de raison que si tu écris des commentaires avec les 2 "--" ça ne fonctionne pas Exemple : -- Dessous un exemple de print avec commentaire print("cette fonction affiche du texte dans la console") -- ligne de code pour afficher du texte dans la console Modifié le 9 août 2021 par Fredmas Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fly Posté(e) le 9 août 2021 Auteur Signaler Partager Posté(e) le 9 août 2021 (modifié) Hello, Merci déjà pour ces réponses, et je suis prêt à me lancer dans LUA ou GEA, mais le souci c'est que je rame avec cela pour le moment... En effet, je me suis lancé, et voici mon code: La condition qui est purement de type alarme, si le capteur de mouvement voit quelque chose. { conditions = { { id = 1, isTrigger = true, operator = "==", property = "breached", type = "alarm", value = true } }, operator = "all" } Et la partie Actions: -- Alerte sur iPhone fibaro.alert('simplePush', {[1] = 104, }, '!! INTRUSION ENTRÉE !!', false) -- On allume la lumière entrée fibaro.call(41, 'turnOn') -- On bouge les volets SAM, Cuisine, Salon, Chambre à 60 pourcent fibaro.call({[1] = 71, [2] = 86, [3] = 66, [4] = 76, }, 'setValue', 60) -- On allume la lumière SAM, Cuisine, Salon, Canapé et Cinéma à 100 pourcent fibaro.call({[1] = 108, [2] = 110, [3] = 111, [4] = 115, [5] = 117, }, 'setValue', 100) -- Réglage en Rouge fibaro.setTimeout(500, function() fibaro.callUI(115, 'onChanged', 'sldHue', 0) fibaro.callUI(115, 'onChanged', 'sldSaturation', 100) fibaro.setTimeout(500, function() fibaro.callUI(117, 'onChanged', 'sldHue', 0) fibaro.callUI(117, 'onChanged', 'sldSaturation', 100) fibaro.setTimeout(500, function() fibaro.callUI(111, 'onChanged', 'sldHue', 0) fibaro.callUI(111, 'onChanged', 'sldSaturation', 100) fibaro.setTimeout(500, function() fibaro.callUI(110, 'onChanged', 'sldHue', 0) fibaro.callUI(110, 'onChanged', 'sldSaturation', 100) fibaro.setTimeout(500, function() fibaro.callUI(108, 'onChanged', 'sldHue', 0) fibaro.callUI(108, 'onChanged', 'sldSaturation', 100) end) end) end) end) end) Si je lance, RIEN ne se passe... :-( J'ai tout essayé, de supprimer les timeout, de ne laisser que : fibaro.call(41, 'turnOn') fibaro.call({[1] = 71, [2] = 86, [3] = 66, [4] = 76, }, 'setValue', 60) fibaro.call({[1] = 108, [2] = 110, [3] = 111, [4] = 115, [5] = 117, }, 'setValue', 100) Ça ne marche pas non plus... Il n'y a que la ligne 1 seule qui fonctionne (si elle est toute seule)... Modifié le 9 août 2021 par Fly Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 9 août 2021 Signaler Partager Posté(e) le 9 août 2021 Je ne pense pas que tes syntaxes de fibaro.call avec plusieurs id dans une table soient correctes. En tout cas je n'ai jamais vu ça. Tu peux soit les décomposer en autant de ligne qu'il y a d'ID... mais c'est un peu fastidieux. Ou bien faire une petite boucle : local IDs = {71, 86, 66, 76} for _, id in ipairs(IDs) do fibaro.call(id, 'setValue', 60) end Sinon il y a peut être moyen avec fibaro.callGroupAction() mais la syntaxe est un peu particulière, car elle permet de filtrer sur les modules existants : https://manuals.fibaro.com/home-center-3-lua-scenes/ Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sowliny Posté(e) le 10 août 2021 Signaler Partager Posté(e) le 10 août 2021 (modifié) Bonjour et bienvenue ! En ce qui concerne la condition, elle me semble trop "étoffée". Dans le cas d'un condition unique, on peut omettre "operator" et "conditions" (ce qui simplifie l'écriture, surtout lorsque l'on débute) Ce qui nous donne : { type = "device", id = nn, property = "value", operator = "==", value = true, isTrigger = true } J'utilisais cette syntaxe pour mes FGMS au début, avant que je ne crée des conditions plus complexes (avec juste "property = value", étant donné que "id" correspond au numéro du module enfant "Motion Sensor"). Mais je suis peut-être dans l'erreur en n'utilisant pas "property = breached"... Modifié le 10 août 2021 par Sowliny Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sowliny Posté(e) le 10 août 2021 Signaler Partager Posté(e) le 10 août 2021 PS : perso, tous mes identifiants de modules sont inscrits dans des variable globales (de même que les délais, les seuils, certaines heures de déclenchements...). Solution qui permet de ne pas réécrire les scènes à chaque fois que l'Id change : réinitialisation "hard" du module, échange de module, etc... Mais on ne peut pas les utiliser dans les scenes "bloc". Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fredmas Posté(e) le 10 août 2021 Signaler Partager Posté(e) le 10 août 2021 Bien que je comprenne la raison de fonctionner comme ça, cette dernière remarque me fait me poser une question technique (pour les pro du HW ). Pour en avoir déjà discuté, il est clair que d'un point de vue général l'écriture dans la DB utilise et use la mémoire flash. Mais quid de la simple lecture en gérant les identifiants comme décrit ci-dessus ? Ca me questionne uniquement au niveau de l'usure de la mémoire, pas au niveau des autres désavantages d'utilisation de la DB comme par exemple les temps de réaction Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 10 août 2021 Signaler Partager Posté(e) le 10 août 2021 La lecture n'use pas la Flash En ce qui concerne les opérations de lecture/écriture, que ça soit dans une variable globale, une variable de QA ou de scène, une propriété d'un module, etc... au final ça ne change pas grand chose, ça arrive toujours dans la même DB, donc l'usure est sensiblement identique. Reste les questions d'organisation, où stocker la donnée, chacun fait comme il veut. Cela dit, un script (QA ou scène, peu importe), qui va lire des données dans une variable (globale/QA/Scène) à chaque passage de boucle, ira chercher dans la DB, donc c'est plus lent et consommateur de CPU. Probablement sans impact dans la majorité des cas. Mais sur un système chargé, avec une boucle un peu trop agressive (par exemple chaque seconde), l'impact sur les performances deviendra sensible. A l'inverse, un tableau défini au début du code LUA, comme dans l'exemple donné plus haut sur cette page, sera infiniment plus rapide, car ce tableau, une fois chargé en RAM lors du démarrage de la scène/QA, va y rester, donc accessible par le processeur en quelques nanosecondes. Donc pour résumer, si vous souhaitez utiliser souvent une donnée, elle doit rester dans la mémoire du script LUA. Dans ce cas, le script qui exploite une variable "externe", pourra aller la lire une première fois dans la DB au moment au démarrage du script, puis la conserver dans une variable dans le code LUA. Ainsi la donnée reste en RAM, et on n'a plus de problème de performance. Si vous regardez tous mes QuickApps que j'ai partagé sur le forum, c'est ce qui se passe : les variables du QA sont chargées en RAM au démarrage (dans onInit()), puis elles y restent. Bref, la lecture n'est pas un problème d'usure de la mémoire Flash, mais de performance. 1 Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fredmas Posté(e) le 10 août 2021 Signaler Partager Posté(e) le 10 août 2021 il y a 51 minutes, Lazer a dit : La lecture n'use pas la Flash (...) Bref, la lecture n'est pas un problème d'usure de la mémoire Flash, mais de performance. Merci @Lazer Même si j'ai eu le doute, c'est bien ce que je pensais et je ne me suis pas trop trompé pour une fois, comme quoi tout arrive à force Par contre cela étant dit, pour faire suite à notre discussion précédente à propos des QA et des variables il y a 2 semaines, comme je suis en train de "virer" un maximum de chose en DB, je vais réfléchir/m'inspirer de ta proposition que j'ai résumé ainsi (...) dans la citation précédente, et probablement récupérer (ce n'était pas encore prévu) mes ID en début de QA dans des variables locales pour le reste du code et en faciliter la maintenance en cas de changement d'ID ultérieurs... comme un potentiel passage en moteur 3.0 un jour en 2023 par exemple Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 10 août 2021 Signaler Partager Posté(e) le 10 août 2021 Oui centraliser les ID des modules quelques part est une bonne approche. Perso c'est un peu différent, car 99% de mes scénarios sont ensemble : dans GEA. Du coup c'est une simple table LUA au début du script qu'il me suffit de maintenir à jour, juste avant le long listing des différentes règles. Les rares exceptions en fin de compte, c'est une scène Alarme, qui est autonome, et fait clignoter les éclairages et envoie des snapshots des caméras. Là les ID sont aussi codée en dur dans une tableau LUA au début de la scène. Ainsi elle reste le plus légère possible et fonctionne en toute circonstance sans dépendre d'une variable globale externe. Et puis de toute façon, les ID de mes éclairages ne changent jamais. Comme tu dis, le jour où on passe sur le moteur Z-Wave v3 et que les ID changent, je n'aurai que 2 endroits à modifier, très simple. Exactement ccomme ce qui s'est passé quand j'ai basculé de HC2 à HC3, la bascule a été très simple (c'était la réécriture préalable des QA qui a été longue) Lien vers le commentaire Partager sur d’autres sites More sharing options...
Cardane Posté(e) le 10 août 2021 Signaler Partager Posté(e) le 10 août 2021 il y a d'ailleurs toujours cette scène disponible sur le forum qui permet de générer la table d'ID à mettre en début de GEA.... elle tourne très bien sur HC3 Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fly Posté(e) le 10 août 2021 Auteur Signaler Partager Posté(e) le 10 août 2021 J’ai du me tromper d’endroit ou de sujet pour me faire aider en tant que novice :-(((( Lien vers le commentaire Partager sur d’autres sites More sharing options...
Cardane Posté(e) le 10 août 2021 Signaler Partager Posté(e) le 10 août 2021 il y a une heure, Fly a dit : J’ai du me tromper d’endroit ou de sujet pour me faire aider en tant que novice :-(((( quel est le problème ? tu as eu une réponse à ta question ci-dessus, faut juste essayer ... Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 13 août 2021 Signaler Partager Posté(e) le 13 août 2021 Le 09/08/2021 à 13:51, Fly a dit : Mais par contre, j'ai toujours la mauvais info affichée sur le panneau "energy": 63.0 --> pourquoi ? Je viens de voir que le problème a été remonté sur le forum officiel. Pas de réponse pour l'instant, mais vu que le panneau d'énergie est tout nouveau, comporte encore pas mal de bugs, et qu'il est amené à évoluer, j'imagine qu'ils vont corriger ça prochainement : https://forum.fibaro.com/topic/55131-new-energy-pannel-explanations-please/?do=findComment&comment=234713 Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fly Posté(e) le 16 août 2021 Auteur Signaler Partager Posté(e) le 16 août 2021 Le 13/08/2021 à 19:09, Lazer a dit : Je viens de voir que le problème a été remonté sur le forum officiel. Pas de réponse pour l'instant, mais vu que le panneau d'énergie est tout nouveau, comporte encore pas mal de bugs, et qu'il est amené à évoluer, j'imagine qu'ils vont corriger ça prochainement Merci pour l'info. Le 11/08/2021 à 00:15, Cardane a dit : quel est le problème ? tu as eu une réponse à ta question ci-dessus, faut juste essayer ... J'en suis à des dizaines et des dizaines de test, tous avec échecs, j'espérais avoir des solutions mais les réponses qui me sont fournies ne sont pas de mon niveau, je suis désolé. Je m'explique: Le 09/08/2021 à 15:18, Lazer a dit : Si tu ne connais pas GEA, c'est un script dispo sur le forum pour gérer des scénarios, du plus simple au plus complexe. Pas évident à prendre en main, mais ça permet de tout faire sans connaitre LUA, donc assez pratique au final. Je ne connais absolument pas GEA, je pensais pouvoir faire avec les outils par défaut de la box, le LUA doit bien pouvoir faire tout cela simplement, diable !! Le 09/08/2021 à 21:21, Lazer a dit : Je ne pense pas que tes syntaxes de fibaro.call avec plusieurs id dans une table soient correctes. En tout cas je n'ai jamais vu ça. J'ai simplement fait fermer 2 volets en mode BLOCK, puis j'ai transformé le mode BLOCK en LUA, et la syntaxe m'a été fournie par la Fibaro elle-même. Le 10/08/2021 à 10:37, Sowliny a dit : Ce qui nous donne : { type = "device", id = nn, property = "value", operator = "==", value = true, isTrigger = true } Je ne comprends pas bien où je devrais mettre cela, à la place de quelle ligne ? Navré, mais je débute vraiment... Le 10/08/2021 à 10:47, Sowliny a dit : PS : perso, tous mes identifiants de modules sont inscrits dans des variable globales (de même que les délais, les seuils, certaines heures de déclenchements...). Solution qui permet de ne pas réécrire les scènes à chaque fois que l'Id change : réinitialisation "hard" du module, échange de module, etc... Mais on ne peut pas les utiliser dans les scenes "bloc". Là je n'ai pas compris non plus, désolé. Le 10/08/2021 à 11:00, Fredmas a dit : Pour en avoir déjà discuté, il est clair que d'un point de vue général l'écriture dans la DB utilise et use la mémoire flash. Mais quid de la simple lecture en gérant les identifiants comme décrit ci-dessus ? Ca me questionne uniquement au niveau de l'usure de la mémoire, pas au niveau des autres désavantages d'utilisation de la DB comme par exemple les temps de réaction Idem, je suis largué, je ne comprends pas ce que je dois faire... Le 10/08/2021 à 11:36, Lazer a dit : La lecture n'use pas la Flash En ce qui concerne les opérations de lecture/écriture, que ça soit dans une variable globale, une variable de QA ou de scène, une propriété d'un module, etc... au final ça ne change pas grand chose, ça arrive toujours dans la même DB, donc l'usure est sensiblement identique. Reste les questions d'organisation, où stocker la donnée, chacun fait comme il veut. Cela dit, un script (QA ou scène, peu importe), qui va lire des données dans une variable (globale/QA/Scène) à chaque passage de boucle, ira chercher dans la DB, donc c'est plus lent et consommateur de CPU. Probablement sans impact dans la majorité des cas. Mais sur un système chargé, avec une boucle un peu trop agressive (par exemple chaque seconde), l'impact sur les performances deviendra sensible. A l'inverse, un tableau défini au début du code LUA, comme dans l'exemple donné plus haut sur cette page, sera infiniment plus rapide, car ce tableau, une fois chargé en RAM lors du démarrage de la scène/QA, va y rester, donc accessible par le processeur en quelques nanosecondes. Donc pour résumer, si vous souhaitez utiliser souvent une donnée, elle doit rester dans la mémoire du script LUA. Dans ce cas, le script qui exploite une variable "externe", pourra aller la lire une première fois dans la DB au moment au démarrage du script, puis la conserver dans une variable dans le code LUA. Ainsi la donnée reste en RAM, et on n'a plus de problème de performance. Si vous regardez tous mes QuickApps que j'ai partagé sur le forum, c'est ce qui se passe : les variables du QA sont chargées en RAM au démarrage (dans onInit()), puis elles y restent. Bref, la lecture n'est pas un problème d'usure de la mémoire Flash, mais de performance. Ici, il va sans dire que je suis encore plus perdu. Le 10/08/2021 à 12:36, Fredmas a dit : Par contre cela étant dit, pour faire suite à notre discussion précédente à propos des QA et des variables il y a 2 semaines, comme je suis en train de "virer" un maximum de chose en DB, je vais réfléchir/m'inspirer de ta proposition que j'ai résumé ainsi (...) dans la citation précédente, et probablement récupérer (ce n'était pas encore prévu) mes ID en début de QA dans des variables locales pour le reste du code et en faciliter la maintenance en cas de changement d'ID ultérieurs... comme un potentiel passage en moteur 3.0 un jour en 2023 par exemple Le 10/08/2021 à 12:42, Lazer a dit : Oui centraliser les ID des modules quelques part est une bonne approche. Perso c'est un peu différent, car 99% de mes scénarios sont ensemble : dans GEA. Du coup c'est une simple table LUA au début du script qu'il me suffit de maintenir à jour, juste avant le long listing des différentes règles. Les rares exceptions en fin de compte, c'est une scène Alarme, qui est autonome, et fait clignoter les éclairages et envoie des snapshots des caméras. Là les ID sont aussi codée en dur dans une tableau LUA au début de la scène. Ainsi elle reste le plus légère possible et fonctionne en toute circonstance sans dépendre d'une variable globale externe. Et puis de toute façon, les ID de mes éclairages ne changent jamais. Comme tu dis, le jour où on passe sur le moteur Z-Wave v3 et que les ID changent, je n'aurai que 2 endroits à modifier, très simple. Exactement ccomme ce qui s'est passé quand j'ai basculé de HC2 à HC3, la bascule a été très simple (c'était la réécriture préalable des QA qui a été longue) Le 10/08/2021 à 13:52, Cardane a dit : il y a d'ailleurs toujours cette scène disponible sur le forum qui permet de générer la table d'ID à mettre en début de GEA.... elle tourne très bien sur HC3 Itou... Donc en bref, si je récapitule: -- Alerte sur iPhone fibaro.alert('simplePush', {[1] = 104, }, '!! INTRUSION ENTRÉE !!', false) Ce code tout seul fonctionne super bien. -- On allume la lumière entrée fibaro.call(41, 'turnOn') Celui là tout seul fonctionne très bien Etc... Mais quand je les mets bout à bout, ça ne fonctionne plus. L'ensemble du script a été généré par BLOCK que j'ai transféré en LUA. D'autres idées, car je ne souhaite pas trop passer en GEA que je ne connais pas, et que je vais encore m'emmêler dans un autre truc qu'il faut installer. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 16 août 2021 Signaler Partager Posté(e) le 16 août 2021 Ne tiens pas compte des discussions que nous avons eu entre nous, il est vrai que la discussion a dérivé et a largement dépassé tes questions initiales. Désolé si ton topic a été pollué, mais tu constateras que c'est souvent comme ça sur ce forum, dans le feu de l'action et de fil en aiguille les discussions dérivent souvent. Bref, en ce qui te concerne, la dernière réponse à tes questions que j'ai donné était mon message du 9 aout, que tu sembles avoir complètement loupé (car tu cites des tonnes de messages, mais pas le bon ) Voici le lien direct : https://www.domotique-fibaro.fr/topic/15235-configuration-hc3-par-un-débutant/?do=findComment&comment=241090 Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fly Posté(e) le 16 août 2021 Auteur Signaler Partager Posté(e) le 16 août 2021 (modifié) Le 09/08/2021 à 21:21, Lazer a dit : Tu peux soit les décomposer en autant de ligne qu'il y a d'ID... mais c'est un peu fastidieux. Ou bien faire une petite boucle : local IDs = {71, 86, 66, 76} for _, id in ipairs(IDs) do fibaro.call(id, 'setValue', 60) end Sinon il y a peut être moyen avec fibaro.callGroupAction() mais la syntaxe est un peu particulière, car elle permet de filtrer sur les modules existants : https://manuals.fibaro.com/home-center-3-lua-scenes/ Ahhhhh, beaucoup mieux :-) merci j'avais du louper cela merci bien !! Du coup ceci marche SUPER BIEN !! fibaro.call(41, 'turnOn') -- Ferme Volets à xx % fibaro.call({[1] = 86, [2] = 66, }, 'setValue', 50) -- Allume Canapé, Cinéma, Cuisine, SAM, Salon fibaro.call({[1] = 108, [2] = 110, [3] = 111, [4] = 115, [5] = 117, }, 'setValue', 100) -- Saturation Canapé fibaro.callUI(108, 'onChanged', 'sldSaturation', 100) -- HUE Canapé fibaro.callUI(108, 'onChanged', 'sldHue', 0) -- Saturation Cinéma fibaro.callUI(110, 'onChanged', 'sldSaturation', 100) -- HUE Cinéma fibaro.callUI(110, 'onChanged', 'sldHue', 0) -- Saturation Cuisine fibaro.callUI(111, 'onChanged', 'sldSaturation', 100) -- HUE Cuisine fibaro.callUI(111, 'onChanged', 'sldHue', 0) -- Saturation SAM fibaro.callUI(115, 'onChanged', 'sldSaturation', 100) -- HUE SAM fibaro.callUI(115, 'onChanged', 'sldHue', 0) -- Saturation Salon fibaro.callUI(117, 'onChanged', 'sldSaturation', 100) -- HUE Salon fibaro.callUI(117, 'onChanged', 'sldHue', 0) -- Saturation Balcon fibaro.callUI(107, 'onChanged', 'sldSaturation', 100) -- HUE Balcon fibaro.callUI(107, 'onChanged', 'sldHue', 0) Ou encore cela marche aussi: fibaro.call(41, 'turnOn') -- Ferme Volets à xx % fibaro.call({[1] = 86, [2] = 66, }, 'setValue', 60) -- Allume Canapé, Cinéma, Cuisine, SAM, Salon fibaro.call({[1] = 108, [2] = 110, [3] = 111, [4] = 115, [5] = 117, [6] = 107, }, 'setValue', 100) -- Saturation & HUE de toutes les lumières local IDs = {108, 110, 111, 115, 117, 107} for _, id in ipairs(IDs) do fibaro.callUI(id, 'onChanged', 'sldSaturation', 100) fibaro.callUI(id, 'onChanged', 'sldHue', 0) end J'ai une préférence pour la 2ème solution. Par contre, je ne sais pas trop pourquoi, les lampes sont longues à changer de couleur, j'ai essayé d'introduire des TEMPO, mais c'est pas mieux, ça me sature le réseau (ma fille qui joue en même temps m'indique des montées de ping phénoménales à chaque lancement de la scène). Une idée ? Je me demande si ce n'est pas le HUE qui est un peu à la ramasse avec un plugin (où je ne sais pas comment ça s'appelle) que j'ai installé ??? -- PUSH fibaro.alert('simplePush', {[1] = 104, }, '!! INTRUSION ENTRÉE !!', false) fibaro.call(41, 'turnOn') -- Ferme Volets à 60 % fibaro.call({[1] = 86, [2] = 66, }, 'setValue', 60) fibaro.setTimeout(500, function() end) -- Allume Canapé, Cinéma, Cuisine, SAM, Salon fibaro.call({[1] = 108, [2] = 110, [3] = 111, [4] = 115, [5] = 117, [6] = 107, }, 'setValue', 100) fibaro.setTimeout(500, function() end) -- Saturation & HUE de toutes les lumières en ROUGE local IDs = {108, 110, 111, 115, 117, 107} for _, id in ipairs(IDs) do fibaro.callUI(id, 'onChanged', 'sldSaturation', 100) fibaro.callUI(id, 'onChanged', 'sldHue', 0) fibaro.setTimeout(500, function() end) end Et ce qui m'intéresserait maintenant, c'est de les faire clignoter, ROUGE / éteint / ROUGE / éteint, etc... Modifié le 16 août 2021 par Fly Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 16 août 2021 Signaler Partager Posté(e) le 16 août 2021 Ce sont des lumières Philips Hue ? Si tu as des ralentissements sur ton réseau, alors ce n'est clairement pas la faute de la HC3, mais du réseau lui-même. Wi-Fi pourri ? Celui de la box opérateur ? Tu parles de ta fille, elle joue sur PC ou tablette ? Le PC, il faut le brancher en câble. Après ça reste quand même étrange que de simples ordres données à toutes les lumières Hue ralentisse le réseau à ce point, d'où ce que j'ai appelé le Wi-Fi "pourri" ?!? Lien vers le commentaire Partager sur d’autres sites More sharing options...
Fly Posté(e) le 16 août 2021 Auteur Signaler Partager Posté(e) le 16 août 2021 à l’instant, Lazer a dit : Ce sont des lumières Philips Hue ? 3 lumières standard mais une seule dans la scène car les autres elles ne se voient pas d'où je suis (et c'est super rapide pour la Non HUE et c'est top avec Fibaro). Toutes les autres sont HUE oui. WiFi Pourri: NON pas dans la pièce où les HUE se trouvent le réseau est TOP (j'ai récemment fait de grosses investigations et des modifications sur le réseau). Box Opérateur: ??? Est-ce que les scènes de la FIBARO passent par internet avant de revenir à la maison ? En d'autres termes, je lance depuis la maison une scène en attaquant directement la box en http://192.168.1.xx et ça passerait par internet ? Je ne crois pas si ? Ma fille joue sur le réseau WiFi sur tablette. Et je te confirme qu'à chaque fois que je trifouille la Fibaro (en lançant une scène), ça rame grave. Mais ce n'est que moindre mal, c'est pas si long que ça, environ 10 secondes. Je viens de redémarrer la Fibaro, ça va bien mieux curieusement. Maintenant, me reste à trouver comment éteindre et allumer (clignotement) les lumières. Une idée ? Sinon, peut-être que je devrais refaire une installation de plugin (quick app on appelle cela je crois) HUE ? Vous avez un bon candidat à me proposer ? Car celui que j'ai, l'interface graphique n'est pas top (impossible de prédire la couleur que l'on indique, car il faut jouer sur le paramètre "HUE", je n'ai rien de graphique): Lien vers le commentaire Partager sur d’autres sites More sharing options...
Lazer Posté(e) le 16 août 2021 Signaler Partager Posté(e) le 16 août 2021 Que le Wi-Fi soit bon dans une pièce donné, ça ne veut rien dire sur la qualité du réseau. Le Wi-Fi, tous les appareils de la maison le partagent, il suffit qu'il y ait un appareil trop loin, ou 1 seul appareil qui devienne trop bavard, pour pourrir l'intégralité du réseau. Je pense que les communications avec le Pont Hue sont en local, c'est à dire qu'elles ne passent pas par Internet. Mais tu as mal compris mon message, ou bien tu n'as pas saisi le fonctionnement d'un réseau local (Wi-Fi, Ethernet, switch, routeur, Internet, etc) => très probable. Le Wi-Fi des box fournies par les opérateur va de médiocre à passable, mais jamais bon. Ici c'est un peu hors sujet, mais il y ajustement une section réseau sur le forum, et tu verras que pas mal de gens ici sont passés à d'autres solutions pour le Wi-Fi. J'espère au moins que ta box HC3 est branché en Ethernet (avec un câble RJ-45), et pas en Wi-Fi. De façon générale, tout ce qui peut être branché devrait l'être, et on ne conserve le Wi-Fi que pour les appareils mobiles (téléphone, tablette, aspirateur, etc... ponctuellement le PC Portable sur les genoux sur le canapé). Sinon pour le Plugin/QuickApp Hue, désolé je ne sais pas te conseiller, je n'ai pas de Hue chez moi. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés