Aller au contenu

Configuration HC3 par un débutant


Fly

Messages recommandés

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:

 

 

image.png.d909fb81b211f3c1fc77030600d45494.png.4f7e1229ca5312248f23ddbb501f2d71.png

 

image.png.e7ac98091f50b8f7f8e1e0a5af574470.png

 

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:

image.png.9925b4329bf713b105a143bb5bee38a3.thumb.png.53b7c2ec12dab648574aad0562d55f3d.png

 

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

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 :

 

image.png.1a695d9ddbb047cdd6167626c2b2d6e6.png

 

 

Si tu ne vois pas les modules cachés, il y a une case à cocher en haut à droite (décochée par défaut) :

 

image.png.f74b89da044a388bd59d58d784220b89.png

 

 

En complément, on voit le parent et tous ses enfants dans l'onglet Général :

 

image.png.2f2412f5de9a1d620ccfbc9f0c4ed68f.png

 

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

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):

 

image.thumb.png.ed2853772c830966d783bfa79e740e67.png

 

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é:

image.thumb.png.df1eaa696053eb909ee2b29ad681eb2a.png

 

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 ?

 

image.thumb.png.f558504cd1d66d3f4b7607d84643c804.png

 

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

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

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 :huh:

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é par Fredmas
Lien vers le commentaire
Partager sur d’autres sites

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é par Fly
Lien vers le commentaire
Partager sur d’autres sites

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

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é par Sowliny
Lien vers le commentaire
Partager sur d’autres sites

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

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 :D).

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

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.

  • Like 1
Lien vers le commentaire
Partager sur d’autres sites

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 :D 

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  :P

 

 

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 :D

 

Lien vers le commentaire
Partager sur d’autres sites

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

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

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

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 :D

 

 

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

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 :P )

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

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é par Fly
Lien vers le commentaire
Partager sur d’autres sites

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

à 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):

 

image.thumb.png.ab28d665bb9c0b7ffa5a3126e9913142.png

Lien vers le commentaire
Partager sur d’autres sites

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

×
×
  • Créer...