Lazer

Les condensateurs ça s'use, c'est de la chimie, ça peut finir par "cramer", alors il peuvent devenir passant (court circuit), donc il est tout à fait possible que l'usure des piles augmente à cause d'un simple condensateur. En plus, pour une station météo, exposée aux pires intempéries, c'est un scénario très probable. ça peut aussi être une diode ou un transistor, mais c'est plus rare (et le résultat serait plutôt du style : "ça ne marche plus du tout !") Cela dit, nettoyer les cosses me semble une bonne idée ça me rappelle quand je faisais ça avec les patins de voitures de mes circuits électriques... souvenirs

Tout à fait, et je n'ai jamais prétendu le contraire (ou alors je me suis mal exprimé ?) Je ne faisais pas référence au test de performance de @jang, mais à son message précédent Voilà, on est bien d'accord en fait. Désavantages de l'écriture en DB (que ça soit une variable QA ou Globale) : - lent - usure mémoire flash - mène à un crash aléatoire (à priori quand il y a trop d'écritures simultanées, j'ai l'impression que le process dédié à cette tâche dans la box le gère mal... problème connu depuis la v4 sur HC2... même si ça va mieux depuis) Donc oui, on évite autant que possible les écritures en DB. Je considère cette remarque valable pour toutes les écritures, donc aussi bien les variables que les propriétés des modules ("value", etc). Si tu regardes mes codes, tu verras que je m'applique à faire autant que possible une vérification de la valeur précédente, une comparaison, avant d"éventuellement stocker la nouvelle valeur si elle diffère. Cela permet d'afficher un petit message de log dans la console, cela réduit l'usure de la flash, les risques de plantage, et de façon assez intéressante, c'est plus rapide, bien que plus d'opérations soient impliquées. En effet, supposons que la variable/propriété ne change qu'une fois sur 10, alors 10 lecture et 1 écriture, c'est beaucoup plus rapide que 10 écritures seules. En tout cas, ce que tu stockes dans une variable QA/Globale, doit nécessairement avoir besoin d'être persistent, c'est à dire conservé au prochain reboot. L'exemple typique, ce sont les adresses IP configurées par l'utilisateur, le user/password, etc.... Il n'y a pas de raison de stocker une valeur pour le plaisir. Tu peux t'amuser à faire des petits benchmarks de performance, avec une petite boucle sur le modèle déjà partagé par @jang, pour écrire une VG, une Variable QA, un Label, etc... et la même chose en lecture... tu verras la différence flagrante de performance. Alors quelques microsecondes c'est rien, mais sur un système lourdement chargé, avec des dizaines de QA qui tournent en boucle, ça finit par faire beaucoup. PS : les labels ne sont pas persistants en DB sur HC3 contrairement à la HC2, mais leur écriture est tout de même relativement lente. En effet, chaque modification de label entraine l'émissions d'événements récupérables dans les API refreshStates et events/history, donc le rafraichissement des différentes interfaces graphiques (Web, appli mobile...)

Et ? La réponse apportée à la question est très claire, et abonde dans mon sens, puisqu'il déclare bien ses variables locales a et b avant de pouvoir les utiliser. Et @jang dit la même chose dans l'un de ses messages. Ce que précise @jang en complément, c'est que dans le cas de QuickApp:onInit(), il est exécuté après l'exécution du fichier. Du coup les variables locales ont bien été déclarées/définies. Du coup, je ne comprends pas ta remarque pour le QA Surveillance Station, car la fonction loop est déclarée comme étant un membre de la classe QuickApp, donc non concernée par la notion de "forward" (j'ai appris ce terme aujourd'hui d'ailleurs) function QuickApp:loop() end (et oui je sais, ça ne respecte pas ce que j'ai écris quelques messages plus haut, à savoir que cette boucle n'est pas censée être publiée et être partagée aux autres QA, mais c'est un vieux code, parmi mes premiers QA il y a 1 an)

Alors attention, car là aussi il y a confusion. Depuis le début de la discussion, on parlait de langage LUA, donc les notions de variables "locales" et "globales" sont propres au LUA, avec la portée inhérente. Maintenant, tu parles des variables au sens Fibaro, c'est à dire stockées dans la base de données de la box domotique : HC2, HC3, etc. => Ce qu'on appelle Variable Globale (=VG) sur le forum depuis des années. Ou plus récemment, les Variables de QuickApp depuis la HC3. Ces 2 types des variables portent mal leur nom, car elles induisent en erreur avec les "variables" au sens langage de programmation (LUA) Disons qu'elle sont un moyen de stocker des données de manière persistante, comme le ferait un logiciel sur un ordinateur/smartphone : dans un fichier, dans la base de registre, dans une base de données, etc. On lit ces données avec des fonctions getVariable() et getGlobalVariable(), qui retournent une valeur, qu'on stocke dans une variable (une vraie variable cette fois-ci, au sens LUA du terme), qu'elle soit d'une portée locale ou globale dans notre code LUA, c'est notre responsabilité de programmeur. Que la variable LUA soit globale ou locale, elle est perdue en cas de redémarrage du QA, donc il faut l'écrire avec setVariable() pour la mémoriser de manière persistante dans la box. Mais finalement, le principe est le même pour les variable de la box que les variables LUA => il faut réduire leur portée au strict nécessaire. En pratique sur HC2 on utilisait massivement les Variables Globales car on n'avait pas le choix, c'était notre seule méthode de stockage possible, et on s'en servait même pour échanger des données (communiquer) entre différents Modules Virtuels et Scènes. Sur HC3, cela est terminé, il n'y a quasiment plus aucune raison d'utiliser les Variables Globales, perso sur mon HC3 de production, j'en ai très très peu.

Reprenons : -- Cette fonction est membre de la classe QuickApp. Elle est donc automatiquement publiée et accessible depuis l extérieur du QA function QuickApp:test() self:debug("hello") end -- Cette fonction est "globale" (par défaut), c'est à dire accessible dans tous les fichiers du QA : function test(self) self:debug("hello") end -- Cette fonction est locale (car spécifié) donc accessible uniquement dans le fichier en cours (ou bloc de code en cours si la fonction a été définie à l'intérieur d'une autre fonction/boucle/etc) : local function test(self) self:debug("hello") end J'ajoute que l'utilisation des variables globales (et une fonction est en quelque sorte une variable au sens LUA) est à éviter autant que possible, car elles pourraient entrer en collision avec d'autres variables nommées à l'identique dans d'autres parties du code. Une bonne pratique est de limiter la portée des variables à leur strict nécessaire, et à les passer en paramètres des fonctions quand nécessaire. Cela devient de plus en plus important à mesure que notre code grossit, et qu'on réutilise des bouts de codes dans d'autres développements. Un autre impact a lieu également sur les performances, car les variables globales elles sont rangées dans une super table globale nommée _G que l'interpréteur LUA doit parcourir à chaque fois qu'on fait appelle à ladite variable (ou fonction). C'est par conséquent plus lent que l'utilisation d'une variable (fonction) locale. Pour une variable qui est appelée une fois par minute, ça ne change rien. Pour une boucle qui le ferait plusieurs fois par secondes, la différence devient sensible. Rappel :

Je comprends ton besoin de reformuler, mais je t'invite à oublier l'utilisation que tu fais des termes "local" et "global", car ils prêtent à confusion car ce sont des termes qui existent en LUA. Bref, tu as parfaitement compris la portée de la fonction hello() au sein du QA ou en dehors, mais ta formulation des fausse

Tu es certain ? J'avais pris cette habitude, car il me semble que dans mes tests ça ne fonctionnait pas sinon.

Tes 2 écritures sont totalement différentes. Dans la 1ère, la fonction test() n'est pas membre de la classe QuickApp. Elle est globale, c'est à dire qu'elle est accessible dans tous les fichiers LUA du QA. Mais vu qu'elle n'est pas membre de QuickApp, alors elle n'est pas accessible depuis l'extérieur (depuis un autre QA ou scène avec fibaro.call() ou via l'API HTTP) Dans la 2nde, la fonction test() est bien membre de la classe QuickApp. A titre de "best practices", je dirais que les fonctions qui doivent être publiées, c'est à dire accessibles depuis les autres QA, doivent être membre de QuickApp, tandis que les autres fonctions doivent être locales (donc avec le passage de self en paramètres si nécessaire). Pour le QuickApp:onInit(), tu le mets où tu veux, c'est selon les préférences. Souvent en codage, on retrouver les 1ère fonctions en bas du code, parce que lorsqu'elle sont exécutées, les autres fonctions ont déjà été définies préalablement, donc elles sont connues au moment de l'exécution. Exemple : function QuickApp:onInit() hello() -- Erreur : la fonction hello() n'a pas encore été définie end local function hello() print("world") end Il y a 2 façons de contourner le problème : Mettre onInit() à la fin du code : local function hello() print("world") end function QuickApp:onInit() hello() -- OK end déclarer la fonction au début du code, et la définir plus loin : local hello function QuickApp:onInit() hello() -- OK end hello = function() print("world") end

Ah ça, j'avais oublié, je vais tout supprimer, ça sera plus simple, car de toute façon je ne le met plus à jour depuis quelques années. Je parlais de la Box indiquée dans le cartouche à gauche, sous l'avatar

Si si j'avais fait ça fait mai, sur une bonne semaine, tranquillement. J'ai mis à jour la signature du coup. Il le reste juste 2 ou 3 modules virtuels sur HC2 que je j'ai pas encore récris sur HC3, du coup elle est toujours allumée.

J'ai un doute, mais je précise que j'ai déjà migré sur HC3. C'est la migration sur le moteur Z-Wave v3 que je ferai plus tard... déjà attendre qu'il sorte de Beta, puis que Fibaro propose la possibilité de migrer, puis qu'ils débuggent encore un peu, puis la fin de l'hiver.... donc l'été prochain, dans 1 an, me semble un délai raisonnable.

ah bah non, je vais pas casser une config qui fonctionne très bien. On verra, peut être dans 1 an, l'été prochain.

Oh oui Nico tu as le temps de voir venir. Déjà attendre que le moteur Z-wave passe en stable, ensuite ils ajouteront la possibilité de migrer de v2 vers v3, c'est pas avant la fin de l'année à mon avis (ils annonçaient 3 mois, mais on connait leur gestion des délais) @ericl78 non pas testé de reconfiguration, mais je n'ai pas de devices Z-Wave sur mon HC3 de test qui remontent une énergie, que des QA.

C'est tout à fait normal et conforme à ce qui a été annoncé lors de la beta précédente Pour une fois, ils ne sont pas (encore) en retard !

OK merci, voilà qui est mieux. J'étudierai ça plus tard. Tu as quel modèle d'aspirateur ? PS : pense toujours à commencer par faire la dernière mise à jour quand tu as un problème, règle valable pas uniquement pour la domotique, mais de façon générale pour n'importe quel sujet (ordinateur, téléphone, etc). Les mises à jour sont là pour corriger les bugs.

Question : tu as bien installé la version 2.01 proposée dans le topic ?

Pour y voir plus clair, dans ta fonction error() tu peux afficher le message d'erreur err : error = function(err) -- Gestion de l'erreur (connexion impossible) self:error("Echec du lancement de la requette :", err) end,

C'est une solution. Sinon avec VariableCache, je verrais bien le synoptique suivant, en 2 règles : - condition true => action : affectation de la valeur du label dans une VariableCache courante - condition : comparaison de la VariableCache courante avec la VariableCache précédente => action notification + mémorisation du nouveau label dans la VariableCache précédente

Ta syntaxe LUA semble OK, mais là ça coince du coté de ton serveur PHP, il n'aime pas la requête que tu as faite. Mais j'ai l'impression, d'après l'URL, que tu es censé envoyer des données à la page ecod2sql.php, ce que tu ne fais pas, car tu n'as rien dans options = {} Il faudrait y mettre une requête de type "POST" avec des data je suppose.

Euh.... bonne question... tu me poses une colle là

OK c'est plus clair, merci pour le log. Alors on voit bien qu'il commence à discuter, donc la communication réseau est OK. Puis.... plus de réponse.... Je vais étudier ça, mais plus tard, pas avant plusieurs jours.

"Operation canceled" => Pas de réponse de l'aspirateur, c'est un problème réseau, il n'y a rien que je puisse faire, la HC3 non plus. Il faut que tu vérifies ton adresse IP, la qualité de la connexion Wi-Fi de ton aspirateur, etc. PS : merci pour le log, mais les fichiers portant l'extension TXT sont bloqués au téléchargement sur le forum, donc il faudrait que tu le renommes différemment.

Hum, je n'avais pas compris. Tu veux un déclenchement de la règle à chaque fois que le Label change. Alors du coup, le comportent actuel de GEA est "normal". C'est le comportement que tu avais sur HC2 que je ne comprend pas.... GEA est censé faire la comparaison avec la valeur donnée (donc une chaine vide "" dans ton cas), du coup il ne va jamais déclencher quand le label change, car il est toujours différent de "". Ce qu'il faudrait que tu fasses, c'est stocker la valeur du label dans une VariableCache à chaque changement, puis comparer le label avec la VariableCache en question, ainsi tu pourrais détecter la modification du label.

Non en effet, si tu choisis des Philips Hue, alors il faudra utiliser leur nouveau micro-module qu'ils ont sorti cette année derrière l'interrupteur mural : https://www.maison-et-domotique.com/131005-test-module-interrupteur-mural-hue-micromodule-sans-fil/

@Dragoniacs ça me semble un comportement normal, il faut que tu rajoutes {"Repeat"} dans les actions. @fredokl je vois que tu utilises le déclenchement instantané avec -1. Cependant tu n'as entouré aucune de tes conditions par des parenthèses, donc elles sont toutes des déclencheurs... es-tu certain que c'est bien ce que tu voulais ? Sinon sur quelle condition est censée se déclencher ta règle ? Commençons par mettre la règle au propre avant de débugguer.