RS600807

Il est vrai que sur des splits, il y a moins de chose à peaufiner que sur un Pl chauffant où l'inertie du bâti est par ex. un paramètre important dont il faut tenir compte dans ses réglages... Ouais c'est sûr que les coûts pour la réno peuvent vite s'envoler... Mais sur du neuf, les coûts ne sont pas nécessairement plus bas, étant dictés par la RT où les indicateurs de performances des bâtis ont été durcis ou changés entre la RT2012 et la RT2020. Quoi qu'il en soit, les budgets ne sont pas extensibles... C'est bien là l'intérêt de la domotique! Quand je me suis lancé au travers de ce forum, j'ai découvert le champ des possibilités. Et il faut bien reconnaître que GEA est un "outil" devenu indispensable pour moi! Là où c'est d'autant plus fort, c'est que sans connaissance particulière en programmation, on prend assez vite en main son utilisation, avec le tuto de syntaxe en back-up quand on a un doute :)) ! Ca reste quand même plutôt élevé, si je me base sur les retours que j'ai pu voir sur les forums où ça tourne plutôt autour de 25-30%. Pour ma part, mon profil journalier actuel fleurte de plus en plus avec les 50% (il était autour de 63% en mars), voire en dessous sur de forts ensoleillements. Ceci étant la conséquence directe du fait d'avoir coupé le chauffage depuis début avril, accentué par une production plus importante des panneaux. Et ça va forcément baisser avec les beaux jours qui reviennent, sachant que je ne cherche pas à allumer le four de la cuisine pour le plaisir de bruler des kWh et maintenir mon auto-conso C'est vrai que les retours ne sont pas encourageants. Ca ressemble de plus en plus à une pyramide de Ponzi leur entreprise... J'espère me tromper pour les clients qui ont souscrit. Mais quand on regarde les solutions alternatives à EDF OA pour les auto-installateurs, je n'ai pas vu d'offre intéressante...

Merci @Lazer pour ce retour instructif après une année glissante de fonctionnement. Je suis également convaincu que Tempo et panneaux PV sont très complémentaires. Ce serait même dommage de se priver de l'un ou de l'autre compte-tenues des plages horaires HC/HP (les panneaux PV couvrant en bonne partie voire totalement le bruit de fond sur la tranche HP, même en hiver). Autant c'est relativement simple de faire basculer son abo edf autant certains sont plus réticents à monter sur leur toit ou se lancer dans l'aventure... Question de choix qui appartient à chacun. Quant à la PAC, pas surpris que les économies soient au rdv. Là encore les appareils actuels proposent des performances et des modes de fonctionnement (inverter notamment) très intéressants. Encore faut-il qu'ils soient bien réglés par l'installateur (très souvent ce n'est pas le cas, et je ne jette pas la pierre aux artisans) ou l'utilisateur (qui n'a pas forcément l'envie de se fader les 200 pages du manuel technique). Mais là aussi, j'ajouterais que si on veut faire des économies un bon système de chauffage ne va pas sans une bonne isolation! Plus de 63% d'autoconso, c'est assez remarquable pour une moyenne annuelle (si c'est bien ce qu'il faut lire). Il me semble que tu avais opté pour une revente chez JPME. As tu par conséquent favorisé l'auto-consommation au détriment de la revente chez JPME (dont j'ai pu lire des avis assez mitigés) ?

J'étais certainement dans la même réflexion que toi il y a presque 2 mois. Aujourd'hui, même si je n'ai que 2 mois de recul, les économies sont déjà là... Je suis aussi en tout électrique à la maison, sans appoint supplémentaire (si ce n'est les panneaux sur le toit :)). Mais avec une maison en RT2012 (ou RT2020), dans une région où ce n'est pas non plus le froid polaire (je suis en gironde, toi dans les yvelines) l'inertie et l'isolation feront le job, sans amputer le confort thermique dans la maison (c'est le cas chez moi). Si tu as des panneaux solaires, c'est je crois une très bonne opportunité à saisir, même s'il faut rester "un peu" vigilant 22 jours dans l'année !

OK. Si j'avais "compris" cela plus tôt, je ne me serai pas casser la tête pour faire coller les étiquettes réellement renvoyées par mon linky avec les lignes de configuration à mettre au niveau de la téléinfo. Dans ma logique, il fallait associer l'étiquette au child qu'on voulait créer, comme pour les tores qu'on associe au bon sous-poste par ex. Je plaide coupable, j'aurais dû recopier bêtement la ligne indiquée dans le tuto! Je ne sais pas si je suis le seul à avoir rencontré ce pb, mais peut-être que rajouter un commentaire dans le tuto du QA GCE en indiquant que "la config de la téléinfo doit être recopiée telle quelle, quel que soit le type d'abonnement (base, tempo, EJP...)" --> Effectivement, avec pin = "EAST", cette fois la variable se met bien à jour... et ne reste plus vide comme jusqu'à maintenant. Merci pour toute ton aide et ta patience! Je comprends que ce ne doit pas être simple pour des initiés comme toi de gérer les cas et les conneries des non-initiés comme moi ! Le pb semble résolu. Je vérifierai tout de même le log du QA Tempo dans la nuit pour être sûr, le pb ayant été identifié à partir de ce QA... Nouveau proverbe du jour (c'est d'actualité avec les grèves SNCF) : un QA mal configuré peut en cacher un autre !

OK pour le name, j'ai vu qu'on pouvait les renommer après coup. L'étiquette EAST n'existe pas chez moi en mode tempo historique. Elle existait bien avant, quand j'étais en base. Mais là elle n'est plus disponible. Donc je devrais mettre quelle étiquette parmi celles-ci ? Ce n'est pas vraiment que j'ai voulu jouer aux apprentis sorciers. J'ai suivi une logique assez triviale (peut-être ?) en me basant sur les étiquettes que me renvoie la TI du linky. L'intérêt que j'y vois c'est d'avoir un visuel direct sur l 'index du jour (ou total) au lieu de passer par l'interface de mon EDRT2. C'est déjà ce que je fais un peu ici : je récupère les index sur les sous-postes. Donc en clair, il faut que : - je supprime tous les device avec type ="teleinfo", - que j'en crée un nouveau avec pin ="xxx" où "xxx" est l'étiquette à choisir, --> alors la variable TELEINFO_Tarif devrait être correctement alimentée cette fois, correct ?

Salut, Je rencontre un soucis dans la configuration de mon QA GCE avec mon EDRT2. La variable TELEINFO_tarif n'est pas alimentée correctement. J'avais la configuration suivante : @Lazer m'a indiqué qu'on ne peut avoir qu'une seule ligne de configuration pour la Téléinfo. Là j'en ai 6, pour chacun de mes 6 index Tempo. Mais le QA GCE n'envoie aucun avertissement ou aucune erreur. Si on ne peut avoir qu'une seule ligne, comment obtient-on les 6 index séparemment, i.e. dans des child séparés ?

OK, je bascule sur le topic GCE.

J'ai eu un premier retour du support fibaro. Ils ne peuvent pas intervenir sur les QA (et scènes) créés par les utilisateurs. Il faut se tourner vers le créateur du QA... Je vais insister sur le fait qu'il y a tout de même un éventuel pb avec la box. J'avais vu cette partie là du code. je pensais au début qu'il pouvait y avoir un soucis avec le string.find car je ne savais pas ce que cette fct détectait, i.e. s'il fallait que la variable contienne juste "JB", "JW ou "JR" ou si une trame du type "xxJB" ou "xxJW" ou "xxJR" convenait) mais j'ai compris ensuite en recherchant des infos sur cette fct. Oui, c'est pour cela que j'ai fini par en déduire que le pb venait certainement de la variable TELEINFO_Tarif, alimentée elle-même par le QA GCE. Je suis allé le relire plusieurs fois. Je n'ai aucun warning ou erreur retournée par le QA GCE. Pardon, mais ce n'est pas forcément clair pour moi entre ce que je vois dans le descriptif et ce que tu m'indiques : J'avais créé 6 index totaux sur la base du modèle ci-dessus, en remplaçant pin="EAST" pour chaque index par pin = "BBRxxxx" correspondantes (--> pas de warning ou d'erreur du QA GCE). --> Je viens donc de supprimer la variable TELEINFO_tarif, j'ai viré les options pour 5 de mes 6 index. Il recrée la variable TELEINFO_tarif et pourtant cette variable reste vide...

J'ai contacté le support fibaro. Ils ont ouvert un ticket. En attendant de voir ce qu'ils vont éventuellement trouver, quelques nouvelles supplémentaires : - j'ai vérifié dans l'historique de la box. Rien d'anormal de ce que j'ai pu voir, tous les QA communiquent régulièrement, de même que les modules Z-wave - j'ai récupéré le nouveau log de cette nuit : log.lua. Il est bien complet (pas de "trou" comme la dernière fois, j'ai laissé le PC allumé pour écarter toute cause possible !) et tout semble indiquer que le QA fonctionne correctement dans la récupération et la mise à jour des variables. Je pense avoir isolé le pb, qui semble venir de cette variable TELEINFO_tarif. En effet, sur le log: - tout est correct jusqu'à 7h00 - puis àpartir de 7h00 il interroge RTE et teste le tarif de la teleinfo (dont j'avais rentré la valeur HPJB hier matin). TELINFO_Tarif n'aurait-elle pas dû passer à HPJW à 7h00, par une mise à jour du QA GCE? - il voit qu'il y a une différence entre la valeur du tarif et la couleur du jour - il conserve alors la couleur associée à la valeur de tarif_teleinfo (dans le cas présent bleau) - à 7h51, je modifie la valeur de TELEINFO_tarif par "" et là il actualise la variable Tempo_Jour en blanc (car il n'a rien trouvé dans la variable TELEINFO_tarif) La variable TELEINFO_tarif se met à jour par l'EDRT2 (via le QA GCE). Et ensuite, tu recherches dans le main du QA Tempo la valeur de cette variable, correct ? Alors ça voudrait dire que j'ai peut-être raté quelque chose au moment de la configuration du QA GCE, car celui-ci ne semble pas mettre à jour la variable TELEINFO_Tarif (il y a une règle de push supplémentaire à faire ?) Voilà ce que j'ai au niveau du fichier config du QA GCE : Les warning n'apparaissant que lorsqu'il voit que le tarif de la TI n'est pas compatible avec la couleur du jour, je ne crois pas que ce soit un pb du QA Tempo, mais plutôt un pb dans ma config du QA GCE (sachant que mon EDRT2 semble capricieux pour enregistrer correctement sa configuration, comme je l'ai indiqué sur un autre topic) Tu en penses quoi ?

Salut @Lazer Merci pour ton retour. Je vais contacter le support pour voir s'il y a quelque chose de particulier avec la box. C'est très bizarre parce que typiquement cette nuit, tout a semble-t-il fonctionné correctement : j'ai bien une trace toutes les 15min, et la mise à jour des variables TempoJour et TempoDemain s'est faite correctement. Non pas de pb observé. Je suis en version 5.150.18. Et depuis que je suis en version stable, je ne rencontre plus de redémarrage intempestif comme avant (en pleine nuit, 1 à 2 fois par mois). Hormis des messages de notifications dans la rubrique notification qui ne veulent pas s'effacer, rien de particulier avec les QA, ils fonctionnent tous correctement. Je vais voir cette nuit ce que ça donne, en attendant le retour du support fibaro.

Salut @Lazer, Les mêmes causes produisant les mêmes effets, avec la transition blanc -> bleu de cette nuit, j'ai de nouveau reçu les alertes que je m'attendais à recevoir. Voilà le log de cette nuit : log du 20-02 au 21-02.lua La première alerte démarre bien à 7h du matin, ce qui est conforme aux attentes d'après ce que tu me disais plus haut. A minuit, il n'a visiblement pas actualisé les vg Tempo_Jour et Tempo_demain, comme on le voit sur le log. et comme le confirme l'état des vg dans la liste des variables que j'ai contrôlée ce matin à 8h (il est resté "bloqué" sur le jour d'hier) Les notifications sont donc cohérentes d'un certain point de vue. Ce qui l'est moins, c'est pourquoi il n'y a plus de debug ni de trace entre 23h01 et 7h37? C'est d'autant plus étonnant que dans le précédent log que je t'avais transmis, on avait bien vu qu'il mettait correctement à jour les vg à minuit. C'est comme s'il y avait une interruption du QA. Question : la fenêtre de log s'interrompt-elle de stocker les infos lorsque le PC passe en veille ou veille prolongée ? J'ai mis le PC en veille vers 23h15 en allant me coucher, c'était probablement une erreur. Et je ne l'ai sorti de veille que ce matin vers 8h15 (alors que j'ai les premiers debug à 7h37). Je viens de faire une petite manip en relançant le QA. Chronologiquement : - on voit qu'à 9:43:18 il détecte bien les couleurs du jour (bleu) et de demain (bleu) mais pas correctement la téléinformation (il est resté sur le tarif de la veille (jour blanc)). - il affiche ensuite le warning (je reçois par conséquent la notification). - il indique que la couleur du jour est alors blanc. Je vois 2 choses qui m'interpellent : - C'est comme s'il ne tenait pas compte des détections qu'il avait faites après la 1ere requête RTE. Et je m'attendais aussi à ce qu'il mette à jour les VG Tempo_Jour et Tempo_Demain après cette détection, mais elles n'apparaissent pas dans le log. - Il devrait détecter que le tarif de la TI est bleu (car c'est bien ce que renvoie mon EDRT2 sur l'étiquette PTEC) et pourtant il dit qu'il est sur blanc. C'est comme s'il n'avait pas consulté à nouveau l'edrt2 pour récupérer la valeur de l'étiquette PTEC et qu'il avait conservé la valeur de la veille. Manip subsidiaire : je viens de remplacer la valeur de la TELEINFO_Tarif par une chaine vide et j'ai relançé le QA. Cette fois il prend bien en compte les détections qu'il a faites sur RTE et EDF, et met à jour la vg Tempo_Jour. D'où ma question subsidiaire : la variable TELEINFO_Tarif ne doit-elle pas contenir la valeur du tarif en cours (étant en mode historique, je devrais voir apparaître l'étiquette HPJB) ? ou doit-elle rester vide (j'ai mis "" car on ne peut pas laisser un champ vide) ? Si c'est lié à cela, je comprends quand est apparu mon soucis... Le premier jour où j'ai basculé en abo TEMPO, c'était un jour blanc. Or le premier jour, EDF nous met automatiquement en jour bleu, comme vu précédemment. Etant donné que je recevais des notif indiquant que la couleur du jour (forcé par EDF) ne correspondait pas au tarif de la TI, j'ai dû mettre la valeur "HPJB" à la variable TELEINFO_Tarif. Et dès que j'ai un jour de couleur différente, je suis obligé de modifier manuellement sa valeur pour faire cesser les notifications. As-tu la même lecture que moi ?

Salut @mprinfo, Je pense avoir résolu le pb (à confirmer lors d'un jour rouge). Peut-être que ça pourra servir pour un autre utilisateur à qui l'EDRT2 fait des siennes! J'ai supprimé les index de télé information concernant la couleur rouge (ceux qui ne semblaient pas fonctionner correctement) et je les ai recréés. Et à mon étonnement, avec les mêmes étiquettes et paramètres, cette fois cela fonctionne (on voit que les index courants sont bien à jour pour les HC et HP rouge, alors qu'ils restaient à 0 avant). Je ne sais pas trop pourquoi ça a fait cela. Comme je l'avais dit plus haut, me concernant ce n'est pas la première fois que l'EDRT2 initialise mal les paramètres ou a du mal à enregistrer correctement une configuration du premier coup. A moins d'un pb sur mon produit, c'est assez surprenant de la part d'un produit qui n'est tout de même pas donné.

Merci pour tes réponses. Voilà le log que j'obtiens : log.lua J'ai vérifié dans le QA de mprinfo, ce ne sont pas les mêmes noms de variable. Donc il n'y aurait pas de raison que ce soit gênant avec ton QA. D'après le log, on voit que les variables globales sont bien mises à jour (et je suis allé les contrôler également dans le tableau des variables) : la variable tempo_demain est passée à non défini et tempo_jour est restée blanc). Le QA semble réagir de la même façon chez moi que chez toi. Et pourtant lundi matin, quand j'ai regardé l'état des variables, je peux certifier que la VG tempo_jour etait sur bleu... Une chose m'intrigue : aurais-tu désactivé les notifications, car j'en comprends que tu n'as besoin finalement que des variables globales pour les scenarii GEA ? Cela pourrait expliquer pourquoi je reçois les notifications d'incompatibilité couleur jour/tarif lors d'une transition entre 2 jours de couleur différente alors que tu ne les reçois pas (a priori). Cela ne me gêne pas en soi que ce soit calé sur les jours calendaires. Je cherche simplement à comprendre si j'ai un bug dans ma config, s'il y a réellement une "fausse alarme" entre la valeur réelle des variables globales qui sont mises à jour et les messages de notification ou si c'est encore autre chose... Car il y a pour moi un mystère non résolu: on a une configuration similaire et pourtant des résultats sensiblement différents (tes VG sont bien actualisées et tu n'as pas de messages d'alarme). Il faut que je refasse la manip quand deux jours de couleur différente vont se présenter à nouveau, afin de voir ce que ça dit au niveau des logs. Merci pour ta patience en tous les cas, parfois on peut avoir l'impression d'être pris pour un fou quand on obtient des résultats différents des autres

Salut @Lazer, C'est noté pour la mise en forme du fichier log, merci pour le mode opératoire. Je n'ai l'historique que depuis 8h06 : Y a-t-il un moyen de récupérer les actions depuis l'heure qu'on souhaite quand on a fermé la fenêtre de log ? Je vérifierai cette nuit les transitions pour les variables Tempo_jour et Tempo_demain afin de voir s'il récupère les bonnes informations (je suis quasi certain qu'il le fait bien !) et je prendrai le log dès ce soir. En prenant le cas d'hier (bleu) et d'aujourd'hui (blanc), si la variable Tempo-Jour s'actualise dès minuit, à quelle heure l'état du QA est-il modifié, i.e. à quelle heure l'icone passe du bleu au blanc ? Car pour le coup mon QA n'a jamais basculé en blanc. Il est resté en bleu (jusqu'à que je décide de le basculer manuellement en blanc, pour arrêter les notifications toutes les 5 min, en allant dans dashboard/paramètres/général/variables). Ma vision est qu'il devrait basculer à 6h00, sinon on risquerait d'avoir un conflit permanent entre 00h00 et 6h00 du fait d'une couleur (HP blanc) qui ne correspondrait pas au tarif en cours (qui serait HC bleu). Est-ce qu'un conflit (variables globales qui trainent?) pourrait être possible entre l'appli de @mprinfo (que j'avais installée puis désinstallée) et la tienne ? Ci-dessous l'historique du QA entre 5h59 et 6h00 : le tarif bascule bien (HCJB -> HPJW), mais pas l'état.

Merci @Barelle. Ce n'est pas précisément le message d'alarme lié à RTE qui m'inquiète. C'est plutôt le fait que la variable Tempo_Jour ne se mette pas à jour à 6h du matin pour indiquer la "vraie" couleur en cours, alors que la couleur est bien détectée la veille pour le lendemain. D'un jour bleu à blanc, ce n'est pas très grave. Mais si c'est d'un jour bleu à rouge, ça peut vite devenir catastrophique (économiquement parlant !). Pour être clair, hier le QA avait bien détecté qu'aujourd'hui serait un jour blanc. A 6h ce matin, il aurait dû basculer sur blanc alors qu'il est resté sur bleu. Et comme le tarif en cours est correctement remonté, il y a alors incohérence entre la couleur du jour identifiée et le tarif.