Lazer

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

je vais me confiner pour la peine Attendons la version de @Barelle alors qui sera peut être plus compréhensible

Sa phrase était ambiguë. Explication : Dans ce dernier cas fonction est locale au quickapp (le QA en tant que module, donc pas accessible depuis les autres QA via l'API fibaro.call()) sans appartenir à la classe QuickApp (la classe QuickApp en LUA) En fait, toutes les fonctions déclarées dans QuickApp (y compris onInit() du coup) sont automatiquement exportées, donc exécutables depuis n'importe où via l'API. Il y a les fonctions que l'on crée, et les fonctions prédéfinies (le fameux self:debug(), ce n'est que la fonction debug prédéfinie (qui est en fait héritée de la classe parent, mais peu importe)... qu'on peut s'amuser à redéfinir si on veut ! ) Est-ce plus clair ainsi ?

Le Broadlink, si tu arrives à t'interfacer avec, tu auras du succès, car c'est un produit populaire qui va attirer du monde (quand on voit son succès sur Jeedom Hass & co)

@Barelle juste histoire de polémiquer un peu  : Dans ce dernier cas fonction est locale au fichier du quickapp... Et encore, c'est vrai si tu déclares la fonction avec local function(...) Sinon elle sera globale (c'est à dire accessible depuis tous les fichiers du QA) Mais dans tous les cas on est bien d'accord qu'elle ne sera pas exposée aux autres QuickApp par le biais de fibaro.call() Je crois qu'on va noyer tout le monde

N'hésite pas à poser des questions, et expérimenter par toi même. Il est aussi très instructif de créer volontairement des erreurs dans le code pour voir comment ça réagit. @Barelle Oui tu as raison pour le premier point, on peut aussi passer l’intervalle en argument de la fonction loop() Quant aux fonctions locales c'est vrai aussi car cela évite d'exposer les fonctions aux appels externes, cela dit ça complexifie significativement le code LUA. En effet, plus question d'utiliser self, ou alors il faut le passer en argument, ou bien encore appeler directement l'objet quickApp (sans la majuscule... QuickApp est la classe, quickApp est l'objet instancié à partir de la classe) Mais tout cela est beaucoup trop compliqué pour le néophyte, je pense que ce sont des notions réservées aux développeurs un minimum expérimentés. En tout cas c'est l'une des raisons pour lesquelles j'utilise beaucoup les fichiers des QA, j'y range ce que j'appelle des librairies, qui permettent d'une part de "cacher" les fonctions qui ne sont plus exposées dans le QuickApp, mais également de mieux structurer le code, de facilité de réemploi dans d'autres QuickApp (à la façon programmation objet), et de faciliter les migrations futures. Si le QuickApp disparait ou est remplacé à nouveau par autre chose, seule la partie interface IHM sera à réécrire, tout le reste sera repris tel quel. C'est le principe que j'avais commencé à adopter dans mes derniers développements sur HC2, si bien que j'ai migré mon QA Onduleur Eaton en un temps record, bien qu'il soit le plus complexe de tous ceux que j'ai réalisé : ma librairie SNMP a été migrée quasiment telle quelle, à quelques détails près.

La cacher oui. La désactiver non je ne pense pas, car je crois que ça va désactiver tout le module Z-wave, donc également "thermostat" (entre guillemets car c'est un faux thermostat) Et justement, le truc, comme je le disais, c'est un thermostat au sens Z-Wave => Il accepte une consigne de température Mais ce n'est pas un thermostat au sens de la régulation du chauffage => il ne fait que transmettre cette consigne au thermostat intégré à la climatisation, et c'est elle qui a son propre thermostat intégré de régulation de température. Et oui pour la télécommande, tu as compris, car tu as besoin de sa sonde de température intégrée. MAIS : il ne faut plus l'utiliser, car si tu donnes un ordre à la clim à partir de la télécommande, alors ta domotique ne sera pas au courant, et ne pourra pas prendre les bonnes décisions. Dans mon cas, avec ma clim bas de gamme, ou disons juste ordinaire, la télécommande possède un écran LCD, mais la seule température affichée est la consigne. Ce n'est pas une sonde (la sonde est dans le split mural) Donc j'ai enlevé la pile, je l'ai rangé, et je n'utilise que la domotique pour piloter la clim (c'est tout automatique grâce au module virtuel que j'ai rapidement décrit précédemment, le tout géré par GEA en fonction des heures, présence, etc)