Lazer

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.

Non la Téléinfo c'est un cas particulier, je te l'ai déjà dit, et c'est documenté en 1ère page. Ce que tu devrais pouvoir faire, dans l'EcoDevice, c'est associer ta production solaire à un sous-poste dédié, ainsi tu pourras facilement aller chercher ce sous-poste avec le QuickApp. Note que c'est purement théorique, je n'ai pas de production chez moi, je ne peux pas reproduire...

Oui il manque une virgule avant le power

Oui c'est compliqué, comme je l'ai mis en avertissement dans le tuto, la bonne configuration nécessite une bonne compréhension du fonctionnement de l'EDRT2 (ou IPX800) et de la HC3, tant les possibilités sont nombreuses. Il faut se creuser un peu la tête, mais les possibilités sont quasi infinies. Surtout quand tu veux faire interagir cela avec DomoCharts ou d'autres QuickApps. Je viens de me rendre compte qu'il n'y a pas d'entrées virtuelles sur l'EDRT2 (c'est uniquement sur IPX800) Mais c'est pas grave, tu peux utiliser n'importe quelle sortie virtuelle ou entrée numérique que tu n'utilises pas. Il y a les liens vers l'API GCE en première page, donc tu peux voir toutes tes sorties virtuelles avec l'URL suivante : /api/xdevices.json?key=apikey&Get=VO Il n'y a rien à configurer, elles existent déjà, et tu ne les utilises pas vu que tu ne semble pas savoir ce que c'est. Donc il suffit de prendre la première.... ou mieux, la dernière, comme ça tu es certain de ne jamais l'utiliser pour de vrai Donc au final un truc dans ce genre là : {device = {name = "APsystem", type = "BinarySensor"}, value = {command = "Get", argument = "VO", pin = "VO128", formula = function(value) return not value end} power = {command = "Get", argument = "P", pin = "INSTANT_POSTE4", formula = function(x) return tools:round(x*1000, 0) end}}, Tu noteras que j'ai mis une formule d'inversion sur la value de la sortie virtuelle 128, c'est juste pour faire joli et que le capteur binaire apparaisse actif dans l'interface de la HC3. Tu n'as plus qu'à mettre une icône avec un appareil allumé et courant qui passe, et ça sera joli.

J'y pense, tu devrais regarder du coté de l'API fibaro:callGroupAction() qui est assez méconnue, ça irait peut être plus vite. C'est d'ailleurs peut être celle qu'utilise Homebridge.

Non les VD, Scènes, et QuickApps sont mono-threadés chez Fibaro. Petite particularité, les scènes sur HC2 : on peut déclencher simultanément jusqu'à 10 instances d'une même scène, ce qui équivaut à 10 processus différents au niveau de l'OS. Mais attention je dis bien processus, et non pas thread, puisque chaque instance de scène est totalement indépendante des autres et a son propre espace mémoire. En résumé, pas de programmation multithread en LUA sur les box Fibaro, et c'est pas plus mal, c'est bien pénible à synchroniser.... Cela dit, je ne sais pas à quoi ressemble ta scène, mais il y a peut être moyen d'optimiser ta boucle pour déclencher les ordres Z-Wave plus rapidement. Un enchainement de fibaro.call() ça va vite... Mais autre souci derrière çà, c'est le protocole Z-Wave, qui ne permet de toute façon pas d'envoyer simultanément plusieurs trames. Les trames sont forcément envoyées en séquence. Par ailleurs, je suppose que le contrôleur (HC2) gère cela au mieux possible pour éviter les collisions de trames et donc la saturation du réseau Z-Wave..... donc la box attends probablement quelques millisecondes entre les envois d'ordres différents vers les modules.... surtout que pendant ce temps là, la box continue de communiquer avec d'autres modules (les relevés de température, consommation électrique, etc) Peut-être même qu'elle attend le retour d'état du premier module avant d'envoyer l'ordre au 2nd module, ainsi de suite... En association direct, je suppose que la télécommande ne se pose pas toutes ces questions, et puis pour éviter de bouffer trop vite les piles, il faut rester éveillé le moins longtemps possible, donc j'imagine bien la télécommande qui envoie tous les ordres en série sans attente entre chacun, puis se rendort bien vite... et tant pis si le réseau sature. Simples suppositions, il faudrait un sniffer Z-Wave pour étudier cela plus en profondeur.

Hum, je n'avais pas pensé à cette utilisation du GoTo, merci pour l'idée (encore une fonction qu'il faudra que j'ajoute dans le QA donc)

A mon avis Bloug parlait de faire cohabiter 2 robots sur la même station de vidage. Cela dit, si chaque robot est à un étage différent, je ne vois pas l'intérêt. Prochaine étape, l’assesseur à robot Ou le robot-drone. Ou le robot sur pâte.

En fait, si on peut bien remonter toutes les valeurs de puissance de l'Eco-Device, c'est bien là tout l'intérêt de mon QA. C'est juste que je n'avais pas pensé à remonter les puissances seules, car chez moi toutes les consommations correspondent à un device existant (comme dit, des Binary switch principalement, mais pas que). Et encore, faut que je fasse attention à la façon dont je le dit, car on peut bien les remonter, c'est juste que si on les mets dans la "value" d'un device, elle n'est pas pris en compte par DomoCharts. Pour le warning du "value" manquant, oui c'était prévisible. Sinon la solution serait d'utiliser simplement des PowerSensor, mais tu vas râler parce que ça ne remontera pas dans Domocharts. Encore une fois, tu es dans un cas de figure auquel je n'avais pas pensé. En fait, avec ce QA et DomoCharts, j'ai surtout essayé de coller au plus proche de la philosophie de Fibaro avec la HC3. - value = la valeur de device - power = sa puissance électrique consommée - energy = son énergie électrique cosnommée Cette règle est applicable à tous les modules (Z-Wave ou non) Sinon tu peux tricher, par exemple définir un BinarySensor avec une valeur bidon (une entrée numérique virtuelle de l'éco-device) qui sera toujours sur ON, et tu lui attribues le power avec tes étiquettes INSTANT_POWER Et tu devrais avoir le résultat voulu. Je pense que c'est la meilleure solution dans ton cas. D'ailleurs, tricher, c'est ce que j'ai fait avec le type spécial Teleinfo, qui est de type "com.fibaro.powerSensor", et les propriétés suivantes : - value : la puissance apparente en VA directement remontée par le compteur Enedis, information assez peu pertinente à conserver, et ignorée par DomoCharts. Cela dit l'exploiter en temps réel est utile dans un scénario de délestage en cas de surconsommation - power : la puissance active en W, c'est celle qui nous intéresse => relevé par DomoCharts - energy : l'index du compteur en kWh => relevé par DomoCharts Pour les 3 phases de ta production solaire, là c'est encore autre chose. Soit l'Eco Device te permet de les additionner (avec des sous-postes dans un poste tu dois pouvoir le faire) Soit tu laisses le QA GCE te remonter les 3 valeurs indépendantes, puis tu crées ton propre QA qui fait la sommes des 3 autres.

Euh.... c'est quoi cet énervement ? Et j'aimerais bien savoir où j'ai proposé à quelqu'un de me contacter en MP, je me suis toujours refusé d''apporter du support sur la HCL, c'est un pot de pus ce truc là. (EDIT : surement sur un autre sujet) Tu es bien l'un des rares à qui je réponds à ce sujet. Bref, désolé pour toi si le support Fibaro n'est pas à la hauteur, tu ne seras pas le premier à qui ça arrive.... si tu as cherché sur le forum, tu as dû voir le nombre de gens qui s'en plaignent. Cette HCL a un hardware totalement sous-dimensionné (CPU/RAM), et visiblement instable de plus d'après les nombreux retours sur le forum, il y a vraiment peu de choses que les nous autres utilisateurs finaux puissions faire...

C'est normal, DomoCharts cherche la puissance électrique consommée dans la propriété power des modules, mais avec ta config, tu as dis au QA GCE de mettre cette information dans la propriété value. Du coup la propriété power n'est pas mise à jour.... et je pense qu'elle n'existe tout simplement pas, car tu as créé un multilevelSensor. Tu peux le vérifier dans le JSON de ton module enfant 406 Pour mettre la conso électrique au bon endroit, il faut placer ton étiquette INSTANT_POSTE4 dans la rubrique power = { ... } de ta ligne de config Reste que je ne sais pas quoi te proposer d'utiliser comme device de base.... à vrai dire je n'avais pas trop envisagé la possibilité de remonter une consommation électrique "sans rien", dans ma config toutes les consommations électriques sont associées à un module, de type Binary switch par exemple

Puisque tu sembles désespéré, que tu insistes et que tu cries à l'aide partout, je vais te donner mon avis : la HC Lite est un attrape nigaud, cette box n'aura jamais dû exister. Je l'ai déjà écris à plusieurs reprises partout sur le forum. Je ne sais bien sûr pas t'aider, et si tu ne trouves personne pour cela, alors fait jouer le SAV auprès de ton revendeur, ou directement de Fibaro : support@fibaro.com

Intéressant. Tu peux créer un tuto dans la rubrique adéquate, tu auras plus de visibilité : https://www.domotique-fibaro.fr/forum/120-quick-app-developpeur/