Lazer

La lecture n'use pas la Flash En ce qui concerne les opérations de lecture/écriture, que ça soit dans une variable globale, une variable de QA ou de scène, une propriété d'un module, etc... au final ça ne change pas grand chose, ça arrive toujours dans la même DB, donc l'usure est sensiblement identique. Reste les questions d'organisation, où stocker la donnée, chacun fait comme il veut. Cela dit, un script (QA ou scène, peu importe), qui va lire des données dans une variable (globale/QA/Scène) à chaque passage de boucle, ira chercher dans la DB, donc c'est plus lent et consommateur de CPU. Probablement sans impact dans la majorité des cas. Mais sur un système chargé, avec une boucle un peu trop agressive (par exemple chaque seconde), l'impact sur les performances deviendra sensible. A l'inverse, un tableau défini au début du code LUA, comme dans l'exemple donné plus haut sur cette page, sera infiniment plus rapide, car ce tableau, une fois chargé en RAM lors du démarrage de la scène/QA, va y rester, donc accessible par le processeur en quelques nanosecondes. Donc pour résumer, si vous souhaitez utiliser souvent une donnée, elle doit rester dans la mémoire du script LUA. Dans ce cas, le script qui exploite une variable "externe", pourra aller la lire une première fois dans la DB au moment au démarrage du script, puis la conserver dans une variable dans le code LUA. Ainsi la donnée reste en RAM, et on n'a plus de problème de performance. Si vous regardez tous mes QuickApps que j'ai partagé sur le forum, c'est ce qui se passe : les variables du QA sont chargées en RAM au démarrage (dans onInit()), puis elles y restent. Bref, la lecture n'est pas un problème d'usure de la mémoire Flash, mais de performance.

Je n'utilise que très peu les scènes, mais la réponse à ta question semble être ce paramètre : Autoriser le redémarrage de la scène en cours d'exécution: Oui/Non Donc si tu choisis "Oui", alors la scène sera redémarrée de force, donc l'instance précédente stoppée (et donc forcément l'éventuel setTimeout qui était dedans)

Il faut utiliser /api/refreshStates Il y a une discussion sur ce sujet sur le forum, sur comment le mettre en œuvre, et son impact (très modéré) sur les performances. Il se trouve que j'ai un QuickApp qui fait exactement pareil, de type rollerShutter, et qui surveille 2 contacts d'ouverture haut et bas, comme toi. Je ne l'ai pas partagé parce que je pensais être le seul dans ce cas de figure. Voici le code, il faut mettre les ID des 2 détecteurs dans l'onglet Variables du QA. Ce QA fait une double vérification de l'état de la porte (c'est critique... sécurité oblige) : boucle avec setTimeout, et détection instantané avec refreshStates : ---------------------------------------------------------------------------------------------------- -- QuickApp : Porte garage -- Author : Lazer -- Version : 1.00 -- Date : May 2021 ---------------------------------------------------------------------------------------------------- -- -- System variables -- __TAG = "QA_PORTEGARAGE_" .. plugin.mainDeviceId QuickApp.version = 1.00 QuickApp._VERSION = "1.00" local id_bas, id_haut local garbageExecTime local intervalLoop -- -- Constructor -- function QuickApp:onInit() -- Initialize self:trace("") self:trace("QuickApp Porte de garage - Initialisation") self:trace("") -- Check if QuickApp device is enabled if not api.get("/devices/"..tostring(self.id)).enabled then self:updateProperty("log", "Désactivé") self:warning("Le module", self.name, "est désactivé => QuickApp arrêté") return end -- Get QuickApp variables id_bas = tonumber(self:getVariable("ID_Bas")) id_haut = tonumber(self:getVariable("ID_Haut")) if not id_bas or not id_haut then self:error("ID haut ou bas invalide") self:updateProperty("log", "Erreur") return end local refreshInterval = tonumber(self:getVariable("Refresh")) or 60 -- Update main device properties self:updateProperty("manufacturer", "Lazer") self:updateProperty("model", "Porte garage") self:updateProperty("log", "") -- Display debug information self:debug("<font color=teal>Capteur porte basse : #<b>" .. tostring(id_bas), fibaro.getName(id_bas), "</b> =>", fibaro.getType(id_bas), "</font>") self:debug("<font color=teal>Capteur porte haute : #<b>" .. tostring(id_haut), fibaro.getName(id_haut), "</b> =>", fibaro.getType(id_haut), "</font>") self:debug("<font color=teal>Intervalle de rafraîchissement : <b>" .. tostring(refreshInterval) .. "</b> secondes", "</font>") -- Initialize internal variables local lastRefresh = 0 -- Performance optimization local http = net.HTTPClient() local http_request = http.request local json_decode = json.decode local pcall = pcall local type = type local setTimeout = setTimeout -- -- Boucle d'attente d'événements instantanés -- local function instantLoop() 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 if type(states) == "table" then lastRefresh = states.last or 0 local events = states.events local nbEvents = #(events or {}) for i = 1, nbEvents do local event = events[i] if event.type == "DevicePropertyUpdatedEvent" then local data = event.data if data and data.property == "value" then local id = data.id if id == id_bas then if data.newValue then self:trace("Porte basse", data.newValue and "ouverte" or "fermée", "=> Porte ouverte à 50 %") self:updateProperty("value", 50) else self:trace("Porte basse", data.newValue and "ouverte" or "fermée", "=> Porte ouverte à 0 %") self:updateProperty("value", 0) end elseif id == id_haut then if data.newValue then self:trace("Porte haute", data.newValue and "ouverte" or "fermée", "=> Porte ouverte à 99 %") self:updateProperty("value", 99) else self:trace("Porte haute", data.newValue and "ouverte" or "fermée", "=> Porte ouverte à 50 %") self:updateProperty("value", 50) end end end end end else self:error("Invalid states :", type(states)) end else self:error(states or "json.decode() failed") end setTimeout(instantLoop, 250) end, error = function(res) self:error("Error : API refreshStates :", res) setTimeout(instantLoop, 5000) end, }) end) if not status then self:error(err) setTimeout(instantLoop, 5000) end end -- Start both loops fibaro.setTimeout(1000, function() intervalLoop(self, refreshInterval) end) fibaro.setTimeout(1500, instantLoop) end -- -- Main loop -- intervalLoop = function(self, refreshInterval) -- Display LUA memory consumption every 5 minutes if not garbageExecTime then garbageExecTime = os.time() else local elapsedTime = os.difftime(os.time(), garbageExecTime or 0) if elapsedTime >= 300 then self:debug(string.format("<font color=gray>Total memory in use by Lua : %.2f KB</font>", collectgarbage("count"))) garbageExecTime = os.time() end end -- Check local newValue if fibaro.getValue(id_haut, "value") then newValue = 99 elseif not fibaro.getValue(id_bas, "value") then newValue = 0 else newValue = 50 end if newValue ~= self.properties.value then self:warning("Porte ouverte à", newValue, "%") self:updateProperty("value", newValue) end -- Wait if refreshInterval and refreshInterval > 0 then fibaro.setTimeout(math.floor(refreshInterval*1000), function() intervalLoop(self, refreshInterval) end) end end -- -- Actions -- function QuickApp:open() self:setValue(99) end function QuickApp:close() self:setValue(0) end function QuickApp:stop() end -- Value is type of integer (0-99) function QuickApp:setValue(value) -- TODO -- Gestion du double clic -- Appel de l'API GCE IPX800 et du FGS --self:trace("Ouverture porte à", value, "%") --self:updateProperty("value", value) end On constate tout en cas que j'ai prévu les actions open, close, et setValue, auxquelles doit pouvoir réagir un QA de type RollerShutter. Sauf que je n'ai pas encore câblé cela sur la porte de garage, donc pour l'instant c'est inactif.

Je ne pense pas que tes syntaxes de fibaro.call avec plusieurs id dans une table soient correctes. En tout cas je n'ai jamais vu ça. Tu peux soit les décomposer en autant de ligne qu'il y a d'ID... mais c'est un peu fastidieux. Ou bien faire une petite boucle : local IDs = {71, 86, 66, 76} for _, id in ipairs(IDs) do fibaro.call(id, 'setValue', 60) end Sinon il y a peut être moyen avec fibaro.callGroupAction() mais la syntaxe est un peu particulière, car elle permet de filtrer sur les modules existants : https://manuals.fibaro.com/home-center-3-lua-scenes/

Je ne sais pas... Je ne saurais pas te répondre, je n'utilise aucun scénario en mode bloc, j'utilise exclusivement GEA pour tous mes scénarios. Si tu ne connais pas GEA, c'est un script dispo sur le forum pour gérer des scénarios, du plus simple au plus complexe. Pas évident à prendre en main, mais ça permet de tout faire sans connaitre LUA, donc assez pratique au final. Mais si quelqu'un utilise le mode bloc, il saura peut être te répondre. Alors là, il faudra partager ton code, et préciser si tu le fais tourner dans un QuickApp ou une Scène, le comportement est assez différent.

Normalement, après l'inclusion, la HC3 cache automatiquement ceux qui sont inutiles. Si tu as un doute sur le module enfant à utiliser, c'est simple : tu agis avec les interrupteurs sur le module (ce qui va ouvrir/ferme le volet), et tu constates sur l'interface Web quel est l’icône qui a changé d'état => Alors tu sais que c'est ce module-là que tu dois conserver dans ton interface, et cacher tous les autres (mais encore une fois, normalement par défaut, les autres sont déjà cachés) Il y a une exception, c'est la télécommande, qui est affichée par défaut car elle permet de faire des scénarios simples en mode graphique. Perso je ne m'en sert pas, donc je cache systématiquement le module enfant de cette télécommande. Pour cacher un module, c'est simple, il y a une case à cocher dans les propriétés avancées de chaque module : Si tu ne vois pas les modules cachés, il y a une case à cocher en haut à droite (décochée par défaut) : En complément, on voit le parent et tous ses enfants dans l'onglet Général : Perso j'ai pris pour habitude de nommer le module parent avec la référence du produit, donc FGD-212 dans le cas présent. Sur cette capture d'écran, on voit bien mon module enfant principal qui contrôle la Lumière, puisqu'il s'appelle ainsi. D'ailleurs c'est le seul qui est visible dans l'interface, tous les autres sont cachés (et portent encore leur nom par défaut, je ne les ai pas renommés, pas besoin)

En Z-Wave , chaque module physique peut avoir plusieurs fonctions (endpoint). Et chaque fonction correspond à un module dans l'interface Fibaro : un parent (qui désigne le module physique), et des enfants (qui désignent les différentes fonctions) Normalement la plupart sont cachés dans l'interface car on ne s'en sert pas, de sorte à ne rendre visible que celui est est utile, c'est à dire la commande du volet roulant dans ton exemple. Tu peux renommer tes modules pour qu'ils apparaissent joliment dans le panneau d'énergie : les 53.0, 63.0, etc

Je te conseille d'attendre avant de passer en Z-Wave v3. La prochaine version, pas sûr, ça sera surement bien plus tard. Là c'est du beta, y'a plein de modules qui ne sont pas reconnus sur le nouveau moteur, il leur faudra encore plusieurs mois de travail, comme déjà précisé. La reconfiguration douce des périphériques, c'est pour ceux qui mesurent une puissance électrique, à cause du nouveau mode de calcul de l'énergie électrique de modules.

Bienvenue sur le forum

L'application mobile Fibaro a été renommée récemment et s'appelle maintenant Yubii Home Center : https://play.google.com/store/apps/details?id=com.fibaro.homecenter&amp;hl=fr&amp;gl=US https://apps.apple.com/fr/app/id1421839464 Tu peux faire tous les scénarios que tu veux, donc bien sûr, sur ouverture d'une porte/fenêtre, tu peux déclencher ce que tu veux. De là à en faire une alarme, c'est clairement déconseillé. Il ne faut pas mélanger domotique (confort) et alarme (sécurité). La domotique peut venir compléter une alarme pour ajouter des scénarios originaux renforçant la sécurité (simulation de présence, faire clignoter les lumières en cas d'intrusion, etc), mais la domotique n'est pas suffisament fiable pour jouter le rôle d'une alarme. Les risques, c'est de ne pas détecter une intrusion, ou au contraire, de détecter une intrusion alors qu'il ne se passent rien. Les détecteurs de mouvement, notamment, sons très sensibles en domotique (afin de réagir le plus vite possible dans quelqu'un entre dans la pièce, par exemple pour allumer la lumière). Trop sensibles, si bien qu'un nuage suffit parfois à détecter un mouvement. Et là, tes voisins vont te détester si ta sirène se déclenche pour rien. Et toi, tu vas passer un sale quart d'heure quand ton téléphone va te notifier d'une intrusion qui n'a en fait pas lieu. Bref, c'est un sujet qui a déjà été abordé de très nombreuses fois sur le forum, tu peux te balader et aller lire ce que tu trouves, il y a une section dédiée aux alarmes. Pour les "accessoires", qu'on appelle plus couramment modules, les box Fibaro sont en Z-Wave. C'est un des protocoles majeurs en domotique, tu trouveras de très nombreux modules de diverses marques : Fibaro bien sûr, mais aussi Aeotec, Qubino, etc. Il est possible de tout faire, ton imagination est la seule limite.

Bienvenue sur le forum

Non c'est le premier truc auquel j'ai pensé, mais fait le calcul x1024x1024, tu verras que ça ne correspond pas. La différence est peut-être due à la compression du fichier avant/après, mais ça ferait un bien faible taux de compression du coup, vu la faible différence de taille.

Non j'ai pas essayé DSM7, et je ne risque pas d'y passer de si tôt, voire jamais : - je suis sous Xpenology... donc je sais pas s'ils vont arriver à porter DSM 7 rapidement - l'API de DSM7 semble avoir beaucoup changé, je vois partout que ça casse la compatibilité avec les scripts existants - et... je ne suis jamais copain avec les nouvelles versions majeures, déformation professionnelle, je préfère attendre pour avoir du recul

Grace à toi je viens de découvrir que la HC3 affiche la taille du backup dans la page web... et c'est une nouveauté du dernier firmware. Du coup je n'avais jamais constaté cette différence, forcément, vu que ça n'existait pas avant. Si tu télécharge le fichier depuis l'interface Web, tu verras qu'il est identique à celui sauvegardé sur le NAS par le script. Donc... l'affichage de la taille de la sauvegarde sur la page Web de la HC3 est faux... voilà voilà... Bon ça donne quand même un ordre d'idée, c'est pas si mal.

Sans certitude, mais essaye peut-être avec un autre navigateur.

Je ne sais pas si le support te donnera satisfaction, ils répondent souvent à coté de la plaque, des réponses génériques, etc. Tu devrais profiter que l'équipe de dev est active sur le forum en moment pour décrire ton problème directement là bas : https://forum.fibaro.com/forum/1279-update-5080/

@juch11111 J'ai regardé ton fichier de log, le comportement de ton aspirateur est très étrange, il ne répond pas comme attendu. Rassures moi, tu n'as pas mis à jour que le fichier main, tu as aussi mis à jour le fichier Xiaomi en version 1.01 ? Parce que j'ai pas franchement l'impression.... Si oui, alors dans le fichier main, est-ce que peux essayer de commenter le paragraphe suivant entre les lignes 258 et 265, en ajoutant des balises de commentaires comme suit : --[[ Xiaomi:getFeatures({ success = function(result) tools:print("gray", "Vacuum features :", tools:tostring(result, true, true)) end, error = function(response) tools:error(response.message) end, }) --]] Puis tu relances le test, et tu captures les logs.

Ah dommage

Euh, dès fois que le journal des nouveautés ne soit pas clair : Le nouveau moteur Z-Wave v3 n'est pas une mise à jour. Le nouveau moteur Z-Wave v3 n'est accessible qu'après une réinitialisation complète de la box, et après avoir spécifiquement choisi le moteur Z-Wave v3 lors de l'assistant de démarrage (sachant que le moteur v2 reste celui sélectionné par défaut) Quoi qu'il en soit, même pour ceux qui font le choix de faire une nouvelle installation avec ce nouveau moteur Z-Wave v3, cela reste une première version qui n'est pas exempte de bugs... à réserver aux plateformes de tests, et éviter la production. Pour les systèmes existants, la migration du moteur v2 vers le moteur v3 sera proposé ultérieurement par Fibaro.... d'ici l'automne environ (plus ou moins un certain retard) Bref, vous pouvez faire cette mise à jour 5.080.9 sans crainte (mais on n'est jamais à l'abri d'un bug quelconque).

C'est beau quand même Node RED. Mais je me vois pas gérer 200 règles en mode graphique.... je suis surement déformé (mode Unixien), mais je trouve tellement plus facile de gérer 200 règles GEA en mode texte dans mon éditeur favori...

Oui le Swagger, très pratique ça y est, la tempête de goutes d'eau est arrivée, la HC3 est donc en avance sur son temps

Si ça freeze, tu as tout autant de chance que l'API freeze également, comme le QA. Donc ça ne changera rien. Et que ça freeze n'est pas un souci, puisque tu mesures le delta justement. L’intervalle de temps sera allongé, et c'est tout. Mais tu mesureras bien la surconsommation CPU liée au freeze. Reste le bon point de l'application externe qui passe par l'API : détecter et noter l'heure du freeze. Sinon tu sais qu'en 10 minutes tu pourrais mettre en place DomoCharts sur un NAS et avoir la courbe CPU

En monitoring système, ça n'a pas de sens de regarder à un instant T, parce qu'une ça dure une microseconde, donc tu rates ce qui se passe pendant les 99,99999999999% du temps restant qu'il s'est écoulé depuis la dernière fois que tu as regardé. Ce que tu donnes l'API, ce sont les métriques systèmes au niveau de l'OS (noyau Linux). Pour simplifier, il compte le temps passé dans chaque "tâche" Sachant que idle est un cas particulier, c'est le temps passé à ne rien faire Et il faut soustraire la valeur précédente afin de calcul le delta CPU consommé De cette façon, tu ne "rates" pas ce qui s'est passé entre 2 périodes de monitoring. Enfin, c'est vite dit, parce que si tu regardes 1 fois toutes les 10 secondes, mais que le CPU a bossé 1s à 100% et le reste à 0, toi tu auras l'impression qu'il a bossé à 10% en moyenne pendant les 10s. Mais au moins, tu auras vu ces 10%, c'est toujours mieux que 0. Au fait, attention, le calcul est à faire pour tous les cœurs du CPU de la box (4 sur HC3, 2 sur HC3L), il faut donc faire une petite boucle. Regarde le code de mon QA DomoCharts, dont voici un extrait : local diagnostics = api.get("/diagnostics") local nbCPUs = #diagnostics.cpuLoad if not self.cpuLoad then self.cpuLoad = {} end local cpuAverage = 0 -- Parse cores for i = 1, nbCPUs do local cpuNew = diagnostics.cpuLoad[i] local cpuName = cpuNew.name local cpuOld = self.cpuLoad[cpuName] if cpuOld then local cpuTotalOld = (cpuOld.user + cpuOld.nice + cpuOld.system + cpuOld.idle) local cpuTotalNew = (cpuNew.user + cpuNew.nice + cpuNew.system + cpuNew.idle) local cpuPercentage = tools:round(((cpuTotalNew - cpuTotalOld) - (cpuNew.idle - cpuOld.idle)) / (cpuTotalNew - cpuTotalOld) * 100, 2) cpuAverage = cpuAverage + cpuPercentage print("Core #" .. i .. " " .. cpuName .. " = " .. cpuPercentage .. "%") end -- Memorize values self.cpuLoad[cpuName] = { user = cpuNew.user, nice = cpuNew.nice, system = cpuNew.system, idle = cpuNew.idle, } end print("Usage CPU moyen sur la période : " .. (cpuAverage / nbCPUs))

Cool Les 2 raisons... je pense que la syntaxe abrégée devait fonctionner il y a bien longtemps, et qu'elle a dû cesser de fonctionner à un moment donné dans mes différentes modifications pour HC3. J'ai regardé dans les règles que j'ai testé, je n'ai jamais testé cette syntaxe abrégée, uniquement la version longue avec WeatherCondition explicitement déclaré. Je regarderai si je peux patcher GEA pour rétablir le fonctionnement raccourci de cette règle, comme avant. Et mettre la doc à jour aussi du coup. Au fait, pour voir la condition actuelle de la météo, il faut passer par l'API de la box : /api/weather On y voit clairement toutes les propriétés exploitables avec "Weather" : (pour la précision, on repassera, il fait soleil en ce moment.... mais bon c'est du Cloud (sans jeu de mot), donc pas précis, peut être qu'il pleut effectivement de l'autre coté de Paris.

J'ai fait le déplacement (il y avait aussi les messages de Dragoniacs du coup) Tu peux essayer avec la syntaxe suivante (avec "WeatherCondition") : {"Weather", "WeatherCondition", "xxx"} Ce qui devrait donner un truc du genre (tu es sûr pour la valeur "dégagé" ?) GEA.add({id["OEIL_SAURON_CUISINE"], {"(Weather)", "WeatherCondition", "dégagé"}, {"(Time)","06:00","22:00"}}, -1, "", {"Color", 153, 255, 206, 51, 0}) Je soupçonne la syntaxe abrégée d'être buggée dans cette version de GEA (et vu que je ne l'ai jamais utilisé, ça fait peut être longtemps)