Lazer

ça c'est normal, plus on apprend, plus on se rend compte du chemin qui reste à parcourir pour maitriser le sujet Pas valable que pour le LUA bien sûr...

Il faut te connecter en local avec l'adresse IP de ta box, et non pas via le cloud home.fibaro.com Utilise Fibaro Finder si tu ne connais pas l'IP, ou alors regarde sur ta box/modem/routeur Internet pour retrouver quelle adresse IP lui a été affectée.

Alors là je ne sais pas faire. Pire, ce que tu veux faire va à l'encontre même du principe de base de GEA.... Du coup je me demande si tu n'aurais pas mieux faire, pour ce scénario précis, de l'écrire à la main en LUA et de le mettre dans une scène dédiée.

Alors, je ne maitrise pas du tout l'usage de StopTask.... je ne sais pas si ta proposition est faisable, il faudrait que je me penche sur la question. Je ne sais pas à quels autres cas d'usages tu penses ? Car pour cet exemple précis tu n'as pas besoin de StopTask. Il te suffit de mettre une VariableCache à une certaine valeur dans les actions de ta seconde ligne, et tester la valeur de cette VariableCache dans les conditions de la première règle.

Si tu ne spécifie pas "local" devant le nom de la variable lors de sa première utilisation, alors elle sera globale. Cela dit, ça ne change pas forcément le fonctionnement du QA.

Bienvenue sur le forum

Ce n'est pas prévu... mais bonne idée. Je vais l'ajouter dans une prochaine version.

Elle fonctionne très bien sur HC3, exactement pareil que sur HC2. Il faut juste l'inclure en mode normal, pas en mode sécurisé.

Voici GEA version 7.34 : Corrige la syntaxe abrégée de "Weather" qui utilise la propriété "WeatherCondition" par défaut. Remarque : je ne conseille pas l'écriture abrégée, préférer l'écriture complète. Le document de syntaxe a été mis à jour dans ce sens. Corrige l'option "VariableCache" quand on lui affecte la valeur booléenne false Copier/coller le contenu du fichier LUA téléchargé par dessus le fichier main dans le QuickApp (ou bien télécharger le QuickApp complet disponible en 1ère page)  GEA v7.34.lua

Le mieux est de continuer la discussion sur le bon topic

Je l'ai cette petite sirène (qui fonctionne aussi bien sur HC3 que sur HC2 au passage), elle est bien pratique pour "notifier" le visiteur du jardin. En effet, vu qu'elle ne sonne pas assez fort pour indisposer un intrus, elle a au moins le mérite de l'informer qu'il a été "vu", ça lui permet de partir tranquillement avant que la vraie alarme ne prenne le relai et réveiller tout le quartier.

Bienvenue sur le forum

Depuis le record ci-dessus, j'ai eu un nouveau record à plus de 150 Mo de RAM utilisés pendant mes vacances. En effet, en l'absence d'événements récents, le QA était obligé d'aller chercher loin dans l'historique, donc manipulation de gros tableaux. Le QA a fini par planter et n'a pas été redémarré par la HC3. Du coup, voici la nouvelle version 2.00, qui n'exploite plus la même API : Utilisation CPU et RAM réduite Rafraichissement quasiment instantané (chaque seconde) Pour la mise à jour, copier/coller simplement le contenu du fichier LUA par dessus le code situé dans le fichier main du QuickApp. A noter que la variable Refresh n'est plus utilisée, vous pouvez la supprimer dans l'onglet Variables du QuickApp. Par ailleurs j'ai laissé le bouton Refresh, mais il n'est plus vraiment utile en pratique. Téléchargement : Evénements v2.00.lua

Création du topic unique de l'IPX800 V5 : Ce topic rumeur est maintenant fermé.

IPX800 V5 Automate Ethernet Hardware: 8 entrées digitales protégées jusqu’à 15V DC 2 x 2 Entrées digitales opto-isolées 0-30V avec 2 masses séparées 4 entrées analogiques 0/3.3v 16 bits 8 Sortie relais 10A inverseurs (cos phi 1) 4 sorties collecteurs ouverts opto-isolées 1 Sortie Modbus 2 Bus Powered EBX sur RJ45 1 Bus EBX sur bornier pour compatibilité avec V4 1 Bus EXT Alimentation : 12 Volts continu (Alimentation X-PSU20 vendue séparément). Consommation : 1 W ( 4 W avec les 8 relais activés). Réseau : 10/100Mbits, HP Auto-MDIX, cable diagnostics, Energy Efficient Ethernet (IEEE 802.3az). Système d’exploitation IPX-OS5 avec Webserver. Sauvegarde en mémoire flash (pas de carte SD). Température d’utilisation : -10 à +60 °c @ 50% humidité Indice de protection IP20 Indice de réparabilité 8,5 Boitier pour montage rail DIN (prévoir 9 emplacements) Annonce officielle du produit le 30/08/2021 sur le forum officiel GCE Electronics : https://forum.gce-electronics.com/t/sortie-de-lipx800-v5-presentation-et-prevente/13716 Les préventes démarreront le 07/09/2021 avec 2 offres : 1 Offre IPX800 V5 seule à 280€ 1 Offre IPX800 V5 + X-PSU20 à 309€ L’utilisation de la X-PSU20 permet d’avoir la gestion intelligente de la commutation des relais afin de limiter les appels de courant (très utile pour les leds et éviter le collage des relais). Les premières IPX800 V5 seront livrées mi-octobre. L'API est très complète mais complètement différente, accès possible à la documentation avec création de compte : https://forum.gce-electronics.com/t/ipx800-v5-lapi-est-en-ligne/13731

2 qui lâchent en même temps, c'est assez surprenant. Alors à moins qu'ils n'aient pris la foudre/une surtension (mais dans ce cas tu dois avoir plein d'autres appareils électriques HS), le problème est peut-être à chercher du coté de ton contrôleur.... Domoticz utilise OpenZwave, qui est connu pour être l'un des pires contrôleurs Z-Wave... Tu n'as pas un autre système pour tester ? Autre piste, sans certitude, tu peux tenter de réinitialiser les modules avant de retenter l'inclusion. Regarde dans la doc pour la procédure exacte.

Bienvenue sur le forum

Oui, il vaut mieux prendre les bonnes habitudes dès le début A noter qu'un code optimisé tout court ça n'existe pas. On optimise dans un but précis, par exemple la performance CPU, ou bien l'empreinte mémoire. Et parfois, un code plus rapide consomme plus de RAM. Et/ou devient illisible. Je me souviens avoir appris à une époque étudiante qu'un appel de fonction c'est relativement long (ça consomme des cycles CPU), et un code rapide utilise le moins de fonctions possible.... donc on se retrouve avec des bouts de codes répétés plusieurs fois par ci par là dans le code... ça devient illisible et inmaintenable, mais c'est rapide. Ce qu'il faut trouver, c'est le juste milieu en fonction de l'effet recherché. Nous ça va, on veux juste faire des QA pour afficher 2 ou 3 informations dans un cadre domotique, ça reste simple. Tiens pendant que j'y pense en parlant performance et algorithme. J'ai mon QA Événements (partagé sur le forum) qui est le plus consommateur de RAM et de CPU de ma box, juste pour afficher les 25 derniers événements. Je sais pourquoi, il manipule de grosses tables, plusieurs centaines d'éléments, et le LUA n'est pas très bien optimisé à ce petit jeu là. Pendant mes vacances, il s'est emballé, a consommé jusqu'à 150 Mo de RAM (là où la plupart des QA consomment autour de 1 Mo seulement), et plusieurs pourcents de CPU. La box n'a pas crashé, pas rebooté, elle a tué le QA, et ne l'a pas redémarré (alors qu'il y a normalement un watchdog qui surveille le redémarrage des QA plantés). Bravo Fibaro pour la stabilité et la robustesse de la box Et pourtant dans ce QA, j'avais fait plein de micro-optimisations, notamment redéclarer toutes les variables et fonctions globales en local, etc.... mais c'était inutile en fin de compte, l'erreur était dans l'algorithme, la méthode que j'ai employé n'était pas la bonne (interrogation de l'API /events/history) J'ai commencé la réécriture en utilisant une autre méthode (/api/refreshStates), et les premiers résultats sont très encourageants, ça semble consommer moins de CPU et moins de RAM. Combo gagnant. Et cerise sur le gâteau, au lieu d'avoir un intervalle de rafraichissement de 60s, il est maintenant de 1s seulement ! Comme quoi, il faut parfois prendre le problème par un autre bout, et tout recommencer à zéro quand ça ne va pas.

Tu calcules surement ta charge CPU de façon différente, moi je le fais avec DomoCharts, qui calcule ça en interne dans le QA avant d'exporter vers la DB. Du coup le pic CPU est visible uniquement à la fin du Freeze. La box figée, je l'ai déjà constaté, mais uniquement durant quelques secondes, lorsque j'ai trop d'onglets ouverts en même temps (plus de 4, ça empire si on ouvre 5 ou 6 onglets), et que j'enregistre un QA en cours d'édition. C'est ce qui m'avait fait dire à un moment que c'est le process d'écriture dans la DB qui fige les autres I/O, donc la box qui se met en attente de la disponibilité de la DB. Je ne sais pas si le freeze long a le même origine, les I/O. Il faudrait peut être vacciner la box pour réduire les risques de freeze long

Dans l'ensemble, OUI.... mais je vais te reprendre sur 2 points : Dans l'exemple #2 : - "mavariable" a une portée locale (à tout le QA qui la contient), le code ne fait pas appel à la table "super-globale _G" durant son exécution => Il est incorrect de parler de portée, car mavariable est en réalité un élément de la table QuickApp. C'est là que le LUA est un peu étrange, et différent d'un vrai langage de programmation orienté objet (C++, Java, etc). QuickApp est donc une table, qui contient différents éléments : function, string, number, table, etc... La subtilité c'est que dans les fonctions, "self" pointe sur la table QuickApp elle-même, donc on a accès à tous les autres variables et fonctions de cette table, y compris notre fameuse mavariable. Du coup, par abus de langage, on dit que la portée de mavariable est celle de QuickApp, c'est à dire utilisable dans tous les fonctions membres de QuickApp. - performance exécution code théoriquement maxi => en fait non pas du tout, car pour aller chercher mavariable, le programme va devoir parcourir la table QuickApp.... donc la performance est plus ou moins similaire à celle d'une variable globale qu'on va rechercher dans _G. En fait, pour savoir lequel des 2 est plus rapide, il faut compter le nombre d'éléments dans les tables _G et QuickApp.... du coup, ben ça dépend de chaque programme. Après il ne faut pas non plus se focaliser sur cette histoire de performance d'accès aux variables, car c'est de l'ordre des nanosecondes (microseconde à tout casser), c'est inmesurable en pratique, sauf à avoir une boucle qui effectue un gros calcul et accès 1 millions de fois à la même variable. C'est sans commune mesure avec les performances d'accès à la base de données, qui se compte en millisecondes. Bien souvent quand on cherche à optimiser les performances d'un programme informatique, le gros des gains se fait sur l'algorithme utilisé, pas sur l'accès à telle ou telle variable. Et puis quand on cherche la performance maxi, on n'utilise pas du LUA (qui est déjà relativement rapide cela dit), mais plutôt du C... voire de l'assembleur. C'est un tout autre domaine, qu'on va rencontrer dans les moteurs de rendus 3D des jeux vidéos, le calcul scientifique, etc. Bref, l'important dans cette histoire, c'est la portée des variables, qu'on doit limiter à leur strict nécessaire, c'est une bonne pratique pour éviter les collisions de 2 variables qui porteraient le même nom dans 2 bouts de codes différents. C'est particulièrement vrai quand on réutilise des bouts de codes qu'on a déjà développé (sous forme de "librairie", que ça soit dans le même fichier LUA ou dans un autre fichier LUA du QuickApp)

En Z-Wave, un module peut être exclus par le contrôleur qui l'a inclus (donc la HCL dans ton cas), ou bien par n'importe quel autre contrôleur (donc la HC3L dans ton cas) La seule différence en pratique, c'est que : - si tu exclus avec la HCL, alors le module sera retiré de ton HCL - si tu exclus avec la HC3L, alors le module restera dans la HCL... Mais passera en nœud mort car la HCL ne pourra plus communiquer avec Personnellement j'ai tout exclu avec la HC3, car ça me permet de conserver les anciens modules sur la HC2, ainsi j'ai pu relever les anciens ID pour adapter mes scénarios, mais aussi retrouver les paramètres Z-Wave des modules, ou bien encore les icônes. Ensuite quand tu n'as plus besoin de la HCL, tu fais un recovery complet, ça fera le grand ménage.

Et bien... suffisait d'en parler, ça vient de m'arriver, à 18h. Je me suis rendu compte que GEA n'avait pas exécuté une action à cette heure là (action simple, sans autre condition que l'heure) Je regarde la courbe CPU de DomoCharts, et je constaste un affreux pic à cette heure là.... donc forcément, GEA n'a pas pu exécuter l'action à l'heure dite. La solution de contournement, tant que Fibaro n'aura pas travaillé sur ce problème de freeze, c'est d'allonger les plages horaires "Time" qu'on utilise dans GEA.... Là où je suis inquiet, c'est que personne, à part toi et moi, ne semble avoir relevé ces freeze (faut dire que c'est pas évident à détecter).... et encore moins remonté sur le forum officiel, donc Fibaro n'est pas prêt de travailler sur ce sujet... D'ailleurs, c'est très étonnant que ça soit tous les jours à la même heure chez toi, car chez moi c'est assez rare. Plutôt tous les 15 jours, à des horaires variables.

Ah voilà tu as retrouvé où on en a parlé il y a quelques temps Outre les problématiques de portée et de risque d'erreur de réutilisation, précisons, au sujet des performances, qu'il est plus rapide d'utiliser des variables locales que des variables globales (en LUA, ce n'est pas le cas avec d'autres langages) En effet, en LUA, accéder à une variable globale requiert de parcourir la table super-globale _G (une table qui contient toutes les variables globales, les fonctions, etc), ce qui prend des cycles CPU à chaque accès. Mais on parle là de micro-optimisations. Il n'y aura un gain sensible à ce niveau que pour un algorithme très lourd, avec une boucle qui effectue des millions d'accès à la même variable. Cela n'a rien à voir avec la différence de performance lors de l'accès à une variable persistante en DB, pour laquelle la différence de performance est considérable.

Attention de ne pas confondre : les variables LUA (qui existent dans le code LUA, qu'elles soient locales, globales, ou attribuées à un objet via self) => elles résident uniquement en RAM, elle sont créées à chaque démarrage du QuickApp, et perdues lors de son arrêt les variables persistantes de la box (globales, de QuickApp, ou de Scène) => elles sont stockées dans la DB, donc conservées à chaque redémarrage du QA ou reboot de la box.

Dans mon exemple, mavariable est affectée à l'objet self, c'est à dire l'objet QuickApp, cette variable n'est donc accessible que depuis l'une des fonctions membres de QuickApp (avant de me faire reprendre par les experts : en pratique on peut y accéder d'ailleurs, mais chut, on va pas compliquer inutilement pour l'instant) Dans ton dernier exemple, mavariable est une variable globale dans le code LUA de ton QA. C'est qui n'est pas idéal, car une bonne pratique c'est toujours de limiter la portée d'une variable au strict nécessaire. C'est un sujet qui a été abordé plusieurs fois sur le forum, mais l'information étant diluée ça et là au fil des discussions, c'est pas évident à retrouver. On pourrait transformer ta variable globale en variable locale en l'écrivant ainsi : local mavariable function QuickApp:onInit() mavariable = "Hello" end function QuickApp:ModifyVariable(value) mavariable = value end En revanche attention ce code est faux, car la variable serait alors locale uniquement à la fonction onInit() et ne serait donc pas accessible depuis la fonction ModifyVariable (qui créerait alors une autre variable, globale cette fois-ci, portant le même nom) function QuickApp:onInit() local mavariable = "Hello" end function QuickApp:ModifyVariable(value) mavariable = value end Quelques bonnes lectures :