Lazer

J'ai constaté ça aussi. Mais pas remise à zéro, mais remise à .... une valeur arbitraire... très faible ! C'est très étrange. Je n'ai pas d'explication. Il doit manquer les captures d'écran alors, parce qu'en effet, je ne vois rien Pas de souci sur ma box, elle calcule bien les cumuls journaliers, hebdo, etc : Bon par contre il y a un gros bug, car elle calcule un total à 185 kWh tandis que la valeur du module est de 7145 kWh Mais je pense que c'est parce que j'ai recréé ce module enfant récemment, donc le calcul interne de la box est faussé. Je viens de m'en rendre compte suite à cette discussion, vu que je n'utilise pas ces écrans, je fais mon suivi dans DomoCharts et Grafana. Dans le panneau d'énergie aussi les calculs se font bien, même si je ne suis pas fan de la présentation (je ne n'utilise pas vraiment) :

Essaye peut être en http simple, dans le "s" Perso je ne me connecte qu'en local, en direct sur l'IP, je ne passe jamais par home.fibaro.com Si j'ai besoin de m'y connecter à distance, je monte mon VPN et je me connecte en local, sur l'IP.

Ni l'un ni l'autre. La bonne réponse : le support est complètement noeuneud

Welcome to the forum

Je ne sais pas trop... dans le doute je posterais dans la section du firmware stable : https://forum.fibaro.com/forum/1501-update-5140/

Par contre, ce qui est bien possible, c'est que ça soit la réponse du site Web qui fasse bugger ladite fonction... mais nous n'avons pas les moyens de débugguer ce qui se passe dans les librairies LUA mises à disposition par Fibaro. A noter qu'entre les QA et les Scènes ce n'est pas la même version de LUA... si tu es motivé ça vaut le coup de tester si le comportement est identique.

Tu dits que la variable response de la fonction de callback success() est malformée, puisque c'est normalement une table qui contient les 3 variables suivantes : status, data, et headers Vu que status ne contient pas la valeur attendue, c'est donc un bug de cette fonction mise à disposition par la box Fibaro. Si le bug venait du site Web en face, le status serait correct (ou contiendrait une autre valeur que 200, mais sous forme de code HTTP valide : 404, etc), et ce serait la variable data qui serait mal formée.

C'est très étrange... je ne pense pas avoir jamais vu ça. Tu es en firmware stable ou beta ? Ouvre peut être un dossier auprès du support Fibaro, ça ressemble à un gros bug dans la fonction http:request()

c'est pour ça que je t'ai conseillé de faire un reset des modules. c'est différent de exclusion/inclusion. Oui c'est une grosse contrainte. Si HA reste ton "superviseur" général de la domotique, c'est probablement la meilleure solution. Si en revanche tu ne souhaites garder qu'une seule HC3 pour être le point de contrôle générale de la domotique, et si le mode passerelle ne te donne pas satisfaction, tu devrais peut être utiliser le QA "All-in-One" qui t'a été proposé sur le forum officiel. Car son but est de faire remonter des modules provenant de n'importe quelle autre box, y compris HC2, ce qui est pratique pour les migration / intégration hétérogène de box Fibaro. Je ne pourrai pas t'aider car je ne l'utilise pas, mais ça semble assez bien suivi et documenté par son auteur.

Quoi exactement ? Car tu cites 2 lignes distinctes : La première c'est la tension au niveau de l'Envoy, facile. La seconde, c'est les données de production remontées par les micro-onduleurs et agrégées par l'Envoy (elle fait juste la somme je pense). C'est du "lifetime", absolument pas limité à 3 jours. D'ailleurs chez moi vu que j'ai installé la pince environ 1 mois après les micro-onduleurs, j'ai une énergie produite par les micro-onduleurs supérieure à celle comptabilisé par la pince, forcément. Remarques complémentaires : les données provenant des micro-onduleurs ne sont rafraichies que toutes les 5 minutes, limitation CPL lors du passage en firmware D7, le compteur d'énergie des micro-onduleurs a mystérieusement diminué... encore un bug ? Pas très important, car je fait le suivi de ma prod dans DomoCharts jour par jour, mais c'est mystérieux. j'avais lu quelque part (forum, doc Enphase... ????) que les mesures effectuées par les micro-onduleurs sont approximatives. La pince est plus précise, et je peux le confirmer, car j'ai un autre mode de comptage (compteur DIN à impulsion) qui est plus proche de la pince. Ben ça tu les renommes comme tu veux, bien sûr, c'est ce que j'ai fait aussi. C'est natif dans l'interface Web de la HC3 ça, pas besoin de modifier le code LUA. Idem, tu changes les icônes comme tu veux. Par défaut la HC3 propose une icône en forme d'éclair pour tout ce qui concerne les modules de type "électrique" au sens large, c'est déjà mieux que rien. Mouais, alors pour ça, il faut modifier le code LUA, et plus gênant encore, l'application mobile le gère très mal, c'est un coup à se retrouver sans icône, j'ai le cas avec mon QA Kodi. Je suis pas chaud pour faire cette modif du coup... Et dans l'appli mobile, depuis qu'il y a le dashboard de suivi de production, on a une vision claire de ce qui rentre/sort, qui se base sur le panneau d'énergie de la HC3. Et en plus il sait agréger les données provenant de plusieurs sources (dans mon cas, prod Enphase et APsystems, conso EDRT2). C'est juste top ce qu'à fait Fibaro sur ce coup là. Rare moment où la production = consommation (couverture nuageuse) : Bon du coup j'ai répondu plus haut. Je précise quand même : "inverter" ça signifie "onduleur" en anglais, au cas où J'ai pas mis "micro" pour pas que ça fasse trop long.... mais après comme dit, tu renommes comme tu veux. Et si ce module enfant ne t'intéresse pas, tu le caches, voire sur le supprimes. Non, la HC3 n'a besoin que des cumuls d'énergie. C'est elle qui fait ensuite les calculs horaire, journalier, mensuel, etc. C’est comme ça pour tous les modules qui remontent des informations de consommation énergétiques (modules Z-Wave, etc) Je suis sur 5s pour plus de réactivité lors du passage d'un nuage (pour la calcul du surplus pour la borne de recharge VE), j'ai des déconnexion aléatoires mais très rares, donc ce n'est pas un souci en pratique. La déconnexion n'arrive qu'une fois tous les quelques jours, et ça dure 2 minutes, donc pas gênant en pratique, je me suis juste interrogé sur l’apparition de ces déconnexions en D7 alors que je n'en avais jamais eu en D5. Alors, oui j'ai laissé la valeur négative, et c'est voulu, car c'est la mesure de la pince, qui compte le courant dans les 2 sens. A priori les MO ne consomment rien, car ils tirent leur énergie pour fonctionner depuis la tension DC provenant des panneaux... donc en journée seulement, ils sont éteints la nuit et ne communiquent pas avec l'Envoy. Ce que tu mesures, ça doit être la consommation des Q-Relays. Par contre je suis surpris de tes 14W de conso, c'est beaucoup ! Avec 2 Q-Relays, je suis entre 4 et 5W de conso la nuit. Si tu veux mesurer zéro, il faut installer la pince sur les fils de phase qui partent vers les MO, donc après les Q-Relays.

Alors ça c'est curieux, car non seulement ce n'est jamais arrivé en D5, mais en plus j'avais justement 2 accès concurrents.... par mes 2 box domotiques ! Voyant ce problème en D7, j'ai justement pensé à cette histoire d'accès concurrents.... du coup j'ai désactivé le QA sur ma box de test, mais ça n'a rien changé. Mais box de prod est la seule à interroger l'API de l'Envoy, et pourtant le bug se présente de temps en temps... aléatoirement...

Depuis le passage forcé en firmware D7, ma passerelle Envoy-S est injoignable de temps en temps, alors que ça n'arrivait jamais avant avec le firmware D5 : ça revient tout seul 2 minutes plus tard, sans rien faire. Peut être un reboot automatique, un bug, ou autre ? Je ne sais pas. A moins que ça ne soit une manifestation du firmware hyper stable et testé en long en large et en travers par Enphase avant le déploiement mondial dont parlait Nico sur l'autre topic il y a quelques jours Bref, c'était mieux avant

Hum.... oui ça doit être possible, mais ça me ferait faire quelques modifs du code.... que je ne ferai pas tout de suite. Perso je fonctionne différemment, car j'ai un besoin similaire (mais différent). J'ai un autre QA, qui utilise une boucle refreshStates, donc à déclenchement instantané, et qui prend en trigger les ID provenant de différents QA : Enphase (prod solaire), mais aussi GCE EDRT2 (conso réseau), et chauffe-eau. Le but du jeu c'est de calculer le "surplus" disponible, c'est à dire l'injection virtuelle en soustrayant la conso du chauffe-eau, ce dernier étant automatiquement chauffé par le routeur solaire qui mesure l'injection en temps-réel via une pince sur l'arrivée Enedis. Ainsi je génère un module de type powerMeter qui permet de démarrer/arrêter mes bornes de recharge de véhicule électrique. En synthèse, ça donne la priorité à la charge véhicule par rapport à la chauffe de l'eau. L'avantage d'un QA dédié, c'est que je suis indépendant des ID de modules utilisés en entrée, qui peuvent provenir de plusieurs QA différents, et surtout je peux "manipuler" la puissance réelle injectée pour en déduire le surplus. On peut tout imaginer... The sky is the limit comme disent les angliches. Cela dit, vu que Enphase donne le total-consumption et le net-consumption, je me demande si l'un des 2 ne répond déjà pas nativement à ton besoin ? A vrai dire je n'ai pas trop saisi lequel des 2 donne quoi, vu que je n'ai pas pu installer la pince de conso pour expérimenter.

Pourquoi tu en as deux ?

QuickApp APsystems ECU Version 1.00   Présentation :   Ce QuickApp permet de remonter les informations de production photovoltaïque des micro-onduleurs APsystems (DS3, DS3-L, etc...) via la passerelle ECU. Il a été testé avec une passerelle ECU-C et utilise le protocole de communication propriétaire utilisé par l'application mobile sur le port local 8899 de la passerelle. Il devrait théoriquement également fonctionner avec la passerelle ECU-R car elle dispose d'un port Ethernet, et peut-être aussi la passerelle ECU-B, à tester. De base il remonte les informations suivantes :  1 module de type powerMeter : Puissance instantanée totale de tous les micro-onduleurs (en W) 1 module de type energyMeter : Énergie cumulée produite (en kWh) Pour chaque micro-onduleur détecté, il remonte également les informations suivantes : 1 module de type temperatureSensor : Température interne de l'onduleur (en °C) Pour chaque panneau connecté à un micro-onduleur, il remonte également les informations suivantes : 1 module de type powerMeter : Puissance instantanée produite par le panneau (en W) 1 module de type electricMeter : Tension mesurée (en V) Le QuickApp met à jour les informations toutes les 5 minutes, c'est une limitation liée à la technologie radio Zigbee utilisée pour la communication entre les micro-onduleurs et la passerelle ECU. Note : la passerelle a tendance à planter occasionnellement. Le QuickApp est prévu pour le détecter et redémarrer automatiquement celle-ci en cas de besoin, et est visible dans le log : Installation du QuickApp :  Importer le QuickApp (fichier fqa) de façon habituelle sur la box Home Center 3, puis changer les paramètres suivants dans l'onglet Variables :  Configurer les variables comme suit : Address : adresse IP de la passerelle Envoy, par exemple : 192.168.1.1 Port : port de communication, normalement : 8899 Création des modules enfants :  Cliquer sur le bouton "Create devices". Les modules enfants sont automatiquement créés dans l'interface.  Les appuis suivants sont inutiles, et sans danger, car les modules enfants ne seront pas créés plusieurs fois.  Icône : Téléchargement : Nouvelle installation : importer le fichier suivant pour créer un nouveau QuickApp : APsystems_v1.00.fqa

Euh.... d'accord c'est bien, mais il faudrait peut être mettre ton message à la suite de la discussion non ? Parce que là tout seul, on peut se demander de quoi tu parles... EDIT : j'ai retrouvé et fusionné ton topic initial.

Pas de chance... Je ne sais pas répondre à toutes tes questions, mais je te suggère ceci : faire un reset complet des micro-modules. En effet, parfois l'exclusion/inclusion ne suffit pas. Voir la doc pour la procédure de reset. Il faudra évidemment réinclure les modules à l'issue de l'opération Concernant le mode passerelle, soit tu n'as pas compris ce que ça fait, soit je n'ai pas compris ce que tu as fait. Mais le mode passerelle permet justement de créer 2 réseaux distincts, pas 1 seul. On en avait parlé il me semble. Chaque réseau est situé près (= autour = proche) de chaque box qui agit comme autant de contrôleurs Z-Wave principaux distincts. Ensuite le mode passerelle permet de tout gérer depuis un point unique, la box dite "maitre" : A ne pas confondre avec l'inclusion d'une seconde box en tant que contrôleur Z-Wave secondaire, à ne pas utiliser sauf pour des cas très précis : Si tu as bien utilisé le mode maitre/esclave avec 2 réseaux Z-Wave distincts, c'est bien. Mais comme évoqué sur le forum officiel, si tu es en firmware beta, tu te mets en situation à risque. Déjà qu'historiquement, même dans les versions stables, depuis que la HC3 est sortie le mode passerelle semble avoir toujours été quelque peu buggué. Disons plutôt qu'un certain nombre de fonctionnalités ne fonctionnent pas toujours. En tout cas c'est ce que j'ai constaté en survolant les messages du forum officiel.... puisque je n'ai jamais testé avec HC3, seulement des HC2 il y a pas mal d'année. Essaye de contacter le support Fibaro, parfois ils ont inefficaces, mais parfois ils sont efficaces... avec un peu de chance ils identifieront ton problème.

J'ai édité le premier paragraphe du tuto pour préciser les modules enfants créés, ainsi qu'une petite note pour expliquer la distinction MO / Pinces concernant l'énergie et la puissance. J'espère que ça sera plus clair. La tension est mesurée par la passerelle elle-même, puisqu'elle est connectée au réseau électrique. Pas nécessairement au même endroit que les Q-Relay et micro-onduleurs, qui sont souvent quelques centimètres, mètres, voire décamètres, plus loin. J'ai 2 Q-Relay pour protéger mes 16 micro-onduleurs, mais peu importe, puisque ceux-ci ne remontent aucune information, c'est bien la tension de la passerelle qui est utilisée. En tout cas c'est ce que j'ai constaté sur l'API de l'Envoy-S, vu que ce n'est pas vraiment documenté... Chez moi j'ai pu installer la pince de production, mais pas la pince de consommation... donc certains des modules enfants que ce QA va créer n'existent pas chez moi. J'espère qu'ils fonctionneront bien.

Oui c'est clair. Parfois le choix est tellement restreint qu'il ne reste plus qu'une seule marque. Il faut voir le bon coté des choses, quand on hésite entre plusieurs produits aux caractéristiques similaires, au moins ça simplifie le choix Et justement j'ai eu le cas récemment lors du choix de ma pompe à chaleur. Au final j'ai retenu Mitsubishi car les unités sont livrées avec un port sur la carte mère permettant d'y connecter un ESP32 connecté en Wi-Fi sur le réseau, avec API locale, et qui laisse fonctionner le cloud constructeur de son coté. Du coup chaque split a 2 adresses IP, c'est un peu délirant, mais au moins j'ai le contrôle local, et avec retour d'état ! Exit Daikin, sans regret. Puis quand il n'y a pas le choix... ben.... peut être qu'il faut se dire que le mieux est de ne rien acheter, car en fait on n'en a juste pas besoin Y a quand même un produit majeur, dont à ma connaissance aucun constructeur ne propose d'API locale : la voiture. Mais bon... intrinsèquement, une voiture c'est mobile, du coup.... on est bien obligé de passer par Internet.

Pas de gros bug corrigé, ni de nouvelles fonctionnalités importantes.... ça reste une mise à jour mineure

Et voici enfin mon QuickApp Enphase :

QuickApp Enphase Envoy Version 2.00  Présentation : Ce QuickApp permet de remonter les informations de production photovoltaïque des micro-onduleurs Enphase (IQ7, IQ8, etc) via la passerelle Envoy. Il a été testé avec une passerelle Envoy-S Metered et les firmware D5 et D7. Il utilise l'API non documentée HTTP locale, mais depuis le firmware D7.xx a besoin d'un Token généré sur le site Web d'Enphase. Il est capable d'aller chercher automatiquement le Token sur le site d'Enphase, et d'en faire une nouvelle demande en cas d'expiration de celui-ci. Par précaution, il mémorise ce token dans une variable du QA pour le réutiliser lors du prochain redémarrage du QA au cas où le Cloud Enphase serait indisponible à ce moment-là. De base il remonte les informations suivantes : 1 module de type electricMeter : Tension mesurée au niveau de l'Envoy (en V) 1 module de type energyMeter avec interface supplémentaire power : Production remontée par les micro-onduleurs : Énergie (en kWh) et Puissance instantanée (en W) Si la pince ampèremétriques de production est installée, il remonte également les informations suivantes : 1 module de type powerMeter : Puissance instantanée produite (en W) 1 module de type energyMeter : Cumul de l'énergie produite (en kWh) Si la pince ampèremétriques de consommation est installée, il remonte également les informations suivantes : 1 module de type powerMeter : Puissance instantanée totale consommée (en W) 1 module de type energyMeter : Cumul de l'énergie totale consommée (en kWh) 1 module de type powerMeter : Puissance instantanée nette consommée (en W) 1 module de type energyMeter : Cumul de l'énergie nette consommée (en kWh) Par défaut le QuickApp met à jour les informations d'énergie toutes les 5 minutes, et de puissance et tension chaque minute (60 secondes), mais le QuickApp est capable d'interroger plus souvent la passerelle (quelques secondes), et des variables permettent de configurer des déclencheurs afin de mettre à jour instantanément la valeur des modules enfants, ce qui peut être utile dans des scénarios de maximisation du taux d'autoconsommation, afin de réagir rapidement en cas de passage d'un nuage ou du retour du soleil. Note : les informations de production remontées par les micro-onduleurs ne se font que toutes les 5 minutes (limitation liée à la technologie CPL utilisée pour la communication avec la passerelle). C'est donc l'utilisation des pinces ampèremétriques qui permet la remontée rapide des informations. De plus, la mesure par les pinces est plus précise que la mesure intégrée aux micro-onduleurs. Installation du QuickApp :  Importer le QuickApp (fichier fqa) de façon habituelle sur la box Home Center 3, puis changer les paramètres suivants dans l'onglet Variables :  Variables requises : Protocol : protocole à utiliser, normalement : http Address : adresse IP de la passerelle Envoy, par exemple : 192.168.1.1 Port : port de communication, normalement : 80 User : adresse email de l'utilisateur enregistré sur le Cloud Enphase pour l'obtention du token Password : mot de passe de l'utilisateur RefreshInterval : intervalle d'interrogation de la passerelle en secondes, par exemple : 10 (je tourne personnellement avec 5 secondes car j'exploite les variables optionnelles décrites ci-dessous) UpdateInterval : intervalle de rafraichissement de la tension et puissance en secondes, par exemple : 60 (valeur par défaut, suffisante pour suivre la production sans avoir besoin de réactivité extrême) EnergyInterval : intervalle de rafraichissement de l'énergie en secondes, par exemple : 300 (les statistiques d'énergie sont utiles pour suivre la production sur la journée, semaine, mois, année, il n'est donc pas nécessaire de descendre cette valeur) Variables optionnelles qui permettent de régler finement la réactivité du QuickApp pour la mise à jour des puissances instantanées : ProdVarUp : Production Variation Up : variation à la hausse de la production en %, par exemple : 101 (doublement de la puissance) ProdVarDown : Production Variation Down : variation à la baisse de la production en %, par exemple : 51 (division par 2 de la puissance) ProdThresUp : Production Threshold Up : seuil en montée de la production en W, par exemple : 2000 ProdThresDown : Production Threshold Down : seuil en descente de la production en W, par exemple : 1500 ConsVarUp : Consumption Variation Up : variation à la hausse de la consommation en %, par exemple : 101 (doublement de la puissance) ConsVarDown : Consumption Variation Down : variation à la baisse de la consommation en %, par exemple : 51 (division par 2 de la puissance) ConsThresUp : Consumption Threshold Up : seuil en montée de la consommation en W, par exemple : 2000 ConsThresDown : Consumption Threshold Down : seuil en descente de la consommation en W, par exemple : 1500 A noter que lorsque les variables optionnelles sont configurées, en plus de permettre une mise à jour rapide des modules enfants, vont également émettre des Custom Events dans la box, qui peuvent être interceptés par des scénarios (Scènes, GEA, etc) : Enphase_Production_Variation_Up Enphase_Production_Variation_Down Enphase_Production_Threshold_Up Enphase_Production_Threshold_Down Enphase_TotalConsumption_Variation_Up Enphase_TotalConsumption_Variation_Down Enphase_TotalConsumption_Threshold_Up Enphase_TotalConsumption_Threshold_Down Enphase_NetConsumption_Variation_Up Enphase_NetConsumption_Variation_Down Enphase_NetConsumption_Threshold_Up Enphase_NetConsumption_Threshold_Down Création des modules enfants : Cliquer sur le bouton "Create devices". Les modules enfants sont automatiquement créés dans l'interface.  Les appuis suivants sont inutiles, et sans danger, car les modules enfants ne seront pas créés plusieurs fois. Icône : Téléchargement : Nouvelle installation : importer le fichier suivant pour créer un nouveau QuickApp : Enphase_v2.00.fqa Fichiers individuels : Enphase v2.00 - Main.lua Library - Enphase v2.00.lua Library - tools v2.30.lua

Bienvenue sur le forum

Voici GEA version 7.38 : cette version reprend essentiellement les correctifs aux différentes remarque remontées ici durant ces derniers mois (années) Correction de la comparaison de valeurs numériques décimales Amélioration de la fonction de contrôle de l'option "QuickApp" Amélioration de la fonction de contrôle de l'option "Sleep" Correction de la vérification des ID pour "Breached ", "SetArmed" et "SetDisarmed" Correction du plantage en cas de liste d'action vide {} L'action "Call" peut maintenant être utilisée avec un ou plusieurs ID de modules (les mêmes arguments seront envoyés à tous les modules, donc attention à bien lister uniquement des modules identiques) Correction de la faute "doesn't exists" par "doesn't exist " Correction du formatage "Mémoire utilisée ..." Pour la mise à jour, copier/coller le contenu des fichiers LUA : Fichier main : GEA v7.38.lua Fichier tools : Library - tools v2.30.lua Doc de syntaxe à jour : GEA v7.38 Syntaxe.lua QuickApp complet pour une nouvelle installation disponible en première page.

Oui surement. Après comme je disais au dessus, ils n'ont apparemment pas encore activé le compte à rebours, donc espérons que ça dure....