Lazer

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.

Il n'est pas dans le loop() Mais bien avant !

Bon voilà, j'ai lancé 4 QuickApps avec cette boucle pour la nuit, en plus de GEA, ça me fait donc 5 QA en tout qui exploitent cette API. C'est un bon début. Ce que j'ai oublié de préciser : pourquoi je fait tout ça. Je ne suis pas très fan des solutions suivantes : - Scène avec trigger, qui appelle les fonctions d'un QA - QA qui centralise tous les refreshStates, et appelle ensuite les fonctions des autres QA Car cela rend le code plus difficile à maintenir, à cause des dépendances entre Scène et QA (mais que ce passe-t-il si je change l'ID d'un QA, le nom d'une fonction, etc....). J'ai trop galéré sur HC2 avec ce types de dépendances, auxquels on était contraints à cause des limitations des VD d'une part, et des scènes de l'autre (le coup du VD qui appelle une scène, et qui rappelle finalement un bouton de VD... l'horreur) Mon objectif, c'est d'avoir des QA autosuffisants, indépendants. Si un QA a besoin de trigger, il met en œuvre sa petite boucle, et peut vivre sa vie indépendamment des futures reconfigurations effectuées sur la box. Et surtout, ça rend les QA plus facilement partageable. Ce n'est déjà pas toujours facile de faire un tuto et d'assurer le support aux utilisateurs, mais s'il faut en plus imposer d'installer des dépendances, c'est ingérable.

Attention aux opérations sur les tables, c'est très gourmand en CPU et en RAM. Je t'invite à aller discuter de ce sujet sur ce nouveau topic :

Ceci n'est pas un tuto, mais plutôt un topic de travail sur l'avancement de mes tests dans l'utilisation de l'API refreshStates, son optimisation, son impact sur les performances de la box, ses limites, etc. Pour rappel, refreshStates permet de récupérer en temps réel tous les événements sur la box. A l'origine, elle a été créée par Fibaro pour les mises à jours de l'interface Web et des applications mobiles. Mais on peut tout à fait l'utiliser dans nos codes LUA, au sein même des QuickApps, puisque ceux-ci ne disposant pas de déclencheurs (triggers) comme les Scènes, cela leur permet ainsi de simuler ces fameux triggers. Actuellement, j'ai un seul QuickApp (GEA) qui utilise cette API, je vais commencer par créer plusieurs QA qui utilisent cette même API et voir comment réagit la box. Le risque probable, c'est une occupation CPU supérieure, pouvant entrainer des ralentissement, voire plantages. Voici un premier bout de code, optimisé "à fond", c'est à dire que pour optimiser au maximum les performances du LUA, je n'utilise que des variables locales, l'objectif étant de limiter autant que possible l'usage des variables (et fonctions) globales, ainsi que le parcours des tables (l'appel d'une variable globale revient à parcourir la table _G), opérations très consommatrices de cycles CPU. De même, le parcours de la table se fait avec for, plus rapide que ipairs(), lui même plus rapide que pairs() Le calcul du nombre d'éléments de la table se fait avant d'entrer dans la boucle for, afin de ne pas refaire le calcul à chaque passage dans la boucle for. Toutes ces optimisations LUA rendent le code moins lisible, donc je les réserve uniquement à cette boucle infinie loop(), car elle va se répéter un grand nombre de fois, à très haute fréquence. Quelques nanosecondes à chaque cycle, ça fini par faire mal mal de secondes à la fin. Le reste du code du QuickApp (non représenté ici) sera développé de façon plus traditionnelle. Pour ces tests, je commence avec un intervalle de 250 ms, soit 1/4 de seconde, ce qui me parait quasiment instantané à l'échelle humaine, et bien suffisant pour mettre à jour l'état d'un QuickApp dans nos scénarios domotiques. Sur GEA, je tourne actuellement à 100ms et ça ne pose à priori aucun problème, je sais que d'autres personnes sur le forum sont descendues à 50 ms. Mais je suppose que d'avoir plusieurs QA avec un intervalle de 50ms ça sera beaucoup plus stressant que 250ms, d'où mon choix de commencer mes tests avec 250 ms. En revanche, en cas d'erreur sur la requête HTTP, j'ai mis un timeout à 5000 ms, soit 5 secondes. Je me dit que si la requête a échoué, c'est peut être parce que la box est saturée, donc attendre plusieurs secondes ne peut que faire du bien. Évidemment j'utilise pcall() à chaque appel de fonction risquée, afin de protéger le code contre tout plantage, et tant pis pour le (léger) risque d'impact sur les performances. Je vais lancer ce bout de code sur plusieurs QA pendant plusieurs heures, et étudier comment se comporte la box (graph CPU) __TAG = "QA_REFRESHSTATES_" .. plugin.mainDeviceId function QuickApp:onInit() self:trace("") self:trace("onInit") self:trace("") end function QuickApp:buttonLoop(event) local lastRefresh = 0 local http = net.HTTPClient() local http_request = http.request local json_decode = json.decode local pcall = pcall local type = type local setTimeout = setTimeout local self_debug = self.debug -- Boucle d'attente d'événements instantanés local function loop() local status, err = pcall(function() local stat, res = http_request(http, "http://127.0.0.1:11111/api/refreshStates?last=" .. lastRefresh, { success = function(res) local status, states = pcall(function() return json_decode(res.data) end) if status then lastRefresh = states.last or 0 local events = states.events local nbEvents = #(events or {}) if nbEvents > 0 then self_debug(self, nbEvents) end for i = 1, nbEvents do local event = events[i] local id = event.data and event.data.id --if id == 123 then --self:debug("Event :", json.encode(event)) --end end else self:error(states or "json.decode() failed") end setTimeout(loop, 250) end, error = function(res) self:error("Error : API refreshStates :", res) setTimeout(loop, 5000) end, }) end) if not status then self:error(err) setTimeout(loop, 5000) end end loop() end PS : pour ce test il faut créer un bouton buttonLoop pour lancer la boucle.

Je pense quand même que plusieurs QA qui utilisent refreshStates, c'est plus consommateur de ressource qu'un seul QA avec refreshStates qui ferait des appels vers les autres QA. Je te confirme que /api/events/history est très gourmand (*), car j'ai justement mis à jour le QA Evénements la semaine dernière avec cette nouvelle API, et ma consommation CPU a fait un bond (d'environ 0.5%, ça peut paraitre peu, mais sur le graph hebdo, ça fait un palier clairement visible). Hier soir j'ai optimisé autant que possible ce QA, et j'ai gratté entre 0.1 et 0.2% de CPU. Mon graph est avec DomoCharts, donc la résolution est de 1 minute, on ne voit donc pas les pics comme sur ton graph en temps réel. Cela dit je n'aime pas du tout ce graph temps réel, car il représente à lui tout seul la moitié de ce qu'il affiche.... du coup pas facile de savoir si on regarde la consommation CPU de ses propres modules, ou bien de la page qui génère le graph. Un comble ! (*) Ce qui est gourmand avec cette API, c'est qu'on récupère une grosse table avec plein d'événements, qu'on doit ensuite parcourir... donc ça utilise pas mal de RAM et des cycles CPU. Mon QA faisait parfois des pointes à plus de 5 Mo de RAM utilisée. Après l'optimisation d'hier, je reste limitée dans la zone des 4 Mo. Bien sûr en pointe, après le garbage collection il redescend à 500 ko environ. Néanmoins le QA Evénement est mon QA le plus consommateur de RAM.

J'osais pas te parler de GEA Mais la petite différence, c'est qu'il traite tous les événements en interne, sauf exception (puisqu'il peut aussi appeler d'autres QA)

Oui tout à fait, c'était le principe lancé par @jang avec son Webhook QD Probablement plus efficace. Mias l'appel de fonction entre QA ce n'est pas neutre non plus, j'imagine que si un seul QA passe son temps à appeler en permanence des fonctions des autres QA, cela doit avoir un cout CPU non négligeable. Mais là aussi il faudrait benchmarker le comportement en charge.

OK.... oui c'est sûr que les électriciens et la domotique ça fait souvent 2 (sauf notre Did national ) Par contre est-ce que tu peux arrêter de citer systématiquement les messages précédents le tient ? C'est pénible.... Merci

Pour le câblage tu as des tonnes de schémas sur Google : https://www.google.fr/search?q=relai+domotique+chauffe-eau&sxsrf=ALeKk00mZ8It2m-Yr8eTCRnBvA89qqmosA:1620379003103&source=lnms&tbm=isch&sa=X&ved=2ahUKEwiGkoaXnrfwAhUI8BQKHa8WBF8Q_AUoAnoECAEQBA&biw=2560&bih=1308 En fait tu vas juste remplacer la sortie contact sec de ton compteur par le contact sec du module Fibaro, c'est relativement simple. Désolé pas de support en privé pour ma part. Mais si tu es si peu à l'aise avec l'électricité, peut être faut-il faire appel à un électricien ? Dans tous les cas, coupe bien le courant au disjoncteur général avant de faire l'opération.

Parce que je FGS-212 n'est plus fabriqué depuis un bon moment. Mais si tu en as un en stock, il fonctionnera tout aussi bien. Ou un FGS-211 ou encore un FGS-224

Précision : ce n'est pas EDF (ou l'un de ses concurrents) qui fourni le signal HC/HP (appelé Pulsadis), mais Enedis. Et ce signal est fourni tout le temps, quelque soit l'abonnement, puisqu'il est envoyé en CPL sur le réseau électrique. D'ailleurs, il n'y a pas que HC/HP, il y a aussi EJP ou TEMPO. En revanche, c'est le compteur, qui une fois programmé en mode BASE uniquement, ne te donneras plus les changements d'heure. Si tu installes ton propre compteur, tu as toujours la possibilité de récupérer le signal en question. Mais l'intérêt est limité, si tu as une box domotique, elle connait forcément l'heure, et peut faire les scénarios que tu veux. Je suis d'accord avec @fredokl le plus simple c'est un module relai qui va actionner ton contacteur actuel. Ainsi pas de problème de puissance. Après tu peux aller plus loin pour améliorer le pilotage, mais c'est plus compliqué. Perso j'ai un ballon avec ACI (courant imposé anti oxydation de l'anode), donc il faut qu'il reste en marche, du coup je ne coupe que la résistance (et surtout pas le thermostat), via un gros relais. C'est @Did qui avait donné l'info. Je fais ça depuis cet hiver, en ne chauffant qu'en fin de nuit, je suis à environ 20% de gain de consommation électrique, c'est énorme.

Bienvenue sur le forum