Lazer

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/

Ce n'est pas possible (enfin c'est possible via un hack sur la page web, mais pas sur l'application mobile, donc autant dire que c'est impossible) La meilleure solution est d'utiliser des Emojis, que tu peux coller directement On en parle là : Ou là : Et encore là : Et surement encore ailleurs.

Essaye avec ceci : {device = {name = "Eau Froide", type = "MultilevelSensor", unit = "l"}, value = {command = "Index", argument = "C", pin = "Index_C1"}}, {device = {name = "Eau Chaude", type = "MultilevelSensor", unit = "l"}, value = {command = "Index", argument = "C", pin = "Index_C2"}}, Je pense que ça corrigera à la fois les Warnings dans le QA GCE, et ça devrait permettre à DomoCharts de collecter les données.

Bienvenue sur le forum Ton pseudo (et avatar) me laisse penser que tu n'as pas correctement suivi le processus d'inscription du forum, il doit y avoir un lien à cliquer dans un email à recevoir pour activer le compte. Les mails ont du retard sur le forum depuis quelques semaine, il faudra peut être que tu retentes plus tard.

Ben je sais pas, j'ai pas eu de freeze moi, comme dit, un coeur a été saturé pendant plusieurs heures mais la box fonctionnait normalement.

Ce qui est curieux c'est que ça s'est produit à un moment où je n'utilisais pas la box, c'est à dire que je n'étais pas connecté dessus, en train de développer, etc. Et j'ai bien regardé les logs de mes QuickApps, ils avaient l'air de tous fonctionner correctement. Les informations d'utilisation de chaque cœur sont déjà mémorisées dans la base de données par DomoCharts. Ce qui est nouveau, c'est le graphique personnalisé pour l'afficher. Mais c'est un truc bricolé à l'arrache, je ne sais pas si c'est vraiment partageable, je pense qu'il sera préférable d'afficher ça proprement dans Grafana... quand je me remettrai dessus (donc pas tout de suite) Le calcul du maxi peut effectivement être plus ancien, le graphique n'affiche que 7 jours par défaut, mais les données sont conservées un peu plus longtemps. Tout cela est paramétrable dans config.inc.php.

Drôle de comportement de mon HC3 hier, elle fonctionnait très bien (réactive et tout), mais le graph CPU montre une charge à 27% pendant plusieurs heures : Ça correspond à 1/4 de le capacité CPU, et sachant qu'il y a 4 cœurs dans le processeur, je vais donc voir le détail par cœur, et c'est bien 1 seul cœur saturé à 100%, mais à tour de rôle : Au final c'est un reboot qui a solutionné le problème. Donc c'était certainement un processus au niveau de l'OS (Linux) qui était parti dans une boucle infinie, mais lequel ? A priori tous mes QuickApps fonctionnaient bien, et mes quelques 9 modules 2-Wave avaient l'air de communiquer correctement. Étrange....

De mon coté je n'ai pas eu de souci de module non-configuré, je l'ai inclus il y a longtemps, et depuis cette télécommande fonctionne très bien. C'est un module sur batterie, donc il faut prendre soin de l'inclure en étant à coté de la box, et de la réveiller si nécessaire (c'est à dire si le process d'inclusion tourne en boucle sans avancer)

Bienvenue sur le forum

Ah ben c'est une bonne nouvelle alors. Pour l'intervalle de polling, c'est normal de l'augmenter, comme sur la HC2. Mais je n'ai pas encore assez de module sur HC3 pour ma part, sinon essaye de la rebooter peut être .

J'ai mon tout premier module RGBW, sur la HC2, qui présente le même symptôme, il n'a jamais voulu se mettre à jour, et la notification revient sans cesse. J'avais espoir que lorsque je migrerai sur HC3 je pourrai le mettre à jour, mais ton expérience ne me rassure pas... tant pis, ça restera ainsi.

Bravo

D'accord, c'est donc ça que tu utilises. Il faudra que je l'ajoute... J'attends donc ton retour sur le fonctionnement actuel du QA avant de faire une nouvelle version

Faut regarder dans les paramètres du module, mais je pense que ce n'est pas possible, en Z-Wave le retour d'état se fait à la fin de l'action, et comme tu le dis, c'est bien logique.