Aller au contenu

Lazer

Administrateur
  • Compteur de contenus

    25 982
  • Inscription

  • Dernière visite

  • Jours gagnés

    1 277

Tout ce qui a été posté par Lazer

  1. Lazer

    Support Gea

    Il faut utilise la condition "Profile" (voir exemple basique dans la doc de syntaxe) Et tu as mis tes autres conditions dans les actions. Quelque chose comme ça devrait être mieux : GEA.add({{"Profile", "Home"}, {"(Days)", "Weekday"}, {"(Time)", "07:00"}}, -1, "Allumage ID20 le #date# à #time#", {{"turnOn", ID20}}) GEA.add({{"Profile", "Home"}, {"(Days)", "Weekend"}, {"(Time)", "09:00"}}, -1, "Allumage ID20 le #date# à #time#", {{"turnOn", ID20}}) Il faut mettre les autres conditions entre parenthèses car ce sont sont pas des déclencheurs instantanés. Ainsi seul le changement de Profile est concerné par le déclencheur -1. Cela dit la logique est étrange, je pense que je n'est pas compris ce que tu voulais faire, car l'action ne se déclenchera que si le profil est modifié à exactement 7h ou 9h, ce qui a statistiquement peu de chance d'arriver. Il vaut mieux mettre une plage horaire plus large. Pour la seconde question, c'est pareil, il faut ramener tes conditions au début de ta règle. Attention aussi au %date, ça sort d'où ? Il faut utiliser #date# comme dans l'exemple que je t'ai donné.
  2. Mon installation photovoltaïque en autoconsommation Sommaire : Présentation du projet Simulations Consommation, production, et estimation du taux d'autoconsommation Amortissement et rentabilité financière Choix du matériel Livraison du matériel Câblage du tableau électrique Pose des crochets de fixation Pose et câblage du premier champ de 5 panneaux Pose et câblage du champ de 6 panneaux sur l'autre versant Influence de la neige sur la production photovoltaïque Courbe de production d'une journée d'ensoleillement parfaite Suivi production et financière à 1000€ au bout d'an an et demi Répartition des postes de consommation électrique sur 1 an glissant Influence du sous-dimensionnement de la puissance des onduleurs Panneaux sous la neige Panne micro-onduleur APSystems DS3-L Influence de l'arrêt de production d'un micro-onduleur sur la hausse de température d'un panneau Bilan à 3 ans Ça fait des années que j'y pense, j'ai décidé que 2022 serait l'année où je pose des panneaux photovoltaïques. Sur ce topic je vais décrire le processus de réflexion, mes choix, mes calculs, puis la réalisation, et ensuite le suivi de production (les valeurs mesurées seront-elles conformes à la théorie ?.... RDV dans 1 mois, 1 an, 10 ans....) Je prend le temps de décrire les choix, les contraintes, et les calculs de simulations, car lors de mes recherches je me suis rendu compte que : tous les sites commerciaux ne proposent que des approximations grossières, quand elles ne sont pas carrément fausses. A ce sujet on entend souvent dire que la pente idéale est de XX°, sauf que ça correspond bien souvent à Lyon et on n'y habite pas tous, et tout dépend si on souhaite favoriser la production en été ou en hiver. En effet, à l'époque du rachat par EDF à 60 centimes, les installations étaient en vente totale, et on cherchait la production annuelle maximale. Aujourd'hui on fait de l'autoconsommation, et on cherche à consommer le maximum de ce qu'on produit, et ça change tout. Il est absolument fondamental de comprendre ce principe si on veut monter un projet photovoltaïque un minimum cohérent. Autre chose, les pseudo cartes de France avec le taux d'ensoleillement moyen, avec des valeurs très approximatives, et surtout très différentes d'un site à un autre, on ne sait jamais trop s'ils donnent le productible théorique, s'ils prennent en compte la pente des panneaux (mais laquelle ?), les pertes, etc... bref inutilisable. la plupart des gens se lancent dans le photovoltaïque sans faire le moindre calcul, et c'est bien dommage (influencé par les sites commerciaux, voire les démarcheurs peu scrupuleux), et ne découvrent que bien plus tard la rentabilité (ou non) de leur projet, et je trouve ça affligeant. Et encore, certains ne mesurent même pas et se contentent de dire "ma facture a baissé de XX€" => oui mais comparé à quoi ? Est-ce tu as modifié tes habitudes de vie en même temps ? J'espère donc que mon expérience servira au maximum. Et si je me suis trompé, il y aura bien quelqu'un pour me reprendre. J'invite au minimum à faire une simulation sur PVGIS, et une analyse de sa consommation électrique. Mais encore faut-il avoir des relevés, de ce coté là Linky est une évolution considérable, courrez créer votre compte sur le site d'Enedis si ce n'est pas déjà fait. En ce qui me concerne, j'ai des relevés de mon propre compteur comme on le verra plus loin. Bref, je compte poser les panneaux sur le toit de mon garage. Je vais poser moi-même, car la pose par des pros annule tout souhait de rentabilité en doublant, voir triplant le tarif global (la main d’œuvre en région parisienne est stratosphérique, surtout sur ce secteur), et tant pis pour les ridicules aides de l’État qui ne permettent pas de couvrir les frais d'installation, et de très loin. Également pas de vente du surplus (à 10 centimes chez EDF-OA, et 6 centimes chez les concurrents avec plein d'obligations contractuelles, ce n'est pas valable) En résumé, mon projet : autoconsommation pas de vente du surplus objectif de taux d'autoconsommation maximal (car tout ce qui n'est pas consommé est perdu... c'est à dire injecté gratuitement dans le réseau, ou bien écrêté si mise en place d'un profil zéro-injection comme le demande Enedis) Sachant que je suis au chauffage électrique (PAC+radiateur), ballon d'eau chaude de 300L, véhicule hybride rechargeable, installation geek domotique+informatique qui consomme un gros bruit de fond, ça fait pas mal d'occasion d'utiliser la production photovoltaïque. Je suis à environ 12000 kWh annuel. Attention, je pars avec des handicaps : région IDF (il fait toujours gris...) je peux difficilement accéder au toit de la maison (qui est bien exposé), donc je fais le choix de poser sur le toit du garage (facile d'accès) mais le garage a une faible pente (10.5°) et une orientation pas idéale (orientation est-ouest). il va falloir abattre un arbre (un sapin qui est de toute façon devenu gênant) et tailler le autres (ça ne fera pas de mal) nombreux masques dus à ma propre maison, aux bâtiments des voisins, et aux arbres des voisins... tout cela est surtout gênant en décembre/janvier, pas le reste du temps. Voici un plan schématique de ma maison, et du jardin, correctement orienté au nord, afin de comprendre les choix. J'ai coloré en rouge les versants de toit complètement exclus (orientation nord, cheminée, etc) En vert, le toit le mieux exposé au sud-est, bonne pente, quasiment aucune ombre, l'emplacement parfait..... mais, gros problème : toit inaccessible sauf à monter un gros échafaudage, ou bien passer par le Velux (ce qui ne m'enchante guère...) => on oublie En jaune, un toit tout aussi bien exposé au sud-ouest, mais le retour du toit lui procure une ombre en 1ère partie de journée, donc l’ensoleillement est un peu moins bon que le toit vert. Là aussi l'accès est compliqué, mais faisable. C'est une piste éventuelle pour ajouter des panneaux dans le futur. En orange, les 2 pentes du garage... très peu pentu, à seulement 10.5°. Donc assez mal orienté par rapport à l'angle d'incidence des rayons du soleil. Mais finalement pour la pente coté nord-ouest, cette faible pente redevient un avantage, car elle sera tout de même exposée au soleil, c'est toujours mieux qu'à l'ombre, donc cette pente est "exploitable". Reste à calculer sa rentabilité, ce que j'ai fait, c'est pour cela que je l'ai colorié en orange un peu plus foncé. Autres contraintes sur ce garage, les ombres. Celles des arbres du jardin (que j'ai taillé, il ne m'en reste plus qu'un à faire), et de la maison (en hiver uniquement). On verra ces ombres plus loin dans l'étude. Mais surtout, grâce à la faible pente, et la faible auteur du toit du garage, celui-ci est très facile d'accès, donc je peux réaliser l'installation tout seul. Rappel sur les valeurs d'angles utilisées en solaire : azimut : donné par rapport au sud, à 0°. Le nord est à 180°. pente : donnée par rapport au sol, à 0°. Un mur vertical est à 90°. Puisque le garage est retenu, voici une vue 3D du garage avec 14 panneaux installés, le maximum possible. Un petit Velux (qui n'en est pas un) impose de répartir les panneaux en 3 plans distincts au total : Pour info, l'arrière du garage (en haut à gauche sur la représentation 3D) est mon abri de jardin que vous aviez pu découvrir ici : https://www.domotique-fibaro.fr/topic/1894-bricolage-chez-lazer/?page=6&tab=comments#comment-99515 Les panneaux viendront donc s'appuyer directement dessus. Voici la représentation des masques d'ombres au niveau du garage sur un diagramme solaire. Pour le réaliser, je me suis installé au niveau du toit, j'ai utilisé un niveau numérique avec lequel j'ai pointé le sommet des sources d'ombres (bâtiments) afin de relever l'angle d'élévation. Ensuite j'ai utilisé une application de boussole sur mon téléphone, j'ai perdu 1h, car ça ne donne jamais le même angle. Beaucoup trop d'interférences (surtout quand on est collé à un bâtiment en béton...), une précision à 20 ou 30° près, c'est inutilisable. Je suis allé sur Amazon, et j'ai acheté une vraie boussole à 10 balles, la même que j'utilisais pour les courses d'orientation quand j'étais gamin, livrée le lendemain, et j'ai refait mon relevé en 30 secondes. Ensuite j'ai reporté les mesures sur le site SunEarthTools.com qui permet de générer les diagrammes solaires. Je l'ai colorisé pour une meilleure visibilité : en jaune, la course du soleil dans le ciel en fonction de la saison et de l'heure (modulo 1h si heure d'été) en orange, le soleil est bas sur l'horizon, et tout effet d'ombrage sur cette période n'a que très peu d'impact sur la production annuelle en rouge, zone située sous la ligne noire, représente les ombres portées sur les panneaux. Le matin et le soir ce n'est pas vraiment gênant (zone orange), mais en hiver, un peu le matin et le midi, on reconnait l'ombre portée de la maison. En fin d'après-midi ce sont les ombres des maisons des voisins. Et oui, je suis en ville, c'est relativement dense par chez moi... Non représenté, les ombres dues aux arbres, puisqu'ils seront tous taillés d'ici l'installation. J'ai également réalisé les masque d'ombres pour les 2 versants "vert" et "jaune" de la maison, que je ne représente pas ici car ça n'apporte rien, mais je m'en suis servi pour les simulations. Les simulation justement, réalisées à l'aide de l'excellent site de référence PVGIS. ça fait peur au début, mais c'est facile, on met ses coordonnées (très précisément), la puissance crête qu'on projette d'installer, les pertes estimées (conversion des onduleurs, longueurs de câbles, etc), et l'inclinaison et l'azimut. En ce qui me concerne, j'ai également ajouté le profil des ombres relevées précédemment, puisque c'est ce qui permet d'affiner la mesure. Ensuite on clique sur le bouton Visualiser résultats ce qui permet de voir le productible annuel en kWh, et la répartition mensuelle. Je voulais mettre un maximum de données dans Excel pour réaliser des calculs et graphs comparatifs, donc j'ai utilisé PVGIS de la façon suivante : Pour chaque pente de toit candidat (4 dans mon cas, cf plus haut) : J'ai chargé le profil d'horizon correct J'ai indiqué l'inclinaison J'ai indiqué l'azimut Pour l'ensemble, j'ai mis une valeur arbitraire de 1000 Wc, et des pertes = 0 (car je rajouterai les pertes dans Excel). Ainsi j'ai récupérer les valeurs théoriques ce qui me permet de comparer l'efficacité de chaque plan de toiture. J'ai aussi fait un relevé théorique maximal, chez moi ça correspond à 38° et azimut -6°, juste par curiosité, pour comparer. Je vous présenterai les résultats plus tard, car PVGIS annonce une mise à jour le 1er mars, ce qui me permettra d'affiner encore un petit peu plus mes simulations.
  3. Cool, un module musical, c'est dingue ce qu'on arrive à faire avec un peu de domotique et d'impression 3D
  4. J'ai retrouvé : 1ère page, 1er message, chapitre 7, tu as la solution pour Netatmo. Toujours bien lire le tuto jusqu'au bout
  5. Bilan après 1 semaine. C'est stable (comme avant en 5.070). J'ai l'impression que les freezes ont disparu (mais c'est peut être encore un peu trop tôt pour le confirmer) Niveau CPU, nette amélioration : Et Mémoire également : Du tout bon cette version stable
  6. Top ça Une suggestion, c'est ce que je fais maintenant sur tous mes boitiers : je prévois des trous de vis plus large, et j'y introduit un insert métallique avec la pointe d'un fer à souder. Avantage, c'est vissable/dévissable à volonté sans user le pas de vis usiné de force par la vis dans le plastique. Dispo dans toutes les tailles :
  7. Voilà, j'allais te dire que tu peux commenter, ou même supprimer complètement tout le bloc de code LUA dédié à la station Netatmo. Désolé je n'ai plus de HC2, donc c'est du support en mode "best effort", à l'aveugle. De mémoire il y avait un bug avec Netatmo, il doit y avoir un message à ce sujet en 1re page, ou quelque part dans les 52 pages du topic...
  8. Ah non pas normal... mais alors là comme ça, aucune idée du pourquoi du comment Tu as quoi en ligne 213 du code LUA du bouton Devices ?
  9. Les devices sont ajoutés chez nuit après minuit. Tu peux les forcer immédiatement en cliquant sur le bouton Devices du module virtuel. Ensuite ça devrait être bon.
  10. Lazer

    Petits bug de la HC3

    Oui en effet, espérons que ça se passe bien alors.
  11. Lazer

    Petits bug de la HC3

    Débrouille toi pour installer ces modules le plus proche possible afin qu'ils soient en vision directe par la HC3, et tu n'auras pas de problème. Les bugs rencontrés semblent apparaitre quand ces vieux modules passent par au moins 1 saut de routage. Sinon il faut attendre le moteur v3, mais il est très loin d'être stable, donc fortement déconseillé pour l'instant. D'ailleurs fait bien attention lors de l'install de ton HC3, à bien sélectionner le moteur v2.
  12. Possible, je n'utilise le swagger que pour consulter la syntaxe, je ne réalise jamais les requêtes avec. Je fais mes requêtes avec curl directement (depuis une VM Linux, par habitude puisque maintenant c'est en natif dans Windows), ou bien directement dans le navigateur, ou en LUA...
  13. OK d'accord. Alors energy + power sont donc 2 prérequis pour voir virtualEnergyConsumption Donc si je rectifie ce que j'ai écris, ça donne : La propriété energy peut être mise à jour manuellement (par lecture de la valeur d'un compteur électrique, d'un onduleur, etc), ou bien calculée par la HC3 grâce à l'ajout de l'interface virtualEnergyConsumption Pour l'API, essaye avec un s à la fin : "addInterfaces"
  14. Je dirais que c'est normal, d'après ma compréhension de la logique Fibaro, un module peut avoir soit l'interface energy, soit virtualEnergyConsumption, mais pas les deux. - energy : l'énergie est mise à jour manuellement (par lecture de la valeur d'un compteur électrique, d'un onduleur, etc) - virtualEnergyConsumption : justement là on n'a aucun moyen de connaitre l'énergie, donc on laisse la HC3 le calculer (ça n'est possible que si on met à jour la propriété power (ce qui implique que le module doive impérativement posséder l'interface power)
  15. Pour ajouter une interface, tu ne peux pas le faire injectant un paramètre dans le JSON d'un module. Car il ne s'agit pas que d'ajouter un nouvel élément à la table interfaces du module, cela va également créer des nouvelles propriétés dans le module, qui dépendent de l'interface ajoutée. => il faut appeler la méthode addInterfaces du QuickApp (avec l'ID du parent ou d'un enfant, peu importe ça fonctionne pour les 2) Tu peux regarder comment je fais en LUA dans ma librairie tools que tu trouveras dans tous mes QuickApps du forum. Ou alors directement via une méthode GET en passant par callAction : /api/callAction?deviceID=123&name=addInterfaces&arg1=%5B%22power%22%5D /api/callAction?deviceID=123&name=addInterfaces&arg1=%5B%22virtualEnergyConsumption%22%5D Remarque de fond sur la gestion de modules : Je n'aime pas la technique consistant à créer autant d'enfants que d'informations à remonter. Ex : un enfant de type binarySwitch, un autre de type powerMeter, un autre de type energyMeter, et un autre de type battery... ça surcharge l'interface, et remplie la DB de nombreux modules inutiles. Je préfère sélectionner soigneusement le type de mon module (par exemple binarySwitch), et lui ajouter les interfaces nécessaires, donc dans cet exemple : power, energy (ou virtualEnergyConsumption), et battery => On a 1 seul module dans l'interface, c'est propre, concis, et toutes les informations utiles sont bien présentes. Fibaro a inventé ce concept d'interface sur la HC2, il nous permet depuis la HC3 de l'appliquer aux QuickApps, autant en profiter.
  16. Oui ça c'est normal. Relis bien mon message, ce n'est pas ce que je demandais => Soit mettre le power sur un child existant d'un autre type, soit ajouter virtualEnergyConsumption sur ce child de type powerSensor
  17. J'ai l'impression que c'est une limitation actuelle de la box... je n'ai pas non plus cette option sur les powerSensors, alors que je l'ai que les autres types de modules (sur ma capture d'écran d'hier, c'était un binary switch, à laquelle j'ai ajouté l'interface "power") Barelle, plutôt que de créer un child dédié pour la mesure de puissance, est-ce que tu ne pourrais pas l'ajouter en tant qu'interface power sur un module existant (parent ou enfant) ? Si le type est différent, je pense que la HC3 laissera l'utilisateur activer l'option virtualenergyconsumtion. Autre piste, forcer l'ajout du virtualEnergyConsumption via l'API sur le child en question, je pense que ça peut marcher (auquel car ça serait juste une limitation de la page Web, mais pas de la box, ce ne serait pas la 1ère fois que Fibaro nous fait le coup)
  18. Voilà une capture d'écran : Barelle ne pourra pas cliquer à ta place
  19. Lazer

    black friday 2021

    Oui j'ai vu, super prix, mais y'a un doute sur le fait qu'il soit neuf ou reconditionné....
  20. Les modules qui remontent une puissance (power, en Watts) ne sont pas gérés par le panneau d'énergie. Comme son nom l'indique justement, il ne présente que les données issues des capteurs qui remontent une énergie (energy, en kWh) Ce que tu peux faire à partir d'un module qui remonte la puissance, c'est d'activer l'option virtualEnergyConsumption, il y a une case à cocher pour cela dans les propriétés du module. La box va automatiquement calculer l'énergie en kWh à partir de la consommation instantanée en W, et donc le module devrait être géré par le panneau d'énergie.
  21. Ah oui pas bête la DHT22, j'oublie toujours que le nouveau Smart Implant est compatible.
  22. Entre la fiabilité toute relative du capteur de température intégré, le fait qu'il soit situé sur la fenêtre (donc élément froid), et en hauteur (donc au dessus de la tête), et le fait que ça soit un module sur batterie donc pas adapté à remonter la température chaque minute, il est clair que ce type de module ne peut pas être utilisé pour de la gestion de chauffage. Ces capteurs de températures intégrés aux modules domotiques (FGK, FGMS, FGSD, etc), c'est du gadget plus argument commercial que réellement utile. A la limite ça donne une indication de l'ambiance générale de la pièce, mais c'est insuffisant pour gérer du chauffage. Le mieux ça reste la sonde Dallas (une originale, pas une clone chinoise) branchée sur un FGBS Smart Implant, ça c'est ultra fiable et précis. Le souci évidemment, c'est d'amener une alimentation électrique.
  23. Lazer

    Protocole SNMP

    @jjacques68 hum.... c'est moche Quick & Dirty comme ils disent .... ça marche, et puis un jour ça ne marchera plus
  24. Lazer

    Protocole SNMP

    Donc tu as tout réécris ? Tu est bien motivé...
  25. Ah, changement de comportement constaté lors de l'utilisation de net.httpClient() Lorsqu'on appelle http:request(), si l'hôte distant est joignable, la fonction success() est appelée, avec les entêtes et les données dans la variable response, qui est une table : httpClient:request(url, { success = function(response) print(response.status) --> Exemple : 404 print(response.data) --> Exemple : "" end, error = function(message) end, }) Quand le code retour est 404 (page non trouvée), la variable response.status contient bien le code 404, comme avant. En revanche, dans ce cas précis, le variable response.data est une chaine vide, même si l'hôte distant a retourné quelque chose (car plusieurs serveurs Web affichent un message personnalisé pour avertir l'utilisateur que le page demandée n'existe pas). Précédemment, response.data contenait cette page, ce n'est plus le cas maintenant. QuickApp affecté : Network Monitor Fibaro a dû considéré que le contenu de la page n'avait pas d'importance quand le code retour est 404, c'est bien dommage....
×
×
  • Créer...