Lazer

Effectivement CustomEvent est arrivé en 7.20 Mais attends, je vais partager la 7.21, elle est prête, du coup à priori il n'y a pas de bug à corriger avec cette option

Cette valeur est mise à jour suite au boot, au backup, etc, bref tout ce qui redémarre les services Fibaro. Il suffit de le comparer au os.time() courant, si par exemple le delta est inférieur à 120 secondes, on peut raisonnablement penser que la box vient de booter, sinon c'est juste le QA qui a été redémarré. C'est comme ça que GEA procède depuis la HC2, de même que l'une de mes scènes que je m'étais fait à l'époque. @henri-allauch d'ailleurs je ne vois pas bien comment tu voudrait intercepter le boot de la box dans le refreshState depuis un QA, puisque le QA a nécessairement démarré après le boot de la box.

CTRL+F5 plutôt, le F5 n'est pas suffisant. Règle de base après une mise à jour Mais du coup, je n'avais pas fait attention, mais le bug "il y a {{time}}" a enfin disparu, à la place il n'y a ... Plus rien En fait ça ressemble à une erreur de traduction : en anglais le "ago" se met bien après la durée, mais en français le "il y a" doit venir devant. Courage Fibaro, dans 2 ou 3 firmwares vous arriverez enfin à faire un string.format() correct

@Cardane j'ai déplacé ton message ici car ça ressemble à un bug de GEA v7 pour HC3. Tu pourrais m'en dire plus sur le problème ? Logs de GEA, etc ? @Dragoniacs j'ai identifié et corrigé le bug des Profiles dans les conditions. @manulemalin et @Dragoniacs J'ai testé les multi-ID dans les commandes Open et Close, et ça fonctionne, donc là aussi si vous avez un bug, il faudra m'en dire plus (logs détaillés, etc) Pour rappel dans GEA pour obtenir un premier niveau de log, il faut mettre GEA.debug = true dans votre config. Et pour obtenir le 2nd niveau (très bavard), il faut ajouter en plus GEA.lldebug = true

Si les 2 alims sont dans le même tableau, alors l'échauffement sera le même. Et ça sera peut être même pire, car le rendement des alimentations a tendance à baisser avec les petites puissances... il faudra que tu vérifies cela dans la datasheet du modèle que tu vas choisir

Il faut aussi penser à tester le timestamp contenu dans serverStatus via /api/settings/info pour vérifier que le QA n'a pas été redémarré longtemps après le reboot de la box

Bienvenue sur le forum

problème classique avec l'infra-rouge.... tu peux ajouter un wall plug sur les équipements, et en fonction de la conso tu saurais s'il est allumé.

A la louche je dirais environ 15 minutes (hors temps de téléchargement et backup préalable)

J'ai pas chronométré, mais vu l'heure, tu devrais être l'apéro, faut pas perdre les bonnes habitudes acquises avec la HC2

si si, ça a toujours été comme ça je crois bien ça le garde en mémoire tant que tu restes sur la page des dispositifs, si tu la quitte et que tu y retournes, il faut à nouveau cliquer sur le bouton "-" pour faire réapparaitre la corbeille. C''est une bonne petite sécurité je trouve (en plus du popup de confirmation)

Donc d'après les tableaux tu es dans les clous Je suis peut être trop prudent (quoi que, on ne l'est jamais assez ) Le souci avec le micromodule dans le tableau, c'est que même si le courant va se répartir en 3 parmi les 3 fils des 3 couleurs, tu auras quand même le retour sur 1 seul fil (l'anode commune), donc obligé de dimensionner ton installation à 1.5mm² (même si je mettrais de 2.5 perso)

Je propose un truc dans le genre pour calculer le délai d'ici le lendemain à 3h (pas testé, et il y a peut être moyen d'optimiser) : local currentTime = os.time() local futureTime = os.time({ year = os.date("%Y", currentTime), month = os.date("%m", currentTime), day = os.date("%d", currentTime) + (os.date("%H", currentTIme) >= 3 and 1 or 0), hour = 3, min = 0, sec = 0, }) local diffTime = os.difftime(futureTime, currentTime) self:debug("Time is " .. os.date('%H:%M:%S', currentTime) .. ", first loop at " .. os.date("%H:%M:%S", futureTime) .. " in " .. tostring(diffTime) .. " seconds...") fibaro.setTimeout(diffTime*1000, function() self:loop() end) C'est perfectible, car si le QA redémarre entre 0 et minuit il va attendre plus de 24h (le lendemain), donc il faut ajouter un test supplémentaire dans la définition du day + 1 => test ajouté A part cela, je me pose une question, je ne sais pas comment la HC3 gère les timeouts de 24h, je me souviens que sur HC2 ça ne fonctionnait pas et qu'il fallait découper en plusieurs intervalles de taille modeste, mais bon, c'était les VD avec tous leurs défauts. A tester donc.

0.3 ce sont bien des Volts La basse tension, c'est plus compliqué qu'il n'y parait, car à cause justement de la base tension, les courants sont beaucoup plus élevés (P = U * I) Si tu n'as pas le choix, dans ce cas, il faut utiliser des grosses sections, minimum 2.5 mm² pour limiter les risques. Mais reste le problème de l'alimentation, une si forte puissance dans un tableau électrique domestique, c'est moyen. Je dis bien domestique, car en industriel tu as des tableaux en métal plus volumineux, mais tu n'as surement pas la possibilité d'en installer un. Si @Did passe par ici il nous donnera peut être un avis plus éclairé

Pour les modules sur batterie, c'est normal, il faut réveiller manuellement le module, ou bien attendre qu'il se réveille. Petit rappel :

La formule est bonne, mais j'ai pas compris ton calcul 2 lampes de 36W => 72W au total P = U x I soit I = P / U donc 72/24 = 3 Ampères Perte = 0.017 * (2*4) * 3 / 1.5 = 0,272 Volts (du coup j'arrive au même résultat que toi mais avec un raisonnement différent, est-ce un hasard ?) Presque 0.3W de chute de tension, je trouve ça beaucoup. ça fait 0.272 * 24 = 6,528 Watts de perdus en échauffement dans les câbles, c'est énorme ! Si tu veux déporter ton alimentation aussi loin, à ta place je poserai du câble de 2.5mm² Perte = 0.017 * (2*4) * 3 / 2.5 = 0,1632 Volts Soit 3,9168 Watts de perdus dans les câbles, c'est déjà mois pire (même si je trouve ça pas super quand même) Outre l'échauffement des câbles (et le risque d'incendie qui va avec), le risque d'une trop grande chute de tension c'est de ne pas pouvoir allumer les LED du tout. Une LED, ce n'est pas comme une lampe à incandescence, ça s'allume ou ça ne s'allume pas, mais ça ne va pas s'allumer un peu moins. Pour info la gradation des LED n'est pas faite par baisse de la tension, mais par hachage du signal (PWM) Pour ton alimentation au tableau, tu vas tirer 72W, donc si tu pars sur une alim de 100W et qu'elle a, admettons 85% de rendement à 72% de charge, alors ça fait 72*(100-85)/100 = 10 Watts de perdus Et là encore c'est énorme, 10W dans un tableau électrique fermé en plastique, je ne m'y risquerais pas A ta place, si tu veux assurer le coup en toute sécurité, je prendrais une alimentation de qualité Meanwell tout en métal (ils en font des super bien qui sont étanches en plus, le boitier alu joue le rôle de dissipateur passif), idéalement d'une puissance nominale d'environ 90W (afin d'être dans sa plage de fonctionnement nominale), que j'approcherais le plus possible du sauna, dans un endroit où il y a suffisamment d'espace pour le dégagement de chaleur. De plus, tu pourras surement trouver une alim dont le rendement s'approche des 90%, ça sera toujours de l'énergie perdue en moins et du dégagement calorique en moins à gérer.

Si ça peut être utile, voici la mienne : tools = tools or {} -- -- Get QuickApp variable silently without showing warning message in case variable does not exist -- -- Usage : -- local mavariable = tools.getVariable(self, "debug") -- local mavariable = tools.getVariable(1234, "debug") -- function tools.getVariable(self, variable) local id = type(self) == "userdata" and self ~= tools and self.id or type(self) == "number" and self > 0 and self if id then if type(variable) == "string" and name ~= "" then local device if type(self) == "userdata" then device = self else device = api.get('/devices/' .. tostring(id)) end if device then if type(device.properties) == "table" and type(device.properties.quickAppVariables) == "table" then for _, v in ipairs(device.properties.quickAppVariables) do if v.name == variable then return v.value end end else tools:warning("tools:getVariable() : can't get QuickApp variables") end else tools:error("tools:getVariable() : can't find device", type(self), tostring(self)) end else tools:error("tools:getVariable() : invalid variable name :", type(variable), tostring(variable)) end else tools:error("tools:getVariable() : invalid self device :", type(self), tostring(self)) end end Comme tu peux le voir, on peut l'utiliser au sein d'un QA même (avec self), sur un child, ou bien encore sur n'importe quel QA identifié par son ID

Oui, effectivement j'étais arrivé aux mêmes conclusions

Tout à fait A ce sujet je rappelle cet ancien tuto oublié :

C'est un un terme générique, tu trouveras plus généralement le terme library en anglais, improprement traduit "librairie" en français (faux-amis) En informatique on appelle librairie tout ce qui est un bout de code partageable et réutilisable par plusieurs programmes. L'exemple bien connu, ce sont les tristement célèbres DLL dans Windows (Dynamic Link Library, le truc qui manque parfois quand tu installes un programme, et il refuse de s'exécuter) Tous les OS utilisent ce principe, Linux, etc, mais ça n'a rien de standardisé, le concept de librairie est général, après chacun l'implémente comme il veux. Et ça se sont les librairies partagées, mais tu peux aussi, quand tu compiles un programme, attacher une librairie en statique afin que le programme soit totalement autonome et ne dépende pas d'une librairie externe. Le programme est ainsi plus portable, mais aussi plus lourd (espace occupé) Appliqué au LUA, quand tu utilises les fonctions dans json, net, os, etc, ce sont des librairies, qui sont fournies en standard au LUA ou bien ajoutées par Fibaro. Appliquée aux QuickApps, ma façon de faire (qui n'est pas forcément idéale, mais en tout cas je l'aime bien), c'est de considérer les fichiers à l'intérieur de chaque QA comme des librairies, qui me permettent de facilement réutiliser (par copier/coller... oui désolé LOL) des bouts de codes entiers d'un QA à un autre. Par exemple ma librarie tools que j'utilise partout (et que j'améliore au fur et à mesure), mais aussi Notifications, SNMP, etc. C'est du code qui n'est pas directement lié au QuickApp. Car le code que je met dans mes librairies effectue des opérations indépendantes, qui n'agissent pas directement sur le QuickApp. Ainsi c'est relativement portable et réutilisable dans un autre contexte. Dans l'univers Fibaro on peut citer les modules virtuels et les scènes, mais le LUA existe aussi en dehors. Et bien justement, l'autre jour pour le boulot j'avais une grosse quantité de données à traiter, j'avais le choix entre le Shell ou Excel, mais aucune des 2 solutions ne me convenait. J'ai installé rapidement LUA sous Linux (apt install lua), et j'ai copié/collé ma librairie tools car j'avais besoin de certaines fonctions dedans.

Bon bah je suis grillé, je ne serai jamais embauché chez Space X alors Quoi que... et si..... les multiples explosions à l’atterrissage... ?

On en avait déjà parlé il y a quelques mois il me semble, non ? QuickApp, c'est la classe quickApp, c'est un objet instancié à partir de la classe Je vais essayer de retrouver la discussion.... EDIT : voilà

J'ai fait la mise à jour, c'est passé du premier coup

Hum.... oui.... ça devrait être faisable, mais c'est pas mal de travail.... ça m'embête car ça va être sans fin cette discussion, on est en train de partir dans un cours de LUA là.

Tiens, je ne connaissais pas du tout ces (anciennes ?) règles de 1000 lignes max par fichier / 24 lignes par fonctions. Disons que pour moi, séparer en fichiers, me permet de structurer mon code et surtout faciliter le réemploi dans les autres QA. Je copie/colle un fichier complet sans réfléchir, c'est plus facile, je trouve, que de concaténer les multiples fonctions à la suite. Je rebondit sur ces 2 phrases qui sont liées indirectement. Si tu déclares 3 fonctions ainsi : function xxx() end local function y() end function QuickApp:zzz() end On aura : La 1ère : accessible dans tout le code (tous les fichiers du QA) sera globale, donc plus lente d'accès (LUA devrait parcourir la super table _G pour la retrouver) (ça peut devenir un critère important s'il s'agit d'une fonction appelée souvent dans une boucle, ou pire encore dans le cas d'une récursivité) La 2nde : accessible uniquement dans le fichier en cours du QA sera locale, donc très rapide d'accès La 3ème : sera globale, c'est à dire appelable avec self:zzz() depuis une fonction appartenant également à QuickApp, mais également depuis n'importe où dans le code si self a été passé en paramètre ou bien en appelant l'objet instancié quickApp:zzz() (sans la majuscule initiale donc) sera moyennement rapide si appelée depuis QuickApp (car on recherche un élément de la table self en cours d'utilisation) et sera lente en cas d'appel depuis ailleurs car on va rechercher la variable globale quickApp Donc il y a quand même quelques petites différences, qui peuvent être importantes dans certains cas. Après on peut facilement contourner le "problème" de la relative lenteur des variables/fonctions globales, en les redéclarant localement : local mafonctionlocale = quickApp.zzz