Lazer

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 :

Si GEA redémarre tout seul, il faudra me donner les logs au moment du redémarrage, sans ça impossible de deviner le problème. Par ailleurs, mettez bien une règle qui vous envoie une notification au redémarrage de GEA (comme dans l'exemple fourni), ça évitera les "impressions" et vous aurez des certitudes sur le redémarrage (ou non) de GEA. Personnellement ça ne m'est jamais arrivé depuis 3 mois que mon GEA tourne en production, avec 150 règles environ (par contre j'ai eu quelques redémarrages de la box) Par ailleurs, est-ce que ça ne serait pas un problème plus général sur la box ? Avec des freeze ou une saturation de la RAM ? Sujet plusieurs fois abordé sur le forum. Si vous avez Domocharts, regardez les graph CPU et RAM. Perso j'en ai assez rarement des freeze, mais ça semble arriver plus souvent à @jjacques68 notamment. Parce qu'un freeze de 1, 2, 3 minutes, voire plus, ça peut expliquer les actions manquées telles que l'allumage du sèche serviette de ton exemple. Mais ça n'expliquerait pas la règle d'extinction du sèche serviette, qui n'a pas de référence horaire. Quand ça arrive, dans la HC3, le module 454, il est bien ON ? Il faut analyser les causes des comportements erratiques, sinon tu ne trouveras jamais.

Attention si tu souhaites mettre la HC3L en passerelle derrière la HC3, il y a encore de nombreux bugs avec cette stable pour les modules esclaves (exemple : impossible de modifier leur propriétés). Fibaro travaille sur le correctif.

Bienvenue sur le forum

Je mettrais un "Repeat" oui.... car le problème avec les détecteurs de mouvement, c'est que s'il se déclenche et s'arrête entre 2 boucles de GEA (toutes les 60s), alors GEA rate des mouvements. Je sais que ça m'arrive sur certains de mes scénarios, depuis la HC2. Donc le Repeat devrait permettre de contourner ce problème.

Je ne sais pas.... je suppose que ça va tout supprimer. Sinon tu attends, ça va se purger automatiquement.

Non, avec updateProperty tu ne peux modifier que les propriétés, c'est à dire les valeurs qui sont dans la sous-table properties du JSON du module (visible via /api/devices/ID) Si la variable est "locale", c'est qu'elle est dans la mémoire (pile) du code LUA en cours d'exécution, donc elle n'est absolument pas accessible depuis un autre QA. C'est l'isolation élémentaire des espaces mémoires des programmes informatiques. Encore heureux... encore que des bugs/failles existent, ce qui mène aux plantages ou piratages qu'on voit parfois passer... En revanche, tu peux modifier les variables de QA (celles qui sont dans l'onglet Variables de l'interface Wzb), puisqu'elles sont stockées dans les properties du QA. Mais attention, le format est un peu spécifique, c'est une sous-table qui liste toutes les variables et leurs valeurs, cela n'est donc pas modifiable avec updateProperty, il faut passer par l'API directement.... ou plus simplement appeler la méthode setVariable du QA cible : fibaro.call(ID, "setVariable", "ma_variable", "ma_valeur") je l'ai déjà dit plusieurs fois sur le forum, mais toutes les méthodes (= fonctions) d'un QuickApp sont automatiquement exposées, elles peuvent donc être exécutées depuis un autre QA, ou bien depuis n'importe où dans le monde en passant par l'API HTTP de la box. Cela inclue donc des fonctions aussi élémentaires que self:debug() ===> fibaro.call(ID, "debug", "Injection d'un message dans le log du QA cible") Cela étant dit, tu peux créer une fonction dans un QA, qui permet de modifier une variable locale. Exemple tout simple : function QuickApp:onInit() self.mavariable = "Hello" end function QuickApp:ModifyVariable(value) self.mavariable = value end Il suffit d'appeler depuis un autre QA : fibaro.call(ID, "ModifyVariable", "Goodbye")

En effet, normal, il fallait écrire avec self : fibaro.setTimeout(0, function() self:loop() end) fibaro.setTimeout(3000, function() self:loop() end) Je t'ai dis, c'est pas testé, et écris à l'arrache

C'est un bon début Alors c'est normal, car tu as déclaré tes variables en local, donc elles ne sont connues que dans la fonction onInit(), mais pas dans loop() Voir : Ensuite, il ne faut surtout pas utiliser sleep(), ça va bloquer ton QA, donc mener à un plantage de celui-ci, voire à un reboot de la box. Il faut utiliser setTimeout() C'est de l'asynchronisme, un mécanisme pas évident à comprendre.... Voir ici : Ce que tu peux faire, c'est affecter tes variables à self (l'objet qui désigne le QuickApp en mémoire), ainsi tu peux utiliser les variables dans toutes les fonctions du QA. Pour accéder à un élément particulier d'une table, il faut utiliser les crochets, et le dièse pour compter le nombre d'éléments de la table : for i=1, #Table do print(Table[i]) end ce qui devrait donner un truc dans le genre (non testé, à affiner, mais ça te donne une base de travail) : function QuickApp:onInit() self:debug("onInit") local tempOld = self.properties.value self.Table = {} for i = 1, 10 do table.insert(self.Table, tempOld) end self:debug(json.encode(self.Table)) fibaro.setTimeout(0, function() loop() end) -- on lance la boucle end function QuickApp:loop() self:debug("loop !") table.remove(self.Table, 1) local newValue = fibaro.getValue(123, "value") -- il s'agit de l'ID de ton module température Z-Wave ou Netatmo table.insert(self.Table, newValue) self:debug(json.encode(self.Table)) local tempSum = 0 for i = 1, #self.Table do tempSum = tempSum + self.Table[i] end local tempMoy = tempSum / #self.Table self:debug("Nouvelle moyenne :", tempMoy) self.updateProperty("value", tempMoy) fibaro.setTimeout(3000, function() loop() end) -- prochaine boucle dans 3 secondes end

Au cas où, tu es en Wi-Fi ? Essaye de le désactiver pour passer en 4G. Sur le forum officiel, plusieurs personnes ont des problèmes avec l'appli en Wi-Fi (dans la sous-catégorie iOS, j'ai l'impression que ça ne concerne pas Android)

Chez moi ça marche, rien à signaler. Sur Android pour info.