Lazer

En effet, c'est clair, seul le 1er ID est contrôlé. Merci ça fera un autre correctif à apporter à la prochaine version. Mais en attendant, je pense que c'est sans impact, tant que tes ID sont bons. Et quand bien même le 2nd (ou 3ème...) ID serait mauvais, ça serait sans impact sur le fonctionnement de GEA, vu que le mauvais ID n'existe pas, il demandera à la HC3 d'exécuter une fonction d'un QA qui n'existe pas, donc il ne se passera rien.

HC3 & HC3L - 5.111.48 - BETA - 03/06/2022 Thank you for using our gateway! Be sure to update to the latest version to enjoy new features and improvements. Main features: 1. Completely new and redesigned process of first gateway configuration in WebUi. 2. Added possibility to test newly added Z-Wave devices during first configuration. What's new: Dashboard Added possibility to use Hold (start move) and Release (stop move) actions on buttons in sidebar for roller shutters. Devices Device roles now visible on the Settings/Devices page. Added missing support for devices which works on HC2/HCL platforms. Added channel designation in the target device selector in Z-Wave association configuration. Slider for level change for roller shutter with role "Device without positioning" removed from control dialog in mobile application. Parameter names are now displayed for Z-Wave devices.** Improved virtual power consumption algorithm for Color Controllers. Elero* Improvements in pairing process. JA Pulse device support added. Nice* Changed default devices names to be more understandable. Improved calibration mechanism for BiDi-Shutter and BiDi-Awning. Improved error handling during pairing processes. UI improvements. Improved removal of disconnected devices. Other Device location (room) added to e-mail and push notifications templates. Updated system packages for performance and stability. Profiles Improved saving for actions in profiles. Quick Apps Added support for Headers in Websocket connections. Scenes Added possibility to rename scenes from within the open editor. Safeguards have been added to prevent incorrect values being entered in Scenarios conditions. Performance improvements related to loading elements in Block Scenes. Added translations for modes and actions for thermostats. Z-Wave Added background polling for sleeping devices**. Improved devices adding process. Updated SDK to v7.17.2 for Yubii Home and Home Center 3 Lite. Performance improvements. Bug fixes: Dashboard Redirection to specific device settings not always works correctly. Elero* Issue with controlling Awnings in some cases (reversed states and/or actions). Energy Wrong rounding up the percentage of summary consumption for devices list in Savings tab. Issue with "Rest" graph in Detailed Consumption graph in General Tab if main energy meter is set. Gateway Connection Empty Z-Wave device templates after downloading them from Slave gateway. Network Listing available networks not always works correctly if the currently connected network has poor quality. Nice* Added device summary shows default names instead of configured ones. It is impossible to control old revision of Era Fit BD and Next Fit BD devices. Inconsistent device renaming during adding wizard in case of different protocols. Other Duplicated scrollbar in WiFi search window. Every logging into the system using mobile application generates redundant events to History. Profiles Wrong unit for Sprinklers watering time. Rooms Drag and drop the rooms not always works correctly. Quick Apps Slider ignores min/max values from the API. Scenes Impossible to edit or create scenes using thermostats in Czech language in some cases. Missing favorite positions condition and trigger for Elero devices. Z-Wave ZW300 devices update fails in some cases. Global polling not always works correctly. Known issues: Z-Wave Engine 3.0 Some Z-Wave devices are not fully compatible with the new version of Z-Wave engine. Gateway connection is not available in the new Z-Wave engine version. * - does not apply to HC3L (Home Center 3 Lite) ** - applies only to Z-Wave Engine 3.0

Si, la variable child retournée par createChildDevice() pointe bien sur le module enfant, enfin sa représentation en mémoire (= une instance de l'objet, cf discussion sur le nouveau topic du QA pour les débutants) Tu peux l'exploiter comme bon te semble, mais c'est de courte durée, car au démarrage suivant du QA, la mémoire est perdue. Donc il faut recréer ton tableau de child, d'où mon message précédent, il te faut un moyen d'identifier simplement les child autrement que par leur ID. La variable stockée dans chaque child est le meilleur moyen à mon avis.

Cool Pour l'ID des enfants, ce qu'il faut faire c'est se construire un tableau dynamique des modules enfants, reconstitué à chaque démarrage, afin d'identifier facilement les enfants. De mémoire la doc Fibaro indique de procéder comme cela. Après la façon de le mettre en œuvre varie selon les gens. Perso lors de la création de chaque module enfant, je leur affecte une variable (variable de quickapp, donc visible dans l'onglet idoine du module) qui contient un identifiant unique (la forme de cet identifiant est très variable selon le but recherché... parfois c'est un ID numérique, parfois c'est juste du texte). Puis lors du démarrage du QA, je vais charger cette variable pour chaque enfant, et me construire une table utilisée dans le code LUA.

Génial, bravo et merci J'ai épinglé ton message du coup, il restera en haut de la page de cette section tutoriels. Juste 2 ou 3 précisions : Les "onglets" du QuickApp qui nous permettent d'organiser notre code LUA, sont en réalité appelés des fichiers. Pour les développeurs, c'est exactement comme quand on réalise un programme avec plusieurs fichiers, qui sont ensuite compilés et liés ensemble avant l'exécution. Le QuickApp lui-même est un programme, qui s'exécute dans un processus géré par le système d'exploitation (Linux) Si tu vas voir le JSON de tes modules QuickApp via l'API HTTP (ou après exportation du QuickApp sur ton PC avec l'extension FQA), tu verras que ces fichiers apparaissent dans le champ files, qui est bien la traduction anglaise de fichier. Le fait de créer un second fichier "tools" pour reprendre ton exemple n'a rien à voir avec le fait d'appeler ses fonctions avec tools:xxx(). Le nom du fichier n'a aucune importance dans l'exécution du programme LUA. En revanche, lors du développement de mes QA, j'ai choisi comme bonne pratique de nommer mes fichiers de la même façon que la librairie qu'elle comporte. Mes librairies, sont en réalité des tables au sens LUA du terme, c'est à dire un tableau qui comprend des fonctions. Basiquement : tools = {} function tools:maFonction(...) -- Fait des trucs end Et c'est bien le nom de la table tools qui importe, car c'est ainsi qu'elle sera connue dans tout le programme LUA (c'est à dire dans l'ensemble des fichiers, ou onglets, du QuickApp) LUA n'est pas un vrai langage de programmation orienté objet, néanmoins Fibaro a construit les QuickApps avec une approche objet. "QuickApp" est assimilable à une classe, donc la représentation théorique de l'objet. "quickApp" (sans la majuscule donc) est assimilable à l'instanciation d'un objet à partir de la classe QuickApp. Et le mot clé self permet d'accéder aux éléments de l'objet en cours. Donc si on est dans une fonction de QuickApp, alors self pointe également sur quickApp, ça revient au même. En pratique on n'a pas besoin d'utiliser quickApp (sans la majuscule), sauf quelques cas particuliers, notamment la communication d'un Child Device vers le QuickApp parent. Et donc justement, il est peu important de comprendre ces notions quand on développe un QuickApp "célibataire", mais il devient primordial d'assimiler ces concepts quand on commence à élever des enfants.

Ah yes, pas mal le format réduit d'ailleurs

Je ne sais pas comment fonctionne ton VD, mais je te confirme que la Téléinfo ne remonte que la puissance apparente (en VA), pas la puissance active (en W). C'est un problème qui existe depuis les tous premiers compteur électroniques, et quand Linky est sorti, ils ont gardé le même mode de fonctionnement. C'est complètement crétin, et ça participe à entretenir la confusion autour de Linky pour 99% des gens, et la défiance de certaines personnes... Cette puissance apparente ne sert à rien, puisqu'elle n'est pas facturée. En fait, elle a un seul intérêt, puisque le disjoncteur de branchement, ainsi que l'organe de coupure du Linky, sont calibrés sur cette puissance apparente (enfin pas tout à fait, pour être exact ils sont calibrés sur le courant... donc selon la tension, la puissance varie) Bref, pour obtenir la puissance active (en W), il faut que le VD fasse le calcul entre 2 relevés : (index_courant - index_précédent) / (timestamp_courant - timestamp_précédent) * 3600 Là on divise bien une énergie active en Wh (modulo la multiplication par 3600 pour passer en Ws) par un temps en s, ce qui donne bien une puissance active en W. C'est ce que fait mon QuickApp GCE justement.

Petit ajout rapide, voici la version 2.11 : La liste des type exclus peut être abrégée, c'est à dire retirer le "com.fibaro." afin de contourner la limite du nombre de caractère saisis dans le champ variable de l'interface Web. Exemple d'utilisation : excl_type = "temperatureSensor, humiditySensor, lightSensor, windSensor, multilevelSensor, meter, powerMeter, electricMeter, energyMeter" Pour la mise à jour, copier/coller simplement le contenu du fichier LUA par dessus le code situé dans le fichier main du QuickApp. Téléchargement : Evénements v2.11.lua

@mprinfo ah faudra qu'on essaye de se croiser alors T'es en voiture ou en train quand tu y va ? @Nico C'est la puissance active, celle qui nous intéresse car facturée par Enedis (enfin, dans le cas présent, non-facturée ) Quand tu seras passé sur HC3, tu pourras utiliser mon beau QuickApp qui remonte toutes les infos utiles sur la box. En attendant, voici quelques URL intéressantes : http://envoy.local/production.json : lecture des informations des micro-onduleurs par CPL toutes les 15 minutes, et des pinces en temps-réel : http://envoy.local/production.json?details=1 : idem avec des détails supplémentaires (puissance apparente, réactive, cos phi, etc) http://envoy.local/ivp/meters/readings : informations détaillées pour toutes les pinces (jusqu'à 6) sur les différentes phases : Toutes les informations sont disponibles en local, il y a plein d'API locales, dont certaines sont protégées par mot de passe (facile à décoder), voir cette page : Enphase Envoy-S “Data Scraping” Pour information il s'agit de l'API locale qui n'est pas documentée par Enphase. Enphase redirige officiellement vers l'API Cloud qui est parfaitement documentée, mais que évidemment personne ne veut utiliser (pas fou le geek ) : The Enlighten Systems API

Ah je n'avais pas compris que tu voulais ajouter des Child devices à un QA existant, dont tu n'es pas l'auteur. Donc à la difficulté de gestion des QA enfants, s'ajoute la difficulté de compréhension du code LUA de quelqu'un d'autre... pas simple. Il faudrait vraiment écrire un tuto complet sur la création et la gestion des QA enfants, mais c'est un travail titanesque, surtout si on doit reprendre les bases d'un QA tout simple, ce que beaucoup d'utilisateurs ne maitrisent déjà pas très bien. En attendant le mieux qui existe, je conseille toujours cette lecture sur le forum officiel : The anatomy of QuickApps - Part 1 The anatomy of QuickApps – Part 2 The anatomy of QuickApps – Part 3 QuickAppChildren and how to raise them - Part 4

Euh... pourquoi s'embêter avec une variable de QA, c'est totalement inutile ? Je veux dire, pourquoi stocker la température dans une variable, alors que tu cherches à la stocker dans la propriété value du module. C'est directement là qu'il faut la stocker, pas besoin de rajouter une étape intermédiaire. Ensuite pour la façon de structurer son code, tout dépend de ce que tu fais. Là il n'y a aucune règle. Par exemple dans la majorité de mes QA, les enfants sont "passifs", c'est à dire qu'ils attendent des événements, mais n'ont aucune boucle infinie. La boucle infinie est gérée par le QA Parent, qui va lire les infos dans le monde extérieur (exemple fictif pour rester dans la discussion précédente : le statut de l'onduleur connecté au réseau). Une fois que cette boucle a obtenu toutes les valeurs désirées (température, état de l'alimentation, niveau de batterie, etc)... qui sont alors stockée dans des variables locales au sens LUA du terme, alors elle va "pousser" les valeurs dans les propriétés de chaque QA Enfant. Et dans cette façon de pousser les valeurs, il y a différentes façon de s'y prendre. La méthode basique c'est d'appeler directement la propriété updateProperty() des enfants. Exemple ultra simplifié, à intégrer dans ta boucle infinie du QA parent : -- Temperature : local value = 21 -- Mise à jour de la propriété value du module enfant identifié par son id : self.childDevices[id]:updateProperty("value", value) Bon après faut que tu gères correctement ton tableau d'enfants, car les identifier par leur ID ce n'est pas le plus simple dans le code. Perso ce que je fais maintenant, je crée une fonction push() pour les enfants, ce qui présente 2 avantages : - le parent peut mettre à jour les propriétés des enfants via cette fonction - le monde entier, via l'API, peut également mettre à jour les enfants. C'est particulièrement pratique avec les GCE IPX800 et EDRT2 qui permettent de déclencher des événements Push vers la box domotique pour un rafraichissement instantané. Mais c'est quelque chose que tu pourras voir dans un second temps.

Petite recherche au sujet des longueurs de câble pour l'extension des pinces de mesure de courant. La doc Enphase (cela sera peut être différent pour un autre fabricant comme Power Reducer) précise ceci : Donc ils disent que la résistance du câble doit faire maximum 3 ohm aller/retour, soit 1.5 ohm pour un aller simple. Le site suivant nous donne la formule de calcul de la résistance d'un câble en fonction de son matériaux : https://webetab.ac-bordeaux.fr/Pedagogie/Physique/Physico/Electro/e07fil.htm Si on applique la formule avec du cuivre, on arrive à 1.45 ohm sur chacun des 4 exemples donnés par Enphase, donc c'est cohérent. Je dispose d'une grosse bobine de câble réseau Cat 5e non blindé, exactement cette référence : https://www.touslescables.com/b.php?a=A5LLbo-ac5&c=Voi&h=65 Il est utilisé pour différents usages chez moi, les caméras tout autour de la maison, la téléinfo du compteur Enedis, ainsi que des compteurs à impulsion ou contacts secs pour la domotique. La page nous donne la section, AWG 24 (norme américaine), soit 0.205 mm² en métrique. J'estime la longueur nécessaire entre mon garage et ma maison à 20m. Cela nous donne une résistance de 1.66 ohm. C'est pas bon en théorie du moins.... je pense qu'Enphase prend de la marge de sécurité. Pour info la longueur théorique maximale pour ce câble réseau serait de 18m avec ce calcul. Autre piste, si j'utilise du câble Grade 3s, la section est en AWG 23, soit 0,258 mm² Et là pour 20m on tombe à une résistance de 1,32 ohm, donc c'est bon. Seul problème, je n'arriverai pas à passer le Grade 3s dans ma gaine existante (qui passe déjà le même câble justement... mais pour le réseau) Tandis que j'ai espoir d'arriver à passer le câble Cat 5e, car il est beaucoup plus fin (il n'a pas de double blindage) La solution serait de faire comme le suggère @Nico, à savoir grouper les paires, mais je crains de perdre le bénéfice de la torsade, d'autant plus important que ce câble n'est pas blindé. Bref, il faut que j'essaye. Déjà, arriver à passer le tire fil, première étape, le week-end prochain si la pluie ne s'invite pas (parce que la gaine ressort dehors... avant de rentrer dans la maison... oui c'est bizarre)

Ah, je pense que le navigateur fait automatiquement la correction de casse, ce que je ne fait pas la HC3. Avec le GEA.debug = true tu aurais vu le code de retour http, le message de retour ou d'erreur, etc, bref de quoi diagnostiquer. Comme on en discutait sur l'autre topic, il faut user et abuser de ce paramètre de debug, c'est fait pour, ça date de GEA sur HC2 et Steven pensait à tout

Hier j'ai oublié de publier une autre statistique : En mai, j'ai produit 777 kWh. La simulation donnait 762 kWh. Pas mal du tout, je suis au dessus des prévisions, sachant que : - j'ai toujours mon sapin qui fait ombre une partie de la journée (mais de moins en moins gênant à mesure que le soleil monte dans le ciel, on s'approche des jours les plus longs de l'année) - de plus en plus d'écrêtage des micro-onduleurs IQ7+ en milieu de journée Cette production meilleure que prévue s'explique facilement par le très beau mois de mai que nous avons eu cette année

Il n'existe pas de tuto sur le forum pour réaliser un QuickApp pas à pas. Il faut dire que le sujet est vaste, tant les possibilités avec les QA sont infinies. Si tu lis l'anglais, et que tu n'as pas peur de passer un peu de temps à bien comprendre les fondamentaux du LUA et des QuickApps, je te conseille le tuto de @jang sur le forum officiel, en particulier ces 4 messages : The anatomy of QuickApps - Part 1 The anatomy of QuickApps – Part 2 The anatomy of QuickApps – Part 3 QuickAppChildren and how to raise them - Part 4 J'ai commencé par ça

Comparaison de précision de mesure de puissance entre : En bleu : pince Enphase En jaune : compteur DIN à impulsion ORNO connecté sur une entrée numérique d'un IPX800 : Le compteur ORNO est vraiment très précis car il est agréé MID (donc pour la refacturation, typiquement pour des logements en sous-location). Il ne donne pas la puissance instantanée en W, puisqu'il compte l'énergie en Wh. Pour obtenir la puissance instantanée, mon QuickApp GCE fait la différence des 2 index qu'il divise par l’intervalle de temps. Cela explique les "oscillations" de la courbe jaune, puisque le calcul est précis à 1 impulsion près durant 60 secondes, c'est à dire 60 Watts. La courbe bleue est obtenue via l'API de la passerelle Envoy, il s'agit de la mesure instantanée de la pince à l'instant exact d'interrogation, sachant qu'elle est mise à jour en continu. On pourrait faire un graph à la seconde près si on voulait... Les 2 courbes ont vraiment la même forme et collent entre elles, c'est rassurant. Les petites différences : oscillation à 60W près de la courbe jaune du compteur à impulsion, on a vu précédemment que c'est dû à la méthode de calcul léger retard de la courbe jaune du compteur à impulsion par rapport à la courbe bleue de la pince Enphase, ce qui là aussi s'explique par la méthode de calcul, qui est réalisé par le delta du temps écoulé, donc lors des pics brutaux (passage d'un nuage), on a 1 minute de retard Bon en tout cas les 2 méthodes sont ultra proches et précises, donc plus que suffisant pour faire des statistiques, et gérer des scénarios (déclenchement des radiateurs, de la charge de la voiture, etc) Je vous partage maintenant la courbe de production (en bleu) avec la courbe du ballon d'eau chaude, lequel est une pure résistance, donc piloté par le routeur : On voit bien que le routeur "colle" à la production, moins la consommation de la maison (disons entre 300 et 500W) A 11h, le ballon est chaud, arrêt. A 12h35, la chauffe reprend pour maintenir la température. etc toute la journée. Maintenant c'est le graph de production photovoltaïque comparé à la consommation électrique (soutirage du réseau Enedis, information très précise obtenue via la téléinfo) On voit bien le matin les 2 courbes qui s'annulent, c'est la magie qui s'opère chaque matin A 13h, pas de chance, un nuage passe, pile au moment où je me réchauffe un plat au four micro-onde... du coup je n'ai pas mangé gratos, ça m'a couté quelques centimes d'électricité, rien ne va plus A 13h15 c'était la machine à café.... Voilà vous connaissez tout de mes habitudes N'empêche c'est instructif d'observer les courbes @Nico pour allonger la pince de mesure, je ne mettrais pas en parallèle 2 paires, j'ai peur que ça te crées plus de parasites qu'autre chose. Bon après tu testes et tu nous dis. Cela dit je n'ai toujours pas réussi à passer un câble entre mon garage et ma maison, si bien qu'il manque une info capitale dans mes différents graphs. C'est la courbe d'injection sur le réseau Du coup, aujourd'hui 31 mai, fin de mois, je suis allé faire le relevé manuel de l'index d'injection sur le Linky (vu qu'il ne remonte pas sur la Téléinfo... ) Bilan sur mai : Taux d'autoconsommation = 72,4 % Pas mal du tout, alors que je n'ai pas fini d'optimiser tous mes scénarios, et qu'il a fait un super beau mois de mai avec très peu de chauffage. Lors de mes prévisions de simulations partagés quelques pages plus tôt, je tablais sur 75 % en mai. Objectif : faire mieux que ça dans 1 an @mprinfo Si ta chaudière tourne de septembre à mai, alors tu n'as pas besoin du mode forcé. En effet, je suis persuadé que de mars à octobre, ton routeur suffira. Donc tu n'auras jamais de période où il manque du soleil ou du gaz, tu auras toujours de l'eau chaude. Surtout avec un si gros ballon, tu pourras même survivre 2 jours sans soleil (voire plus) Il y a quoi à Compiègne ? Je suis à une distance entre 1h et 2h30 environ selon l'heure.... (c'est marrant comme phrase, mais à Paris on ne parle pas en km, tu sais bien...)

Ah, tu as encore trouvé une particularité dont tu as le secret Dans ce cas tu peux faire la remarque qui va bien dans la doc, si tu la juge pertinente. Tu pourras lui donner le numéro de version 7.37 afin qu'elle corresponde à la dernière version de GEA en date. Merci en tout cas. Il était 18h24, donc non on contraire, je n'était pas dans mon état normal, l'apéro n'avait pas commencé

Ah oui lancer la chaudière juste pour ça... peut être en effet. En effet chez Enphase les câbles des pinces ont une bonne section, j'ai été impressionné. Au moins on se dit que pour le prix payé on a de la qualité, et pas de la camelote chinoise. Par comparaison, j'adore les produits GCE, mais leurs pinces... euh.... on trouve les même sur Aliexpress. Même du Cat 5E basique (donné pour 1 Gbit/s quand même) fait l'affaire, j'en suis sûr, car ça reste de la paire torsadée, donc naturellement adapté aux grandes longueurs, surtout qu'on ne passe pas de fort courant dessus.

Les caractères spéciaux oui (espace, &, ...), mais les accents c'est plus que spécial, c'est juste une aberration de certaines langues latines (pas de chance pour nous) ! Parce qu'on ne sait jamais trop si c'est encodé en UTF8 ou ISO-8859, bref une plaie que les Unixiens et Linuxiens connaissent bien. Historiquement les accents sont interdits dans les URL, mais une rapide recherche me montre que ça semble maintenant autorisé. Comme quoi tu évolue Du coup... ben... ce code LUA pour la fonction urlencode() qu'on utilise depuis des années.... tu as découvert qu'il n'est pas compatible avec les accents ! En commentant une ligne gsub(), tu as contourné le problème, mais tu vas t'en créer d'autre, car la fonction ne fera plus la conversion de tout un tas de caractères spéciaux (les caractères spéciaux "normaux", ceux qu'on connais de manière historique : - _ . ~ etc...) Je n'utilise pas IFTTT, mais n'as tu pas la possibilité de passer tes paramètres en données d'une requête POST ou PUT, plutôt que dans l'URL d'une requête GET ?

Le 19 janvier 2017, j'indiquais qu'il était définitivement abandonné. Sachant que ça faisait déjà 2 ans (2015) que Fibaro l'avait mis en standby. Tu espères vraiment que 5 ans (voire 7 ans) après, Fibaro va le ressortir du placard ? Aucune chance, même pas besoin de ressortir la boule de cristal : Mon message que tu as cité était une réponse à @Nico qui aime bien troller

Voilà, c'est nickel ça Mais en pratique, est-ce que tu auras besoin de forcer la chauffe ? (mode boost) Je n'ai peut être pas suivi les dernières évolutions de ta future installation, mais ton ballon sera aussi chauffé par la chaudière gaz non ? Auquel cas, en l'absence de soleil, il est plus rentable de chauffer au gaz qu'à l'électricité (importée depuis le réseau au plein tarif)

Ici j'ai un compteur à impulsion sur la ligne de mon ballon d'eau chaude, et cela depuis des années, bien avant d'avoir le routeur. (mon routeur affiche juste les kWh injectés sur un écran LCD, l'information n'est pas directement récupérable dans le domotique car il n'est pas connecté au réseau) Les câbles pour les pinces ampèremétriques ça s'allonge très facilement. Pour mon routeur, qui est prévu avec prise Jack 3.5mm, j'ai fait basique puisque j'utilise une rallonge jack stéréo (3 fils, donc je n'utilise que 2 fils) tout ce qu'il y a de plus standard, et ça marche très bien. Sinon idéalement tu peux utiliser 1 paire (2 fils torsadés) d'un câble réseau ou téléphone classique.

Y'a des plus et des moins pour chaque technologie. Quand un MO (micro-onduleur) est en panne, pas de stress pour le changer, le reste de l'installation continue de fonctionner. Quand un onduleur central est en panne, bah même s'il est plus simple à changer au mur, n'empêche que pendant X jours ou semaines, tu n'as plus de production du tout. Après on pourrait aussi parler du risque de panne d'un panneau, qui existe aussi, et imposera d'aller également sur le toit, le travail est le même que remplacer un MO au final. Sur mon installation je n'ai aucun panneau au milieu des autres, donc que je doive changer un panneau ou un MO, c'est relativement facile puisqu'ils sont tous directement accessibles, sans devoir démonter la moitié de l'installation pour y accéder. Mon toit est également assez bas, ce qui facilite l'accès. C'est différent pour celui qui a un toit en hauteur, avec beaucoup de panneaux tous collés ensembles, etc. J'ai déjà longuement expliqué mes choix dans ce topic, le pourquoi des MO sur mon installations, je ne dis pas que c'est la solution idéale. @mprinfo quant à la durée de vie, c'est un calcul à faire (ce que tu as refusé de faire.... ) pour savoir lequel est le plus intéressant. Mais même en intégrant la panne de l'onduleur central à la moitié de la vie des panneaux, je pense que ça reste plus rentable. Peut être aussi que dans 10/15 ans, une technologie miracle d'onduleur sera disponible, permettant d'améliorer les performances, ou d'ajouter de nouvelles fonctionnalités, tout en conservant les panneaux existants (je pense notamment aux onduleurs hybrides permettant de stocker dans des batteries) Après tu peux aussi regarder chez Fronius, je pense qu'ils proposent des extensions de garantie si ça peut te rassurer. Truc marrant chez Enphase, les MO ne sont garantis 25 ans que si tu as la passerelle Envoy pour les monitorer. Comme si le fait de les monitorer permettant de les rendre plus fiable. Alors j'imagine 2 choses : le monitoring permet à Enphase de vérifier que les MO ont été utilisés correctement (dans les limites prévues par le constructeur), ou bien qu'elle ajuste dynamiquement le comportement du MO (par exemple en limitant sa puissance, ou en mettant à jour son firmware, etc) en fonction des conditions.

Pas d'accord pour le coup, les produits Apple sont de loin ceux qui ont la plus longue durée de vie. A ce jour, aucun constructeur de smartphone ne propose de mise à jour pendant aussi longtemps que Apple (je dis ça alors que je n'aime pas leurs produits pour rappel).... après si un petit pourcentage des clients se sent obligé de changer de modèle chaque année, c'est leur problème (et de toute façon on retrouve les mêmes comportements quelle que soit la marque, ce n'est pas lié à Apple spécifiquement) M'enfin bref passons, dès qu'on parle de cette marque ça part toujours en live. Enphase c'est du luxe, oui c'est sûr. C'est pour ça que j'ai pris les IQ7+, le choix de la raison, et pas les IQ7A qui ont un plus mauvais rapport performance/prix (ou rendement/prix devrais-je même dire) Fronius est bien évidemment un choix plus pertinent d'un point de vue purement économique. Cela dit, concernant la durée de vie, Enphase garantie 25 ans d'origine. Chez Fronuis, je crois que c'est 10 ans ? Et quand tu regardes les retours d'expérience sur les forums, c'est assez unanime, 10 ans c'est l'âge moyen de la durée de vie d'un onduleur central, indépendamment de la marque. Même si tu trouveras toujours des gens pour témoigner que le leur a tenu 12 ans (ou à l'inverse, 8 ans) Et cela s'expliquer techniquement, un onduleur central ça fait passer de plus grosses puissances, ça chauffe plus, les composants (condensateurs principalement) crament plus vite. Les micro-onduleurs font passer un courant plus faible, par principe. Je ne sais pas si tu as vu la vidéo sur Youtube du mec qui a démonté le siens, d'ailleurs il a eu du mal. Entièrement scellé, donc étanche à l'air (et à l'eau évidemment), une espèce membrane à l'intérieur couvre chaque composant, tout semble étudié pour que l'électronique résiste très longtemps. Même si là encore, tu trouveras des gens dont le MO est mort prématurément (dont le youtubeur qui a démonté le siens), mais la garantie est justement là. Seul souci, si dans 10 ans ils te le remplace, le nouveau modèle ne sera pas compatible avec la passerelle Envoy S actuelle (ça s'est produit avec les générations précédentes). Cette dernière remarque m'amène à réagir à ceci : Rien n'est moins sûr... Au pire, je préfère remplacer une passerelle à 300€ (même si c'est déjà horriblement cher pour ce que c'est...) qu'un routeur à 1000€. Sans compter qu'outre le routeur, @mprinfo aura probablement le même souci d’incompatibilité avec le Smartmeter (hop, encore 100€ de plus) Dans un calcul de rentabilité avec onduleur central, normalement on intègre que l'onduleur (et tout ce qui en dépend) sera à remplacer au bout de 10 ans. Pour les micro-onduleurs, la question ne se pose pas vraiment, ils sont censée avoir la même durée de vie que les panneaux, c'est à dire 25 ans en moyenne. C'est le risque de grêle "balle de ping-pong" (ou pire) qui m'inquiète le plus en fait...

A contrario, il deviendrait 100% dépendant de l'onduleur Fronius. Celui-ci sera probablement le premier à tomber en panne, auquel cas il perdra tout d'un coup, et je doute que le Ohm Pilot puisse être utilisé avec un autre onduleur de tout simplement de façon autonome. Les écosystèmes, c'est bien, c'est beau, c'est intégré, c'est facile, c'est tentant, mais ça présente 2 inconvénients : - ça coute plus cher. - tu es enfermé dans une technologie / un constructeur unique... et compliqué pour en sortir (et ça coute doublement plus cher quand tu veux en sortir justement, retour à la case départ) Il y a un très bon exemple mondialement connu, une pomme croquée... Enphase fait pareil tu me diras, ils ont construit un écosystème complet avec batteries, et même aux US (pas encore dispo en FR, probablement 2023) avec les IQ8 et un inverseur de source connecté tu peux avoir de l'autonomie complète en cas de coupure secteur. Mais à quel prix stratosphérique. L'avantage, c'est que tu peux tout à faire utiliser uniquement les micro-onduleurs Enphase, et monter un système indépendant à coté. C'est ce que j'ai fait pour le routeur du cumulus, et probablement plus tard avec du stockage sur batterie (impossible que je prenne chez Enphase, ils sont hors de prix, aucun intérêt... même si c'est beau, intégré et facile ) A la limite, rien n'interdit de marier des MO Enphase avec des MO APS, ou bien un onduleur Fronus sur la même installation, à aucun moment on est bloqué.