Lazer

Salut Ludo, et bonne année Moi je n'ai pas (encore ?) installé HA, mais j'ai commencé à utiliser ESP Home, c'est bien sympa

OK alors alimentation 12V DC, oui ça existe surement, mais en fin de compte c'est le même souci, non compatible avec les modules volet-roulants classiques. Tu as peut être une chance si le moteur est alimenté en 12V DC par inversion de phase, comme les Velux filaires, dans ce cas tu peux utiliser un module Qubino Flush DC (compatible avec les box Fibaro) Le souci c'est que la plupart des vendeurs de stores ne précisent pas les caractéristiques ou le schéma électrique du moteur utilisé... il faudra surement contacter les vendeurs... s'ils savent répondre à la question, tant ce genre de demande doit être rare.

Ah ben voilà, si tu veux un truc sur batterie, tu retombes dans les machins avec télécommande propriétaire. Et puis comme tu dis, indépendamment de la domotique, les batteries ce n'est jamais l'idéal.

Oui, comme indiqué précédemment, j'ai pris chez RUEDUSTORE, le modèle DOMOTIC, le moteur est en 3 fils classiques (2 phases + 1 neutre), et donc parfaitement compatible avec les modules Fibaro FGR (ou n'importe quel autre module domotique). Le plus pénible c'est d'amener l'alimentation 230V. Mais pas sûr qu'ils commercialisent encore ce modèle, déjà à l'époque j'avais eu du mal à trouver, la tendance de fond est à l'enfermement dans des protocoles propriétaires. Ou alors attendre quelques mois/années, avec l'essor de Matter il y a des chances pour que tout cela change.

Mais si, tu mets les 2 conditions dans la même règle, comme tu avais commencé à l'écrire hier : GEA.add({{"Global+", "SMART", 1}, {"Global-", "SMART", 5}}, 30, ... Note que les valeurs 1 et 5 doivent être numérique, c'est mieux que sous forme de chaine de caractères. Comme évolution, ajouter un comparateur 'Entre', pourquoi pas, mais il faudrait lui trouver un symbole, sachant qu'on a déjà +, -, ! (condition de différence), et bien sûr rien du tout (condition d'égalité). ça pourrait être "><" par exemple. Donc en pratique ça donnerait un truc du style : {"Global><", "SMART", 10, 20} Un jour peut être... si je me remets au LUA.

Non je ne crois pas, je pense qu'il faut faire 2 tests, avec "Global+" et "Global-"

Tu as un visuel du QA ? Il ressemble à quoi ? C'est quoi son type ? La bonne solution, en tout cas celle qui respecte la logique Fibaro dans la HC3, ne serait pas d'utiliser le type thermostat ? Dans ce cas, il n'y a plus de question à se poser pour l'UI, on est guidé, l'interface ajoute automatiquement les boutons de réglage, et le module peut être intégré au panneau de chauffage, application, etc. Et pour que le QA fonctionne, il faut respecter les API imposées pour les thermostats (setThermostatMode(), setHeatingThermostatSetpoint(), etc) Le mieux est de partir d'un QA exemple thermostat, et d'ajouter son code dedans. J'ai fait cela pour un QA qui pilote ma PAC. En effet, la sonde de T° du split est à 2m de haut, donc pas précis. Mon QA prend une sonde dans la pièce, et régule la température au 1/10 de degré près en pilotant la PAC (plus chaud/moins chaud, force la vitesse du ventilo pour la remonté rapide de température, etc). Ce n'est pas de la régulation PID, mais un bricolage adapté au split mural.

@olivier828 j'ai fusionné tes messages avec le topic du Link RS car j'ai constaté que tu as pompé ton code depuis ce topic, donc c'est plus logique de poursuivre la discussion ici... on aurait même gagné du temps. EDIT : ah et tu avais même participé, maintenant je comprends mieux.

Donc ton souci doit se situer au moment d'envoyer la nouvelle consigne aux vanne avec les commandes suivantes que tu as mis dans ton 1er message : local lc13 = {208} for i=1, #lc13 do fibaro:call(lc13, "setTargetLevel", rstemp) fibaro:call(lc13, "setTime", rstime) end Parce que déjà tu as une erreur LUA. Un truc comme ça (non testé) serait déjà plus correct : local lc13 = {208} for _, id in ipairs(lc13) do fibaro:call(id, "setTargetLevel", rstemp) fibaro:call(id, "setTime", rstime) end Ensuite vérifie dans le JSON du module (/api/ID) que les actions sont bien setTargetLevel et setTime (je n'ai pas ces modules donc je ne peux pas vérifier) Parce que justement tu lui envoie le paramètre rstime avec l'action setTime, qui doit logiquement être un timestamp UNIX indiquant l'heure de fin de la nouvelle consigne là tu ne connais même pas la valeur de ce timestamp car tu le récupères depuis le module 220 Autre remarque, dans l'entête (trigger) de ta scène tu as un ID 141 je ne sais pas d'où il vient, surement une erreur. Tu voulais surement écrire 220 Attention aussi au xx timestamp qui est incorrect et n'a rien à faire là Je crois bien oui, mais à vérifier par des tests sur ta box

Attention avec le module "RS", je crois qu'il existe (enfin "existait" car ce n'est plus produit) plusieurs versions. J'ai la version Link RS dont on parle sur ce topic : Elle communique en Z-Wave. Je crois me souvenir (à confirmer) que l'autre version communiquait avec le protocole propriétaire de Danfoss, directement entre la sonde RS et les têtes LC13. Donc usage autonome, et par conséquent indépendant de la domotique qui nous intéresse. Comme son nom l'indique, le module RS n'est PAS un thermostat, mais une simple sonde d'ambiance, avec 2 boutons permettant de modifier la température de consigne d'un thermostat. Le thermostat (c'est à dire l'organe responsable de la régulation de température) est situé ailleurs. Soit dans la box (thermostat logiciel : par exemple QuickApp dédié ou modules liés dans le panneau de chauffage), soit dans le module cible... par exemple le Secure SRT321, les têtes thermostatiques Fibaro, ou bien encore les têtes thermostatiques Danfoss LC13 dont tu disposes justement. Et c'est là que ça se complique, car selon la version du module RS utilisé, la liaison est soit directe entre le RS et la LC13, soit passe par le contrôleur Z-Wave (la box domotique donc) sur laquelle il faut créer un petit scénario pour transmettre la consigne du RS vers le thermostat de la LS13. Mais j'espère déjà que ces explications te permettront d'y voir plus clair. Et justement, la lecture de ton premier post n'est pas claire, car tu sembles confondre les notions de température de consigne et de thermostat. Pourtant le script LUA que tu as écrit laisse penser que tu avais bien les versions Z-Wave des modules, et tu as justement mis en oeuvre la liaison logique entre la consigne du module RS et le thermostat de la vanne LS13. Je n'ai pas de LC13, donc je ne pourrai pas t'en dire plus. Je n'ai plus non plus de HC2. Peut être un problème d'inclusion du module LC13 dans la box, ou bien d'intervalle de réveil trop long.

Ah mais c'est sûr qu'au tarif normal ce n'est pas du tout intéressant, sauf à monter une très grosse installation surdimensionnée avec comme objectif de vendre un maximum de surplus... auquel cas ça devient même plus intéressant que la pose par une entreprise agréée RGE avec vente à EDF-OA. Mais oui avec JPME il y a un risque certain vis à vis de la pérennité de l'entreprise. Sur les forums on trouve déjà quelques clients depuis 1 an, qui en sont satisfaits jusqu'à présent. La semaine dernière, lorsque j'ai souscrit, j'ai posé la question et il restait parait-il une dizaine de places parmi les 250 proposées... bluff ou pas, je ne sais pas... Pour la batterie, l'idéal c'est la "batterie" naturelle comme tu fais, chauffer de l'eau c'est bien plus économique (et écologique) que d'installer des batteries Li-ion. Du coup même remarque que la vente de surplus, la batterie ça n'est rentable qu'avec un très gros surplus. Déjà moi je n'ai pas de surplus d'octobre à avril, soit 6 mois dans l'année, donc déjà je sais que la batterie ne tourne que l'autre moitié de l'année... pas terrible. Sinon faut faire de ce qui est interdit par Enedis : charger la batterie depuis le réseau en HC, et l'utiliser pendant les HP. Mais avec les pertes de charges (environ 20%) et la faible différence de prix HC/HP (20% aussi), ça n'est même pas rentable économiquement, et en plus ça use des cycles de batterie. Il faudrait une énorme augmentation des prix de l'électricité (pas juste 15%, mais 50, voire 100% comme au UK) pour inverser la tendance en France. Et une politique publique en faveur du délestage/effacement de consommation, donc une franche différence de tarif HC/HP. Avec tout ça, le calcul ne serait plus le même. @mprinfo au rythme où va le climat, ce n'est pas de la géothermie (chauffage) qu'il faudra bientôt, mais de la "géoclimatisation". Je ne sais pas si le rafraichissement se pratique en géothermie profonde, mais le principe est connu depuis longtemps avec les puits canadien/provençal, c'est réversible par nature. Justement Nico, ta PAC n'est pas réversible, elle ne sait pas aller puiser la fraicheur en sous-sol l'été ?

En effet, le 1 s'était fait la malle, tout de suite 10 MWh manquants 2011 ça change tout C'est corrigé. Au moins tu as bien lu les chiffres Vu les frais d'activation du dossier de rachat, c'est clair que ce n'est potentiellement rentable qu'avec un gros surplus. J'ai eu 1369 kWh de surplus en 2022, donc avec les nouveaux tarifs de rachat à partir du 1er janvier 2023 à 17 cts/kWh, ça fait 233 € annuels, soit 2 ans et demi avant de rentabiliser les frais de dossier. Et ça reste un gros pari, car JPME est une petite structure dont l'avenir n'est pas assurée, de même que le montant du rachat... même s'il a tendance à augmenter fortement depuis 2 ans, en rapport avec la crise énergétique... parions que ça va durer encore quelques années. D'où l'intérêt d'installer encore des panneaux supplémentaires, j'en consommerai une partie, et vendrai le surplus, ça ne fera qu'accélérer le retour sur investissement. Passer en TEMPO peut être intéressant aussi, car aux tarifs actuels, vendre son électricité à JPME est plus rentable que de l'acheter à EDF pendant 343 jours par an ! Et même plus que ça, car dans les 22 jours rouges, sur les HP sont plus chères. Justement j'attends avec impatience les tarifs de février... enfin, impatience, pas tant que ça, car on paiera plus cher en fait... Ah les batteries... Je lisais un article récemment où le rédacteur faisait mine de s'étonner que les batteries domestiques ne se vendent pas du tout en France comparé aux autres pays du monde... tu m'étonnes, ce n'est pas rentabilisable à l'heure actuelle, la batterie est HS avant d'avoir atteint le ROI (sauf à monter une batterie soi-même avec les cellules importées de Chine... faut être joueur) On pourrait se dire qu'avec l'augmentation des tarifs de l'électricité, les batteries seront plus rentables, mais même pas, car en 2022 les tarifs des batteries ont explosé. Je n'ai pas l'impression que ça va se calmer en 2023. On verra. Reste la recherche de l'autonomie pour les sites isolés, la peur de ne pas survivre avec une coupure électrique de 2h, ou d'autres raisons qui font que certains en ont quand même installé, mais ça reste très rare en pratique. En tout cas avec le rachat par JPME, je vais potentiellement définitivement une croix sur les batteries. Sinon il y a Urban Solar, qui est plus gros (fournisseur d'électricité) qui commercialise maintenant une offre de rachat du surplus "Boot mon surplus". Mais l'offre est toute nouvelle, et le tarif est variable mois après mois, donc difficile de faire un calcul de rentabilité. Sinon ils commercialisent l'offre avec batterie virtuelle, mais elle n'est accessible qu'en s'engageant chez eux comme fournisseur. Pour moi c'est bloquant.

Bonne année les illuminés de soleil Petit bilan de l'année 2022, je suis passé d'une consommation annuelle de : 12618 kWh en 2021 à : 9037 kWh en 2022 Soit 28% de réduction de consommation sur la facture EDF, sachant que je n'ai installé les panneaux que fin mars 2022, et qu'on a un véhicule électrique de plus à charger à la maison. Gain/économie valorisé à 588 € Taux d'autoconsommation moyen sur 2022 : 72% Exactement celui que j'avais estimé dans mes simulations décrites dans les 1ères pages de ce topic, sachant qu'il manque les mois de janvier à mars qui feront remonter ce taux Rappel de mon installation : 14 panneaux + MO, soit 5670 Wc pour 4060 VA Projets énergétiques pour 2023 : en cours : pose d'une seconde pompe à chaleur (quadri-split air/air) probable : ajout de panneaux supplémentaires (dimensionnement à calculer) envisageable : passage en tarification TEMPO (dépendra beaucoup des tarifs à partir de février) en cours : dossier de vente du surplus à JPME A ce sujet, j'ai souscrit chez JPME à la E-batterie Super+ pour le rachat de mon surplus solaire : https://batterievirtuelle.fr/ J'ai profité de la promo de Noël qui réduit de moitié les frais d'activation du service : 400 au lieu de 800€. Mais il faudra quand même ajouter 180 € pour le Consuel, que je ne pourrai pas éviter cette fois-ci, donc 580 € en tout. Le temps que le dossier Consuel soit fait, puis l'activation du contrat de raccordement en production chez Enedis (géré par les services de JPME), ça devrait prendre maximum 4 mois (moins que ça si tout se passe bien), donc ça nous amènera en avril quand je commencerai à avoir un peu de surplus.

Voilà, tout est dans le titre Je vous souhaite une bonne année 2023, sans aucun projet domotique car ça voudra dire que votre domotique est parfaite et ne nécessite plus d'améliorations bah quoi, on peut rêver

Welcome to the forum

Il doit y avoir pas mal de discussions dans la section QuickApp > Support.

Je rebondis juste là dessus... non ta loop n'est toujours pas dans un settimout, du moins pas la 1ère exécution, et c'est celle-ci qui est critique : function QuickApp:onInit() -- Fait plein de choses self:loop() end A remplacer par : fibaro.setTimeout(0, function() self:loop() end) Là j'ai mis un timeout à 0, mais perso j'ai pris l'habitude de mettre un timeout plus important, entre 1000ms et 5000ms selon mes QuickApps. En effet, au reboot de la box, tous les QA démarrent en même temps, ce timeout variable permet de temporiser un peu et lisser la charge.

Désolé mais je n'ai pas le temps/courage de me lancer dans un nouveau tuto ces temps ci. Mais ce sont des discussions qu'on a déjà largement abordé en 2020/2021 lorsqu'on est plusieurs à s'être lancé dans le développement de QuickApp suite à la sortie de la HC3, le problème c'est que c'est disséminé un peu partout sur le forum. self désigne l'objet courant. C'est une notion qui fait référence à la programmation orienté objet. Même si en réalité, LUA n'est pas un vrai langage orienté objet comme peuvent l'être le C++ ou le Java. Les objets instanciés à partir des classes sont en réalité des variable de type tables au sens LUA. Une table est une variable qui contient n'importe quoi : des fonctions, des string, des boolean, d'autres tables imbriquées, etc. Fibaro utilise ces notions pour les QA. Il faut voir QuickApp comme étant une classe, et quickApp (sans la majuscule) comme étant une instance d'objet dérivée de la classe (même si en réalité, d'un point de vue LUA, c'est une table, on l'a dit au-dessus) self, si utilisé à l'intérieur d'une fonction membre de QuickApp, pointe alors sur l'instance de l'objet quickApp. self n'est pas utilisable en dehors d'une fonction membre de QuickApp, sauf à le passer explicitement en paramètre lors de l'appel d'une autre fonction (cette autre fonction qui peut être membre d'une autre classe, locale, ou globale, peu importe) Quand on a plusieurs Child Devices, chaque enfant est une instance objet de la classe QuickAppChild (elle même dérivée de QuickApp). A l'intérieur de chaque enfant, self pointe sur l'objet courant. Bref, il te faut revoir les bases de la programmation orientée objet (pleins de tutos sur le net) Puis l'implémentation spécifique LUA/Fibaro, pour cela je t'invite à (re)lire l'excellent exposé de Jang sur l'anatomie d'un QuickApp : 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

Quelques pistes : - la fonction initChildDevices() doit être la première appelée dans le onInit du QA, donc avant d'appeler les fonctions updateProperty, getVariable, et surtout loop() - idéalement c'est mieux d'appeler la fonction loop() dans un setTimeout, même avec un délai de 0, car ça déclenche un process asynchrone donc après la fin de l'exécution de onInit() - toutes tes fonctions createChildXXX() ne devraient pas être dans le onInit(), il faut les mettre dans une fonction spécifique, exécutée avec un bouton par l'utilisateur

N'hésite pas si tu as une question, pour approfondir la réponse de l'autre topic. EDIT : ah Jang vient de donner des détails complémentaires

Plus sérieusement, le message suivant ne te donne pas la réponse ?

Joyeuses fêtes de fin d'année EDIT : mais ce n'était peut être pas la réponse attendue

Erreur classique. Voir :

En ce qui me concerne, j'ai des notifications à chaque reboot/redémarrage des services Fibaro, et aucun reboot intempestif à signaler. Et pas de message d'avertissement dans le centre de notification. A noter que j'ai mon script de sauvegarde automatique qui s'exécute une fois par semaine, donc les services redémarrent à ce moment là.

Bienvenue sur le forum