Lazer

Oh ! Trop bien !

Cool, encore une occasion de trinquer ! Bon anniversaire @Dragoniacs

Rien à voir avec les variables. Ta fonction AffichageJour n'est pas membre de QuickApp, donc self est inconnu à l'intérieur de celle-ci => attempt to index a nil value (global 'self') Toujours bien prendre le temps de lire le message d'erreur, ce n'est pas toujours clair, mais dans le cas présent ça l'est Il faut donc lui passer self en paramètre : function AffichageJour(self) if self:getVariable("OuvAutoMardi") == "OUI" then v= v .."Ma " end self:updateView("lblJour", "text", v) end function QuickApp:onInit() AffichageJour(self) end Si tu avais mis n'importe quelle autre fonction, pas exemple self:debug() tu aurais eu la même erreur.

Penses à faire un tostring() avant de faire le setVariable() L'API, c'est celle que tu utilises en LUA, inconsciemment (via les commandes LUA), ou bien directement en attaquant l'API REST via HTTP (c'est ce que font les commandes LUA en fait) Tu auras la syntaxe complète (ou presque) de l'API dans le Swagger de la HC3.

2 anniversaires en plein confinement, ça fait quand même 2 anniversaire assez peu alcoolisés.... Vivement le prochain.... euh....

Mais c'est dans la tête l'âge voyons

C'est très simple : attendre mardi

Je pense que le groupe NICE prépare l'arrivée de sa nouvelle box de son écosystème Yubii, basé sur une HC3-Lite dédiée : https://products.z-wavealliance.org/products/4107?selectedFrequencyId=1 L'application est renommée pour une intégration globale... du coup... est-ce qu'ils vont abandonner la marque Fibaro à terme ? C'est probable, cette marque est inconnue en dehors des geeks. On verra bien.

Home Center App 1.12 Update As announced, we would like to inform you about important changes to the Home Center app in the near future. With the next update, on April 20, the app will become an integral part of the Yubii ecosystem, which will provide seamless integration of Yubii Nice devices. The update will bring the new icon and the new name - Yubii Home Center. Key information: Changing the login screen In order to use the application and manage all devices within the Yubii ecosystem, log in with the refreshed login screen. You only need to use your current FIBARO ID account. Communication between the app and the control panel as well as passwords are encrypted, so when you entrust your house to our system, you can be sure that it is safe in every aspect.

Merci à tous C'est cool parce qu'avec vous c'est un peu mon anniversaire pendant 1 semaine

Oui donc ce n'est pas GEA en lui-même, mais l'utilisation qui est faite de GEA.... comme GEA est suffisamment générique pour effectuer la plupart des actions sur la box, fatalement il y a un moment où ça peut poser problème. Comme n'importe lequel des QuickApps que chacun développe dans son coin, on est libre de faire n'importe quoi. Cela dit je trouve que la HC3 aujourd'hui est largement plus robuste qu'au début, il y a 1 an... où il était possible de la crasher en 1 ligne de LUA ! (expérience vécue) @971jmd Sinon ma saturation CPU n'avait rien à voir, puisque c'était uniquement 1 cœur (sur les 4) qui était à 100%, et cela pendant plusieurs heures (et pas juste quelques secondes), et la box continuait de fonctionner parfaitement bien. Aucun dysfonctionnement ou ralentissement constaté, j'ai pris le temps de faire le tour de tous mes QuickApps avant de rebooter la box. Voici ici : Mais, cette semaine j'ai rencontré le problème décrit par certains ici, box figée pendant plusieurs secondes. J'étais en train de travailler sur un QuickApp conséquent, composé de 5 fichiers LUA, c'est au moment de l'enregistrement des fichiers que la box s'est figée, pendant 20 secondes environ. On a peut-être là une piste, comme sur HC2 à un moment donné, je ne serai pas surpris que ça soit l'accumulation d'écritures dans la DB (donc sur disque) qui cause les ralentissements. Et Fibaro devrait se concentrer sur ce problème plutôt que d'accuser les QuickApps des utilisateurs (surtout que les QA des utilisateurs sont souvent mieux développés que ceux de Fibaro même ) Puis c'est revenu à la normale comme si de rien n'était, comme en atteste la courbe ci-dessous. Je n'avais pas le graph CPU temps réel de la box d'ouvert à ce moment là (je ne l'utilise jamais), mais de toute façon il aurait été inaccessible car le box ne répondait plus. Sur le graph Domocharts, qui n'a une résolution que d'une minute, on voit un petit pic, mais ce pic a été trop court (moins de 60s), donc pas suffisant pour voir la courbe atteindre 100% sur les 4 coeurs :

Justement, met des print() dans ta fonction, car là on ne sait même pas si elle est effectivement démarrée ou pas. Un print au début de la fonction, et un print(type(...)) sur les variables que tu utilises pour connaitre leur type. Une variable globale c'est du string par défaut, sauf si tu as mis autre chose dedans lors de sa dernière modification

Quand tu dis que ça ne fonctionne pas, concrètement il se produit quoi ? La variable globale n'est jamais mise à jour ? Est-ce que la règle GEA est bien exécutée toutes les 10 minutes ? Tu vois quoi dans les logs ? N'oublie pas d'activer le mode debug. Et note que tu peux ajouter tes propres logs dans ta fonction perso, avec de simples print() tu peux afficher dans le log ce qu'elle effectue, ça te permet de diagnostiquer en temps réel la valeur des variable, la validation du test de la soustraction, etc

Je crois que c'est une des nouveautés du LUA 5.3, les nombres sont traités en number, et il existe le type integer à part. Le souci c'est que même si tu utilises des integer, LUA va automatiquement les convertir en number dès que tu feras une opération mathématique dessus. Et il n'est pas possible de caster les variables comme on le fait sur d'autres langages. ça m'avait bien surpris au début lors de mes premières migrations de codes LUA depuis la HC2 vers la HC3. Il faut que tu prennes l'habitude de formater tes nombres quand tu veux les afficher (dans le log, dans un label, etc..), avec string.format() Exemple pour un nombre entier : self:debug(string.format("heure : %d", heure)) Autrement, tu peux aussi te créer ta propre fonction générique round(), vu que LUA n'en propose pas nativement. Perso elle est incluse dans ma "librairie" d'outils que j'utilise dans tous mes développements de QuickApps. Exemple : -- -- Round number to specified decimal -- -- Usage : -- local entier = round(123.456, 0) -- local decimal = round(123.456, 1) -- function round(num, idp) local mult = 10 ^ (idp or 0) return math.floor(num * mult + 0.5) / mult end

Il n'y a pas 1 sujet, il y a au moins 90% des discussions du forum qui traitent de la HC3 maintenant, dont plusieurs sujets ouverts de retours d'expériences, question, plaintes, et joies Normalement tout est dans la section dédiée : https://www.domotique-fibaro.fr/forum/122-hc-3/ Attention quand même aux premières discussions d'il y a un an qui ne sont plus d'actualités, la box a beaucoup évolué depuis. Le seul truc qui manque par rapport à l'annonce commerciale, c'est le Zigbee, mais là aussi il y a au moins 2 ou 3 sujets qui en parlent, avec la réponse claire de Fibaro : repoussé à la St Glinglin, voire même annulé, car ils attendent de voir si CHIP aboutie à une offre commerciale. Sinon mon HC2 a aussi plus de 7 ans et elle fonctionne toujours très bien (et une en secours au cas où). Quand je l'ai acheté, je visais 3 à 5 ans de durée de vie, honnêtement on a beau se plaindre de Fibaro et de ses retards de développement, il faut avouer qu'ils font plutôt des produits durables, et ça c'est bien appréciable

Il me semble que ça se produit si tu mets autre chose qu'une string dans une variable. Par exemple un number (ce qui semble être le cas) L'API le tolère tout à fait, mais pas l'interface Web.

Je n'ai que 8 modules Z-Wave sur la HC3, mais déjà beaucoup plus de QuickApps (et une vraie colonie de children ) Hyper content oui, pour développer c'est l'éclate, fini toutes les limitations des VD et les contournements complexes via des Labels/VG/Scènes. Normalement je migre mes modules Z-Wave sur la HC3 le mois prochain.

Effectivement, un WP qui fait 1/4 du trafic à lui tout seul, y'a un malaise Les exclure ne changera rien, ils sont bavards à cause de la charge branchée dessus, et tu le vois bien, 3547 trames de mesure de consommation... Il faut jouer avec les paramètres du modules, pour ajuster au mieux à l'appareil branché dessus. Il faut commencer par lire la doc pour bien comprendre les paramètres, ils sont très nombreux. Et la suite de la discussion aurait plus sa place sur le topic du Wall Plug justement.

Peut être parce que tu as des vrais souci de communication ? Il y a une scène sur le forum officiel pour analyser le trafic Z-Wave, ça permet de voir la charge, de déterminer les noeuds les plus bavards, et de les faire taire (ou du moins de les calmer un peu) Perso j'ai appliqué cette méthode pour un Wall Plug branché sur mon frigo, qui floodait le réseau.

Attention ça c'est sur HC3, je ne sais pas si ça fonctionne sur HC2. A tester...

Pour le getVariable, allez voir dans le code source de GEA L'idée de base est simple : api.get("/devices/" .. ID) puis on parcoure les variables pour récupérer celle qui nous intéresse. On peut aussi en supprimer d'ailleurs. Tout est possible.

La méthode setVariable étant une fonction de la classe QuickApp, elle est automatiquement exportée, donc tu peux l'appeler depuis n'importe où : un autre QA, une scène .... (ou même depuis l'extérieur via l'API HTTP) Le plus simple, avec un truc dans le genre je pense que ça doit fonctionner : fibaro.call(ID, "setVariable", "variable", "valeur")

Ah, ce n'est pas passé inaperçu Merci @fredokl

@Sakkhho 440s ça doit être la valeur que t'a conseillé la box, calculé en fonction du nombre de modules dans ton réseau. Quand tu dépasseras un certain seuil, elle te proposera de l'augmenter encore. Perso j'en suis aussi à 440 secondes, pour 94 modules. @kioneoranga Attention, parce ce que parles de polling et de modules à piles dans la même phrase. Les modules à piles ne sont pas concernés par le polling. J'ai constaté les conditions suivantes pour qu'un module passe en noeud mort sur la HC2 : module sur secteur : s'il ne répond pas suite à un ordre envoyé par la box ou l'utilisateur (turnOff, etc) s'il ne répond pas suite à une demande de polling module à pile : s'il n'y a aucune communication depuis le dernier intervalle de réveil. Puisque pour rappel, un module sur batterie doit forcément communiquer avec la box à chaque intervalle de réveil, ou d'envoi de trame spontanée (mesure de température, mouvement, ouverture, etc) Cas particulier : un module dont on aurait désactivé l'intervalle de réveil (possible sur les modules récents) => il ne passera jamais en nœud mort, normal

Perso je remet systématiquement le polling avec l'intervalle global configuré au niveau de la box (donc plus il y a de modules, plus cet intervalle s'allonge) Mais j'ai vu que sur de gros réseaux (plus de 100 modules), si des latences commencent à se faire sentir, cela indique une saturation, donc il est conseillé de désactiver le polling.