Lazer

Je répond à l'envers (mais y'a une certaine logique) Réponse 2 : oui la balise </>, et dans la liste déroulante tu choisis LUA pour avoir la bonne coloration syntaxique. Réponse 1 : voilà justement, tu raisonnes encore HC2, pour moi sur HC3 la notion de VD (ou QA) récapitulatif, avec tous ses labels, n'a plus vraiment de sens... ce qui amène à la réponse à la question originale : Réponse 0 : je n'aurais pas écris une seule ligne de LUA. En effet, ton module 426 (mis à jour de façon externe par Jeedom) porte déjà l'information dans ses propriétés, et avec la bonne unité en prime, donc tu as tout ce qu'il faut pour l'afficher, ou bien l'exploiter dans les scénarios. D'autant plus qu'il est très facile de lire une propriété d'un module, mais bien plus complique de lire une variable, et encore pire pour un label (et pire encore, celui-ci n'est pas persistant). Ma philosophie c'est d'utiliser au maximum les possibilités natives mises à disposition par la box. Sur la HC3, grâce aux QuickApps correctement typés, on couvre déjà 90% des besoins. Besoins qui n'étaient pas comblés sur HC2, puisque les VD n'étant pas typés, on était contraint de stocker et afficher les informations de manière détournée (des labels et variables globales essentiellement) J'ai un cas de figure similaire au tient, j'ai une instance FHEM qui récolte des informations provenant de divers capteurs EnOcean. Pour chaque capteur, j'ai créé un QA tout simple, du bon type, mais sans aucune ligne de code LUA. Chaque QA voit sa propriété value mise à jour par FHEM via l'API, rien de plus, cela suffit. Je peux voir les mesures directement sur les icônes des QA, sur la page Web, sur l'application mobile, et exploiter ces valeurs dans mes scénarios (GEA quasi exclusivement)

2 fois que tu le dis... comme je disais que un autre topic sur un tout autre sujet, il n'y a bien que l'apparence qui compte kWh tu voulais dire, non ?

Je pense que ça devrait fonctionner, condensé en 1 seule ligne : local value = api.get("/devices/426").properties.value Après tu fais ce que tu veux de la variable value, l'afficher dans un label, etc EDIT : mais pourquoi afficher ça dans un label, alors que ton module 426 a déjà la bonne value ? Tu as juste à lui mettre la bonne unité (en mètres, km, etc), et l'affichage sera juste parfait dans la page web, sur l'appli mobile, etc. EDIT 2 : je n'avais pas vu ton code LUA (pense à utiliser les balises qui vient bien pour l'insérer dans ton post) Donc tu as déjà fait le boulot visiblement.

Tu es quand même très fort pour être le seul à trouver des erreurs inédites @jojo (chat noirs inside ) Je vois un accent "è" dans ton url, ce qui est interdit, c'est probablement la cause.

Jojo tu touches des commissions sur les ventes de HC3 ?

La version de quoi ? De la doc de syntaxe ? Dans ce cas oui, c'est la dernière. Oui il reste surement encore pas mal de fautes dedans, pourtant j'en ai déjà corrigé un certain nombre, mais vu la taille du fichier, je n'ai pas analysé ligne par ligne.

Bravo Tu veux faire un tuto ? Chouette

Pascal, mais le Fronius Smart Meter, il mesure avec une pince non ? A l'intérieur. Après la précision de mesure, entre un Fronius Smart Meter ou un compteur DIN à impulsion, franchement je ne sais pas. Et puis même si il y a 1% de différence, c'est pas ça qui va changer radicalement tes statistiques. Par contre, ne mélange pas tout, je ne t'ai jamais dis d'acheter le MK2PVrouter à souder toi même, je me doute bien que tu ne sauras pas le faire d'autant plus que tout est en anglais. Mais la discussion ne portait pas sur ce produit, mais sur la différence de prix du simple au double entre le Fronius Ohm Pilot et le SmartReducer SA comme te le proposais Nico. Et franchement, devoir installer une pince (en parallèle de ton Smartmeter donc) pour économier 500€, je trouve que c'est un bon deal

En gros il récupère la mesure du courant effectuée par le Fronius Smartmetter, ce qui évite de poser une pince supplémentaire sur l'arrivée Enedis. ça fait cher l'économie des 10 minutes à tirer un câble et poser une pince... m'enfin si tu préfères tout prendre chez le même constructeur, fais toi plaisir Quand je pense que mon routeur m'a couté 180€, la différence est colossale ! Et certains arrivent même à s'en bricoler pour moins de 100€. Aller une bonne nouvelle (ou pas) pour vous rassurer sur le bien fondé d'une installation photovoltaïque en autoconsommation : Électricité : une hausse de 8% en 2023 pour compenser le gel des prix ? C'était tellement prévisible ...

comment te dire poliment.... ? les logs, tout ça... merci EDIT : GEA.debug = true GEA.lldebug = true Avec ça on est bon

Ah oui bonne nouvelle, donc ça vient du module alors. Tu as fais la calibration ? Un velux ça consomme très peu de courant, essaye de diminuer les seuils de détection de puissance dans les paramètres du module pour que la calibration puisse se faire (regarde la doc pour trouver les bons paramètres)

Mouais mais un tuto c'est limite plus long que d'écrire le code LUA.... comme toute documentation, c'est hyper long La librairie tools tu peux l'utiliser si tu veux, mais en fait ça ne va pas aider à t'apprendre la construction d'un Child from scratch. Du coup je me dit que mes QA ne sont pas les meilleurs exemples pour débuter. Le self:initChildDevices c'est documenté par Fibaro, donc aucune surprise à ce niveau là, cela doit impérativement être fait dans le onInit() Par contre le tableau que tu as copié juste au dessus, c'est du pur perso, c'est une table qui me sert à déclarer tout ce que va faire le QA (mettre à jour des propriétés, des variables globales, et entre autre, des child devices (juste la dernière ligne))

Non globalvariables n'existe plus, c'était nécessaire sur HC2 mais inutile sur HC3.

J'ai lu comme toi, mais Enphase de son coté a bien pris soin de ne pas s'engager. Ils disent de le brancher à coté.... et d'allonger les câbles des pinces (mais ça ne résout pas le problème des MO installés trop loin). Bref, c'est au petit bonheur la chance... Bien sûr j'ai tenté de bouger la passerelle après la configuration, en vain, une fois dans la maison, même en direct sur le tableau et au plus proche du départ de la ligne vers le garage, ça ne communique pas.

Hum... en effet.... mais je n'ai pas les clés du site... je te laisse le suggérer à @Yohan qu'on ne voit plus beaucoup par ici.

Oui j'ai eu la même déconvenue.... et même problématique si je veux ajouter des panneaux plus tard sur la maison

j'avais oublié ce détail ! Comme quoi, y'a que l'apparence qui compte dans ce monde, après tout le monde se contrefiche que ça fonctionne.... c'est bien triste

Après tu verras, ça dépend beaucoup de la luminosité. En faisant les simulations, je n'avais pas bien saisi l'importance du rayonnement diffus qui est donné sur PVGIS. Du coup, quand le soleil est caché par un bâtiment, selon s'il fait ciel bleu ou ciel violé léger en haut altitude, la production des panneaux n'est pas du tout la même. Et c'est là que c'est intéressant, la production PV est meilleure quand le ciel est voilé, car cela produit un rayonnement diffus qui vient frapper les panneaux. En revanche, quand le ciel est bleu, quasi aucun rayonnement diffus, donc production inférieure. Evidemment quand le soleil touche en direct les panneaux, c'est l'inverse.

Ok, donc ça revient au même, s'il ne peut pas mesurer l'injection, alors il stoppe tout. Logique.

Ah oui tu avais dû mettre le profil zéro-injection (le truc qu'Enedis demande...)

Ton nouveau fichier "Mes_bidoiuilles" permet juste de séparer une portion du code LUA dans un autre fichier, pour faciliter la maintenance ou l'organisation du code (surtout utiles quand on a plusieurs milliers de lignes), mais n'a absolument rien à voir avec la gestion des modules enfants, qui peut (et j'ajoute "doit") être réalisée dans le fichier principal (main), comme tout ce qui touche directement au QuickApp. Perso j'utilise les autres fichiers pour les fonctions annexes (librairie d'outils, de notification, de communication avec un autre appareil externe, etc) Désolé je n'ai pas trop le temps de t'écrire ton QuickApp (car c'est ce que tu demandes en fin de compte), mais je peux te conseiller de consulter le code des différents QuickApps déjà partagés sur le forum. Il y a aura 90% du code qui ne t'intéresse pas, mais il faut que tu en extraies les lignes utiles pour la gestion des modules enfants. Je peux te conseiller mon QA Onduleur Eaton, qui doit être l'un des plus simples (et je te déconseille le QA GCE qui est le plus complexe du coup...), car il gère des modules enfants, et notamment de température.

C'est un problème "connu" avec cette application, elle est extrêmement gourmande en ressources, donc le système Android la tue prématurément. Tu peux harceler le support Fibaro nuit et jour pour qu'ils recrutent enfin un vrai développeur pour remettre à niveau cette application, car depuis 2 ou 3 ans qu'elle est sortie, c'est une vraie plaie, et on sent bien que Fibaro s'en contrefiche, tous les efforts sont concentrés sur les modules et la box.

Y'a pas de gêne Bon courage dans tes recherches, mais ça devrait être assez facile, surtout que @jojo t'a bien dégrossi le travail en identifiant les contacts à utiliser sur ton portail.

C'est con ça, tu n'avais pas les bonnes dimensions avant la livraison ? Tu as pris quels panneaux du coup, les Trinasolar ?

Euh non au contraire. IQ7+ : Tension de départ min : 22 V Plage de tension de fonctionnement : 16 V - 60 V IQ7A : Tension de départ min : 33 V Plage de tension de fonctionnement : 18 V - 58 V Le IQ7+ démarre plus tôt, et fini plus tard. Y'a pas photo, les IQ7A sont adaptés aux panneaux très puissants et idéalement exposés. Les miens sont mal exposés, les IQ7+ sont adaptés Ils produiront moins (car les quelques watts gagnés le matin et le soir ne compensent pas les watts écrêtés au plus fort de la journée), mais si on prend en compte la différence de cout d'achat, et le fait que ne consomme pas 100% du productible, au final ils sont largement plus rentables.