Lazer

On doit avoir la même femme alors Je suis aussi en tout électrique, mais le gros de la consommation, c'est le chauffage, et l'eau chaude, donc entre le routeur, et la domotique, je vais essayer de déplacer un maximum en journée, quitte à surchauffer la maison la journée pour bénéficier de la chaleur en soirée/nuit par inertie, dans la mesure du possible (en mi-saison) Aller je vais mettre les graphs prédictifs justement.... Tiens sinon parmi les optimisations, je pense brancher le lave vaisselle sur le circuit d'eau chaude, ça devrait faire une grosse économie, surtout quand on le lance le soir quand il n'y a plus de soleil.

Tu as des bonnes conditions d'orientation, et en plus en PACA ça aide beaucoup Par contre, ton taux d'autoconsommation est vraiment bas, je pense que tu peux faire largement mieux, surtout avec la domotique. C'est lequel ton "power reducer" ? De mon coté j'ai commandé le Mk2PVRouter, mais le gars est débordé de commandes, donc je vais devoir attendre un peu. Comment tu chauffes le SPA ? En fait la question, c'est quel SPA tu as, où plutôt comment tu arrives à contrôler le chauffage indépendamment de la pompe ? Selon les modèles, ça n'a pas toujours l'air facile. Je n'ai pas de spa, mais j'y pense pour l'avenir, surtout que j'aurai énormément de surplus en été.

Je ne suis pas super fan du sleep dans ce cas précis, parce qu'en cas de crash de la box, redémarrage de GEA, ou tout autre événement, la pompe ne s'arrêtera jamais... ce qui qui peut vite couter très cher. Je préfère une 2nde règle distincte, qui détecte si la pompe est allumée depuis 15 minutes et l'éteint alors. Ainsi cette condition sera toujours remplie, même si GEA redémarre pendant les 15 minutes. Les Sleep, je trouve que c'est bien pour des actions non critiques, et de courtes durées (quelques secondes).

le souci c'est que tu as un Time entre 5:00 et 5:01, soit 2 minutes. Si tu mets une durée de 60*15, c'est bien trop long et surtout largement supérieur aux 2 minutes, donc ta règle ne "matchera" jamais. Les longues durées sont plutôt utilisées dans des scénarios du type : "si la lumière (ou la porte, ou l'arrosage, etc) est allumé depuis 15 minutes, alors faire ceci..." Dans ton cas, tu veux que l'action se déclenche précisément à 5h (modulo 30 secondes), donc c'est bien une durée de 0 qu'il faut utiliser. A noter que 30 ou 60 ou 90 fonctionneraient également puisque l'intervalle de Time est de 2 minutes, soit 120s.

D'accord, donc dans ce cas pas de déclenchement instantané nécessaire, tout simplement : GEA.add({{"Profile", "Home"}, {"Days", "Weekday"}, {"Time", "07:00", "07:01"}}, 0, "Allumage ID20 le #date# à #time#", {{"turnOn", ID20}}) GEA.add({{"Profile", "Home"}, {"Days", "Weekend"}, {"Time", "09:00", "09:01"}}, 0, "Allumage ID20 le #date# à #time#", {{"turnOn", ID20}}) Tu noteras : - l'utilisation d'une durée de 0 secondes (soit entre 0 et 30 secondes de délai de réaction dû aux cycles de GEA) - une plage horaire de 7h à 7h01, laissant largement le temps (2 minutes) pour que GEA puisse tomber dans cet intervalle (avec ses fameux cycles de 30s), ceci en cas de charge excessive de la box, micro-freeze, etc - on peut enlever les parenthèses vu que ce n'est plus une règle à déclenchement instantané Selon la même logique je corrige ta règle d'arrosage, mais tu as compris le principe : GEA.add({{"weather","clear"},{"months","june"},{"Time", "5:00", "5:01"}} , 0, "Arrosage le #date# à #time#", {{"turnOn", id_arrosage1},{"turnOn", id_arrosage2}}) Du coup j'ai mis une durée à 0s, GEA effectue le test à chaque cycle, et uniquement entre 5h et 5h01 il va déclencher l'arrosage (une seule fois) Attention ce que tu appelles le message de log est en réalité une notification push sur ton smartphone, si tu as bien configuré la variable GEA.portables = { ... } Si tu veux juste un log, il faut l'ajouter à la fin, ce qui donne : GEA.add({{"weather","clear"},{"months","june"},{"Time", "5:00", "5:01"}} , 0, "", {{"turnOn", {id_arrosage1, id_arrosage2}}, "Arrosage à 5h en juin") J'ai également optimisé l'écriture pour mettre les 2 ID dans une table pour la même action TurnOn.

J'ai isolé ta question qui n'avait rien à voir avec l'autre topic. Pour récupérer la valeur d'un module, c'est avec fibaro.get(id, property_name) L'ID tu le connais Le nom de la propriété dépend de ce que tu veux récupérer, en général c'est "value", mais ça peut aussi être "power", "batteryLevel", etc par exemples. A bookmarker : https://manuals.fibaro.com/home-center-3-lua-scenes/ https://manuals.fibaro.com/home-center-3-quick-apps/ Après si tu veux déclencher ta scène en fonction de conditions bien précises, il faut se reporter à la doc sur les scènes dont j'ai donné le lien juste au dessus, car il faut bien écrire ta condition de déclenchement de scène. Perso je n'ai que peu d'expérience (voire pas du tout...) car je fais tout sous GEA. Mais plusieurs personnes ici utilisent les scènes et sauront t'aider mieux que moi à ce sujet.

Un détecteur PIR 230V classique (non domotique), que tu trouves en GSB, avec un relai intégré prévu pour piloter une lampe. A la place de la lampe, tu installes un module FGS ou FGD, le relai du détecteur jouera le rôle d'interrupteur sur le module domotique. Au moins c'est fiable, étanche, résistant au froid, au chaud, pas de piles à changer, etc. C'est ce que je fais depuis des années, j'avais partagé le schéma de câblage sur le topic du FGD-211 il me semble.

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é.

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 Batterie de stockage : Victron et Pylontech Communication Modbus entre Victron et Enphase Ç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.

Cool, un module musical, c'est dingue ce qu'on arrive à faire avec un peu de domotique et d'impression 3D

J'ai retrouvé : 1ère page, 1er message, chapitre 7, tu as la solution pour Netatmo. Toujours bien lire le tuto jusqu'au bout

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

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 :

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...

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 ?

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.

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

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.

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...

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"

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)

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.

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

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)

Voilà une capture d'écran : Barelle ne pourra pas cliquer à ta place