Lazer

Ah oui, mais alors tu te bases effectivement sur des vieilleries D'ailleurs, là encore tu restes trop dans l'esprit HC2, il faut oublier tout ça. Complètement Totalement Intégralement ... Bref, la "bonne" méthode (au sens HC3) c'est de créer des QuickApps nativement typés comme il faut. Par exemple capteur de température (que tu choisis au moment de sa création dans la liste déroulante) Puis tu affectes directement sa valeur dans le champ properties.value Et terminé. Pas besoin de label, variable, json, et autre trucs compliqués Je n'arrête pas de le dire sur ce forum, mais oubliez la HC2 les gars, la HC3 reprend tout proprement dès la base : chaque device, a un type, et une value => Intégration native dans l'interface

Pour moi updateProperty n'est pas la bonne action à appeler => il faut appeler l'action setVariable Par ailleurs, ta variable est pour le moins curieuse. Déjà son nom... "ui.Json.value" mais pourquoi un truc aussi compliqué ? J'ai l'impression que tu raisonnes HC2 et que tu confonds avec les anciens Labels des VD historiques. Ensuite son contenu... tu mets un tableau dans le string, avec un id et une value... mouais, là aussi pas fan, tu vas t'ennuyer à json.encoder et json.decoder ça à chaque usage, avec un risque de plantage au passage (les fonctions json.encode() et json.decode() plantent dès que le JSON est mal formaté) En plus ça fait utiliser des cycles CPU pour rien, il est plus efficace de stocker une variable dont la valeur est directement utilisable. Et pour finir quand tu fais tes requêtes sur l'API tu es obligé d'url-encoder la string à cause des caractères spéciaux (accolades, guillemets) Je te propose de simplifier tout ça, en mémorisant tes 2 valeurs dans 2 variables distinctes : - id - value (tu les nommes différemment si tu préfères) Du coup pour la mise à jour via l'API : /api/callAction?deviceID=267&name=setVariable&arg1=id&arg2=131 /api/callAction?deviceID=267&name=setVariable&arg1=value&arg2=21.0 Keep it simple....

Oui d'ailleurs pas la peine de redéclarer une variable arg, tu peux utiliser directement la pseudo variable {...} Exemples : local function une_autre_fonction(...) for k, v in pairs({...}) do end end local function fonction_principale(...) une_autre_fonction(table.unpack({...}) end

La variable prédéfinie args existait dans les anciennes versions de LUA il me semble... je ne sais plus en détail. Sur HC2, c'était genre LUA 5.2 dans les scènes, et LUA 5.1 dans les VD... il me semble. Mais sur HC3 on est en LUA 5.3, ça c'est sûr, et il faut bien utiliser la syntaxe avec les accolades {...}

La concaténation d'un string avec un number donne toujours un string (le LUA fait automatiquement le tostring() sur le number), donc c'est normal. Si par contre tu faisais ça : local IdDevice = 258 self:setVariable(IdDevice) Alors c'est bien un number qui serait stocké dans la variable du QuickApp. Même si là encore, ça ne pose aucun souci à l'API qui le gère très bien, à l'inverse l'interface Web n'aime pas.

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...