Lazer

Indeed, no consumption clamp on my system because I can't connect it (too far away). However I have the production clamp. Aside from the Ethernet/Wi-Fi connexion, the missing clamp may explain the difference, my Envoy has less computing to do.

Je n'ai pas inventé cette formule de calcul, j'ai repris celle que j'ai trouvé quelque part... sans certitude, mais je crois que c'est de @Steven qui l'avais partagé sur le forum, à l'époque de la HC2. En fait cette formule est un grand classique du calcul d'utilisation CPU sur un ordinateur... les métriques remontés par le noyau donnent un temps processeur cumulé (en "tick" processeur, c'est l'unité élémentaire, basée sur le cycle d'horloge, donc le plus petit temps possible), cela pour l'ensemble des cœurs actifs. C'est valable pour les différents systèmes d'exploitation, Linux, AIX, etc... (Windows aussi je suppose, je n'ai jamais développé avec les API de performance sur cette plateforme). Il faut donc diviser le temps total mesuré par le nombre de cœurs installés pour obtenir le bon pourcentage d'utilisation moyen de la machine. Le facteur 4 c'est juste à cause du nombre de cœurs dans le processeur de la HC3, je crois de mémoire que c'est seulement 2 dans le cas de la HC3 Lite. D'où l'utilisation de la variable nbCPUs qui compte le nombre de cœurs dans la formule. Pour s'assurer de la fiabilité de cette formule effectuée en LUA, il faudrait effectuer un benchmark. Pour cela, écrire un code LUA dans un QuickApp, qui tourne en boucle "à fond la caisse", par exemple en faisant un calcul mathématique simple, et cela pendant de longues minutes. Le code LUA du QuickApp étant mono-threadé, il sera affecté à un seul cœur du processeur. Ce cœur sera donc à 100%. La HC3 disposant de 4 cœurs, la charge moyenne du processeur sera donc de 25% (en pratique un peu plus, car la HC3 fait aussi d'autre choses : moteur Z-Wave, autres QuickApps, scènes, et interface Web qui consomment tous un peu de CPU) La formule de calcul, devrait donc donner un résultat approximativement autour de 25% (1 cœur à 100%, divisé par 4 cœurs pour moyenner sur le processeur du système) Cependant, il y a une grosse limitation. L'API /diagnostics remonte les informations fournies par le noyau Linux, donc précises, sur l'ensemble du système (incluant donc la totalité des processus tournant sur la machine... tant les processus utilisateurs (QuickApps, Scènes, les différents binaires Fibaro) que les processus systèmes (noyau, librairies de gestion des entrées/sorties (stockage, réseau, etc). Cependant, la commande collectgarbage("count") utilisée en LUA pour récupérer la consommation CPU du QuickApp, ne compte que le processus utilisateur proprement dit (rappel : 1 QuickApp = 1 processus utilisateur sous Linux). Impossible donc, depuis un QuickApp, de mesurer l'activité induite par le QuickApp, à savoir les autres processus systèmes et noyau. Exemple, un QuickApp qui appelle l'API de la box fait travailler le serveur Web embarqué ainsi que d'autres processus Fibaro. Cette activité sera "vue" par l'API système /diagnostics, mais pas par l'API LUA locale. De même pour un QuickApp qui fait des requêtes réseau, des affichages dans la console de debug, ou déclenche des activités sur les autres modules (physiques ou QuickApps....) Quoi qu'il en soit, mon test de benchmark proposé précédemment, s'il se contente de faire un calcul mathématique simple en local (une simple addition suffit... ou même pas de calcul du tout, ça peut être une bête boucle infinie de type "while true do end") devrait théoriquement limiter l'activité externe induite par le QuickApp, et donc permettre d'approcher les 25% de charge moyenne de la box, tout en étant lui-même à 100% sur un seul cœur. Ou tout du moins, un bon ordre de grandeur (étant donné, encore une fois, que la box fait aussi autre chose en même temps) Pas simple l'analyse de performance en informatique... Oui mais attention, ce cas que tu décris n'est qu'un cas particulier où la charge est équilibrée sur l'ensemble des cores, ce qui est hautement improbable (statistiquement on s'en approche tout de même sur un système chargé avec un grand nombre de processus, car le noyau Linux fait de son mieux pour équilibrer la charge sur les différents cores) Par ailleurs, si tu as suivi mon exposé, tu peux avoir 1 core à 100%, et les autres qui ne font rien, ça fait 25% en moyenne. Ou n'importe quelle autre combinaison de charge de travail (ce qui, dynamiquement, change un grand nombre de fois chaque seconde lorsque le noyau rééquilibre les processus sur les cores) Oui.

Yes, wired Ethernet for all my equipment, including the Envoy gateway. Despite having an excellent Wi-Fi thanks to my 3 Unifi AP, it is only used by mobile devices such as phones, tablets, or some few devices without any Ethernet port such as ESP32 or Netatmo. Nothing cas beat Ethernet connection, not even the latest WiFi 7 protocol. It took me hours, days, weeks of work to be able to bring Ethernet cables to almost everywhere in my house, from the basement to (literally) the roof.

@TitiXsi I remember this old conversation we already had, but my Envoy S Metered has no problem being polled by my QuickApp with a 5 seconds interval. It's monitoring 2 Q-Relays and 16 IQ7+ micro-inverters. Most API requests are delivered within less than 1s, sometimes a little more, but still less than 2 seconds.

Les fichiers TXT sont bloqués par le forum, il faut attacher les fichiers directement avec l'extension lua.

Déjà dans la définition de GEA portables, le 2nd élément de ton tableau c'est une variable vide (donc valeur = nil) car non déclarée. Peut être que tu voulais mettre la chaine de caractères "iphone" à la place. Bon de toute façon ce n'est pas ça le problème. Ensuite tes noms d'ID comportent des espaces, caractères interdits, et bizarreries de toute sorte, en LUA tout cela est syntaxiquement incorrect. Et à mon avis tes problèmes viennent de là. Mais je ne suis pas sûr de bien comprendre... c'est la première fois que tu utilises GEA ? Car vu la tronche de ton fichier, ça ne peut pas être une modification récente, sinon il y aurait 1 seule erreur, et pas des dizaines. Clairement, recommence à 0, et ajoute les règles une par une, sinon tu ne vas pas t'en sortir. Et tu ajouteras les ID au fur à et mesure de tes besoins dans les règles que tu ajoutes au fil de l'eau. Sinon, en l'état, c'est juste impossible à dépanner.

Oui mais c'est juste de la consultation. Une personne qui utiliserait normalement ce gestionnaire d'énergie se connecterait 1 fois dessus par jour, par mois, voire par an... Ce que je veux dire, c'est que l'alimentation électrique est le fondement même de ce produit (vu qu'il est installé dans le tableau et qu'il sert à monitorer le tableau), tandis que le réseau est juste une interface externe. Parce que le coût. GCE s'évertue à proposer des produits made in France, qualitatif, et un tarif raisonnable (internalisation des process de R&D et fabrication, marge réduite, réinvestissement des bénéfices, etc), ce n'est pas pour ajouter des fonctions inutiles, sauf pour 1% des utilisateurs (en comptant large). D'ailleurs c'est exactement le discours qu'ils tiennent sur le forum officiel à chaque fois que quelqu'un fait une proposition d'amélioration... disons... "exotique". Nous ici on est le pourcent d'exception, car on n'utilise pas l'EcoDevice comme un gestionnaire d'énergie, mais juste comme une passerelle pour mesurer les compteurs, pinces, téléinformation, etc. Ce qui est un usage très luxueux car on est riche, payer 300€ juste pour ça, tout le monde ne peut (veux) pas se le permettre. Regarde les forums, tu verras que la plupart des gens qui font du suivi de consommation depuis leur box domotique (HA essentiellement aujourd'hui), utilisent des Shelly EM, Lixee, Zlinky, Emporia, ou tout un tas de chinoiseries à pas cher...

Euh, 2 appareils ce n'est pas ce que j'appellerai un souci connu... Après, le coup de l'alimentation qui crame, ça représente approximativement 90% des pannes des appareils électriques/électronique de notre quotidien, donc de ce point de vue là, oui tu peux dire que la panne d'alimentation au bout de quelques années est un souci connu... mais en ne visant pas spécifiquement l'Ecodevice

C'est parce que tu n'as pas saisi le concept de cet appareil. C"est un appareil autonome, un gestionnaire d'énergie, qui stocke toutes les infos en local, il n'a aucunement besoin du réseau. C'est ton usage détourné (pareil pour moi...), en simple passerelle depuis une box domotique externe, qui fait que tu deviens dépendant du réseau. EDIT : et non, il ne fait pas de Wi-Fi, GCE a pour principe de ne faire que des appareils fiables (même si une panne de composant peut arriver), donc ça exclue le Wi-Fi qui n'est pas fiable par nature, contrairement à l'Ethernet.

Bienvenue sur le forum

Souci...de quoi ?

Peut être, je ne sais pas du tout en fait. Mais je pense plutôt à une modification de la syntaxe du YAML comme je l'ai évoqué dans mon message précédent, as-tu essayé les modifications comme je l'ai suggéré ?

Aucun intérêt le POE sur cet appareil, qui se doit d'être indépendant, connecté directement au compteur dans le tableau électrique. Par contre peur être qu'ils ont prévu le même type de bloc d'alimentation que sur l'IPX800 v5 sur l'EDRT3 dont la conception est quasi finalisée.

Je pense que c'est possible, en revanche ta syntaxe n'est pas bonne, le Slepp n'est pas après les ID, mais avant, il est même avant le nom de l'action à appeler ("Close" je suppose)

Bienvenue sur le forum

Bonne idée

ça a peut être changé.... Je viens de regarder le fichier exemple de la page 1 contient à la fois ota, et à la fois platform, sauf que le platform est dans climate. La doc en ligne te donne les valeurs possibles pour le paramètre platform dans ota : esphome ou http_request... à tester. Sinon, tu peux essayer de virer complètement ota, tu ne pourras pas faire les mises à jour à distance par Wi-Fi, mais ce n'est pas nécessaire, au pire tu devras rebrancher le module en USB sur le PC (c'est d'ailleurs pour ça que j'avais anticipé, dans mon tuto, avec la "rallonge" permettant de déporter le module ESP de la carte mère du split pour le débrancher facilement)

Ah ça avance Là tu dois juste avoir un petit problème d'erreur de syntaxe dans ton fichier de configuration et/ou le fichier de mots de passes.

C'est exactement le même microcontrôleur que j'ai commandé, donc ça devrait être bon. Dans ton fichier YAML, tu n'as pas une référence à esp8266 qui traine ? Si le test.yaml passe, je ne vois pas pourquoi ça ne passerait pas ensuite...

Ouh là là, c'est du chinois tout ça Tu as dû avoir quelque chose qui s'est mal passé durant l'installation de la suite de compilation ESPHome. Essaye de tout effacer et reprendre au début, car là je n'ai aucune idée du problème. EDIT : c'est normal le KeyError: 'esp8266' tout en bas ? C'est de l'ESP32 qu'on utilise normalement... tu n'aurais pas juste une couille dans ton fichier de config YAML ?

Moi aussi... espérons à une indisponibilité passagère de l'API RTE...

Voilà, nouveau topic dédié pour le projet de @Sakkhho

Ah c'est ça le terme technique, merci j'ai appris un mot aujourd'hui (que j'aurai oublié dans 1 heure ) @Sakkhho je vais scinder le topic pour que tu aies ton topic à toi, car ça commence à prendre de l'ampleur et ça n'est pas lié à mon installation, sujet du topic.

Ah oui d'accord, c'est le lien que tu avais donné. Mais de ce que je vois, c'est pas pour les toit plat, mais pour les toitures arrondies, qu'on trouve sur certains entrepôts. Niveau rendement ça être bien merdique, car les panneaux ne sont jamais correctement orientés par rapport au soleil. Et j'ai des doutes sur la durée de vie. Ton problème, ce n'est pas la forme du panneau, mais de trouver un moyen de fixer la structure en dessous. C'est pout ça que je te demandais, si sur ton toit terrasse tu as un rebord (généralement c'est le cas), et surtout qu'il est suffisamment haut, alors venir fixer la structure dessus. Ainsi, elle serait comme en lévitation au dessus du toit plat, sans jamais venir s'appuyer dessus. Après, tu comptes poser toit même ou faire poser ? Car si tu fais poser, ce sont les artisans qui vont te proposer des solutions qu'ils connaissent.

Je ne comprend pourquoi ça fait plusieurs messages que tu parles de panneaux souples ? Ce n'est pas du tout adapté à l'installation fixe sur bâtiment, ces panneaux très particuliers sont prévus pour les toits des fourgons aménagés, afin d'épouser la forme du capot. Sur un bâtiment, tu vas avoir une prise au vent démentielle, et en plus c'est plus fragile, ça ne tiendra jamais dans la durée. C'est du panneau rigide uniquement qu'il te faut utiliser, la question est de trouver un système de fixation sur ton toit-terrasse. Pas possible de fabriquer une structure qui viendrait se fixer sur les rebords verticaux ? Ainsi tu ne toucherais pas à la partie horizontale du toit. Techniquement il est possible de déporter des micro-onduleurs, bien que ça ne soit pas prévu pour.... il faut utiliser des rallonges de câbles DC avec connecteurs MC4. Pourquoi tu ne veux pas d'onduleur central ? C'est à mon avis une solution préférable par rapport à des micro-onduleurs déportés (ce qui va à l'encontre même du principe des MO)