Lazer

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

Oui tu as surement raison.

Merci, je ferai la mise à jour fin mai quand j’exclurai le module pour le ré-inclure sur ma box de prod.

Théoriquement tu pourrais avoir plusieurs QA qui exploitent l'api refreshStates. Je ne sais pas quel serait l'impact sur la charge système, je manque encore de recul.

Euh, j'ai demandé le firmware, pas le prix

Encore une traduction mal.... traduite ! C'est une relation parent/enfant. Et c'est tout à fait normal.... enfin, aussi normal que peut l'être la logique Fibaro. Il n'y a rien à casser. La parent, c'est le module Z-Wave proprement dit. Les enfants, ce sont les "endpoints", disons les fonctions que ce module sait gérer. Si tu n'en n'as pas besoin, tu caches le modules correspondant dans l'interface, tout simplement.

Tu pourrais partager le firmware ? Je ne vois rien sur leur site, pourtant Aeotec partage toujours ses firmwares, c'est même le seul bon élève dans la classe Z-Wave.

Oui, je comprends, en fait tu cherchais une logique similaire à /api/redreshStates Les 2 ont un comportement inversé : /api/events/history permet de remonter dans le passé /api/redreshStates permet de suivre les nouveaux événements au fil de l'eau Du coup, n'est-ce pas refreshStates que tu aurais dû utiliser pour ton application ? Même si tu as trouvé une solution de contournement avec les timestamps from, cela me parait moins précis, car tu peux avoir plusieurs événements au même timestamp (pendant une seconde, c'est long).

Bienvenue sur le forum

Effectivement, la doc du swagger semble erronée, mais le comportement en revanche est logique. Avec numberOfRecords tu récupères les N derniers événements par rapport au moment spécifié (avec lastId). Si lastId n'est pas spécifié, alors c'est le tout dernier. L'idée, est de coller au fonctionnement du panneau d'événement de la HC3. D'abord, on affiche les N derniers événements (afin de remplir la page) Si l'utilisateur scrolle la page, alors on cherche les N événements précédent le dernier ID connu. Etc... cela permet de scroller indéfiniment, et de remonter dans l'historique.

En tout cas 43% pour le used, c'est tout à fait normal, j'ai la même valeur sur mon HC3. J'insiste, je le répète partout sur le forum, il ne faut prendre en compte que le used (= espace utilisé), et ignorer le cache et le buffer.

Ouais c'est ça la magie de GEA Extrait de la doc de syntaxe rédigée par @pepite : Je souhaite que la lumière s'allume au levé du soleil mais pas avant 7h30 : Utiliser le paramètre Sunrise>07:30 ou Sunrise<07:30. GEA.add({"Time", "Sunrise>07:30", "07:35"}, 60, "Allumage lumière", {"TurnOn", 18})

C'est quand même assez aléatoire....

Euh, si, on peut utiliser Sunrize avec >, pourquoi tu dis ça ? Je l'utilise dans mon GEA v6 sur HC2 Pour moi cette condition devrait être valide : {"Time", "Sunrise>08:40", "09:00"}