Lazer

Bienvenue sur le forum

C'est possible, mais pas simple. Je t'invite à regarder ce sujet :

Bienvenue sur le forum Pour tes questions, je te suggère de les poser dans un nouveau topic, par exemple ici : https://www.domotique-fibaro.fr/forum/117-support/ PS : oublie la HCL, ce produit n'aurait jamais dû exister...

OK oui en effet, nous on a pris l'habitude de faire tourner les machines à laver, etc la nuit, afin de maximiser la conso en HC. Malgré cela on était arrivé à 30€ seulement de gain en étant en abo HC/HP, je me disais qu'à ce rythme là, dans 1 an je repasse en tarif BASE (surtout qu'on vient de me poser Linky, donc le changement d'abo est gratuit maintenant, car effectué à distance). Mais dernièrement une voiture rechargeable est arrivée, redonnant de l'intérêt au tarif HC/HP. Mais pour combien de temps ? A terme, les abonnements en heure creuse la nuit disparaitront, et seront remplacés par des abonnements aux tarifs variables chaque heure. On n'en est pas encore là, mais ça va venir. Je comprends bien pourquoi tu ne veux pas laisser tourner le ballon H24, afin de ne pas maintenir inutilement de l'eau à sa plus haute température (déperdition thermiques) Mais du coup, pourquoi ne pas faire ce que je fais ? Au lieu de suivre les horaires historiques de ton HC, ce qui n'a plus aucun intérêt vis à vis du tarif, pourquoi ne pas décaler les horaires de chauffe le plus tard possible dans la nuit, de façon à avoir de l'eau chaude juste avant les douches du matin ? Avec la domotique, tu peux programmer le scénario que tu veux pour déclencher le module FGS aux horaires voulus.

Bienvenue sur le forum

De mon coté je reçois toujours les notifications Push, aucun problème. Aussi bien avec la HC2 que la HC3. Avec l'ancienne, et la nouvelle application mobile. Je précise que je suis sur Android, au cas où. Mais bon, il y a des dizaines de topics déjà ouverts à ce sujet (@twentycents tu n'as pas bien cherché ), et c'est toujours la même histoire : comportement très aléatoire depuis des années.

Oui mais je voulais dire c'est que s'il le relai ne bascule plus, c'est qu'il a changé d'abonnement. Cela dit, si c'était le cas, je ne comprends pas pourquoi il veut continuer à ne chauffer que la nuit dans ce cas là. Attendons sa réponse

Je pense qu'il s'est rendu compte, comme de nombreux français, que le tarif HP/HC lui coûtait plus cher que le tarif de Base uniquement. En effet, l'écart de tarif entre HC et HP se réduit d'année en année, et sauf à avoir une grosse consommation la nuit (voiture, chauffe eau, etc), l'abonnement n'est plus rentable.

Merci Serait-ce juste un problème de non rafraichissement de l'heure sur l’interface Web ?

Matter Et bien, histoire de bien préparer l'abandon prochain de Zigbee, et donner un nom "Matter" un peu plus commercial à CHIP, trop geek : [Abavala] La Zigbee Alliance et le projet CHIP n’existent plus… Vive la Connectivity Standards Alliance et Matter! Alors ça, je n'y crois pas du tout, voilà un beau pipeau pour rassurer le peuple, on sait tous comment ça finit dans ces cas là, Zigbee va s'éteindre progressivement (enfin, seulement si Matter est réellement un succès) : Ah voilà ce que je voulais entendre cela confirme bien ce que j'avais compris, j'attends juste de voir ce qu'implique le processus de certification (contraintes de coût, durée, ...) : C'est parti : Plus d'infos :

Oui je confirme, les contacteurs pour ballon d'eau chaude repassent en AUTO au prochain passage en HP même s'ils sont forcés sur ON. J'avais déjà remarqué la même chose que mon vieux contacteur. En effet, c'est probablement une erreur de câblage.

I think you should look for "VariableCache"

Enadis envoie une impulsion, mais le compteur (ou son relai) la traduit en contact fermé pendant toute la durée des heures creuses, donc il faut bien maintenir le relai en position fermée (= le courant passe) pour que le contacteur fasse également passer le courant vers le ballon. Est-tu certain que ton contacteur est bien en position Auto ? Parce que s'il est sur OFF ("0" sur le schéma) alors il ne fera jamais passer le courant.

To compare a Global Variable with any value, you must use "Global+" or "Global-" : GEA.add({"Global+", "outdoor night timer", 10}, -1, "", {"TurnOff", {620, 659, 362}}) Furthermore, take care of your IDs in the TurnOff action, they must be enclosed with {}

Je n'avais jamais fait attention à l'heure en haut à droite.... je viens de regarder, elle est à l'heure. Faire un Clock Sync, oui peut être, mais n'étant pas concerné (pour le moment ?) je ne saurais pas par où commencer. Espérons que Fibaro résolve le souci

Moi non plus, mais ne te plains pas, celui de @Krikroff est limited

Bien, donc tout va bien alors. C'est le comportement de la dernière fois qui était surprenant.

Mon ballon c'est le même, mais chez le faux concurrent d'en face, Sauter (même groupe donc). Au début la batterie tenait très bien, mais mon ballon a 9 ans, et la batterie est morte. Avec 8h de recharge (durée tarif HC), elle ne tiens plus les 16h restantes. Quand j'ai vu le prix de la batterie officielle de rechange, j'ai eu une crise cardiaque. Puis j'ai repris mes esprits, et je me suis dit, tient puisque je voulais le domotiser depuis longtemps, c'est l'occasion où jamais. Donc j'ai appliqué la technique de Did, à savoir que l'électronique du ballon est alimentée H24, donc le courant imposé par l'anode est toujours présent quoi qu'il arrive. Et avec un Smart Implant qui pilote un gros relai Finder, je ne coupe que les 3 fils de phase qui alimentent la résistance chauffante. Ainsi ça laisse le thermostat faire son job de régulation de température, très important pour ne pas faire exploser le ballon. La mesure de consommation je l'ai depuis le tout début, grâce à un compteur DIN à impulsion installé dans le tableau et branché sur l'Eco-Device En bonus, le smart implant, grâce à une sonde Dallas 1-Wire glissée dans le ballon, me donne la température interne (la même qui est mesurée par l'électronique du ballon pour la régulation) J'ai eu peur le premier jour quand j'ai vu la sonde monter à 65°, mais depuis tout va bien, ça tourne comme ça depuis novembre, donc 6 mois. Et je chauffe en toute fin de nuit, ça évite de maintenir la température toute la nuit pour rien. Je chauffe moins la semaine, et je chauffe plus le week-end, pour assurer les douches plus longues, et éviter la légionellose. Comme je disais, le gain est énorme, plus de 20% pour l'instant (sur l'hiver, on verra ce que donne l'été) De quoi rentabiliser rapidement l'investissement dans le smart implant et le relai.

Bienvenue sur le forum

Cool Vérifie dans l'interface Web et dans l'Application mobile, je ne sais plus laquelle des deux, mais il y en a une qui supprime toutes les balises HTML, du coup je ne sais pas si l'espace insécable est concerné ou pas. Pour cette raison, j'évite de mettre du code HTML dans les labels des QuickApps.

Essaie l'espace forcé en HTML :   Tu peux en mettre plusieurs à la suite

Ici : https://forum.fibaro.com/topic/32655-z-wave-monitor/

Tiens, je l'avais oublié cette version. Je la ferai demain.

Premier bilan après 1 nuit. J'avais oublié que le backup auto se déclenchait cette nuit là, à 3h... donc un des QA n'a pas été relancé car personne pour cliquer sur le bouton (les autres étaient dans le onInit) Mais finalement c'est pas plus mal, ça permet de constater la différence. Les consommation de CPU sont issues des relevés de DomoCharts stockés dans la base SQL. Donc avec un intervalle de 1 minute. Et je fais une moyenne sur plusieurs heures sur des périodes pendant lesquelles je n'ai pas utilisé la box (= aucune fenêtre Web ouverte). L'objectif étant de mesurer le plus précisément possible l'impact de ces boucles refreshStates, sans perturbation extérieure. Le graph suivant représente 48h. On voit clairement mon activité d'hier soir (environ 20h à 22h), pendant laquelle j'avais plusieurs fenêtres ouvertes sur l'interface Web, des enregistrements de QA lorsque le modifie le code LUA, etc. Cela génère une charge CPU conséquente et très irrégulière. Le backup à 3h du matin est bien visible sous forme de petit pic. PS : ne faites pas attention au maximum de 24.6%, c'était il y a quelques jours lorsque j'ai fait des tests violents de performances de bouts de codes LUA (grosses boucles de 10 millions d’itérations, et cela a abouti aux optimisations des variables/fonctions locales versus globales comme évoqué dans le 1er post) Il faut savoir que mon HC3 gère très peu de modules Z-Wave, donc la majeure partie de l'activité est liée aux QuickApps (IPX800, EDRT2, GEA, Xiaomi, DomoCharts, Evénements, Eaton, Surveillance Station, Network Monitor, Kodi, HP N54L (celui là je ne l'ai pas partagé), etc). A eux seuls ils arrivent déjà à provoquer une certaine activité, qui correspond à la période n°1. La période n°2, c'était hier soir, donc avec les 4 boucles refreshStates supplémentaires (en plus de celle de GEA qui est toujours présente). La période n°3, une boucle n'a pas été redémarrée, donc on est à 3 + 1 (GEA) Voici les moyennes de CPU : Période n°1 "activité normale" : 5.36499 % Période n°2 "avec 4 refreshStates supplémentaires" : 5.80069 % Période n°3 "avec 3 refreshStates supplémentaires" : 5.65430 % Quelques soustractions et divisions plus tard, j'arrive à un impact moyen sur la charge CPU de 0.10 % par QA exploitant une boucle refreshStates avec un intervalle de 250 ms. Donc très raisonnable je trouve. Je vais quand même apporter un bémol, car comme je le disais, ma box gère très peu de modules Z-Wave. Donc même si les quelques modules modules en place et les QA génèrent un certain nombre d'événements, on est loin d'une box en prod avec 100 modules Z-Wave (relevés de température, mouvement, consommation électrique, etc). Et c'est là l'effet pervers des boucles exploitant l'API refreshStates, c'est la charge exponentielle que ça va créer. En effet, si le nombre d'événements sur une box en prod est multiplié par 10, alors ça fait des tables 10 fois plus grosses à traiter dans chaque boucle, multiplié par le nombre de QA exploitant cette API. Donc il conviendra de rester vigilant. Dans mon cas, je prévoie les utilisations suivantes : GEA : 1 boucle avec un intervalle de 100 ms Porte de garage : 1 boucle avec un intervalle de 250 ms. Ce QA sera de type RollerShutter et servira à gérer ma porte de garage, qui est équipée de 2 capteurs position haut et basse (permettant de déduire un état mi-ouvert), provenant du QA GCE IPX800. KLF-050 : 1 boucle avec un intervalle de 1 s (pas besoin de plus réactif). Ce QA sera de type RollerShutter et servira à gérer le module du même nom pour le pilotage d'un Velux en IO, avec un module FGS-222 et 2 boutons poussoirs. Donc à priori seulement 3 utilisations de l'API, avec des intervalles de rafraichissement pas trop agressifs, sauf pour GEA mais il est déjà en fonctionnement et ne pose pas de souci. Pour info, et pour ceux qui voudraient faire leur propres tests, la requête SQL sur la base de DomoCharts est toute simple : SELECT AVG(value) FROM domocharts_cpu WHERE time BETWEEN '2021-05-07 00:00:00' AND '2021-05-07 17:10:00' EDIT : graph en temps réel pendant que je rédigeais ce message, aucun pic anormal à signaler

Félicitations pour ton HC3 Lite ! Pour des événements très simples, les scènes ça fait bien le boulot Ce que je leur reproche, c'est qu'elles sont ultra limitées, on ne peut même plus leur passer de paramètres contrairement à ce qu'on faisait sur HC2. Et surtout, limité à une seule instance (contre 10 sur HC2) Donc dès qu'on veut faire des choses un peu plus évoluées, il faut se tourner vers les QuickApps (et là on se rend compte que les scènes ne servent plus à rien car les QA font tout en mieux) Mais attention, un QA c'est plus compliqué à écrire aussi, il faut comprendre la logique. Sinon, pour tes scénarios, si tu veux arriver rapidement à un résultat évolué, sans te prendre la tête à apprendre le LUA, tu peux utiliser GEA maintenant. Et j'ai envie de dire, c'est même encore plus important sur HC3L, vu que tu es limité en nombre de QA et de scènes. Puisque GEA, en 1 seul QA, te permet de réaliser un nombre illimité de scénarios.