Lazer

Cela sera peut être plus clair ainsi, avec les parenthèses : local id = (type(self) == "userdata" and self ~= tools and self.id) or (type(self) == "number" and self > 0 and self) Ou bien en syntaxe traditionnelle : local id if type(self) == "userdata" and self ~= tools then id = self.id elseif type(self) == "number" and self > 0 then id = self end

Ah OK, c'est de l'optimisation de code LUA en une seule ligne avec uniquement des AND et OR, sans utiliser le lourd if .... then ... end Donc rien à avoir avec Fibaro, QuickApp, etc.... c'est du LUA pur et dur Mais cela rend le code moins compréhensible quand on n'a pas l'habitude Un peu dans l'esprit de ce qui est présenté dans ce mini benchmark (test n°5) : https://springrts.com/wiki/Lua_Performance#TEST_5:_Nil_Checks_.28.27if.27_vs._.27or.27.29

Tu pourrais regarder cette discussion, car la fonction push() que je crée sur mes enfants est utilisée aussi bien pour une mise à jour depuis l'API, que depuis le parent lui-même. Dans ton cas, ta fonction UpdateTemp() est similaire à ce que fait ma fonction push() Pour l'appeler pour chaque enfant instancié, il faut que tu parcoure ta table des enfants avec : for _, child in pairs(self.childDevices) do child:UpdateTemp(value) end

ouais mais si tu perds aussi les historiques de température et consommation lors du restore, c'est dommage. Enfin je sais pas, je n'ai pas testé

Pas besoin de me retaper les QA, puisqu'ils fonctionnent avec l'ancienne librairie tools Si par contre je souhaite reprendre le QA pour lui apporter des nouvelles possibilités, améliorations, corrections de bugs, etc, alors là c'est l'occasion de lui "installer" la nouvelle librairie. Cette ligne de code est une astuce pour récupérer l'ID du module passé en paramètre (variable self implicite correspondant au 1er paramètre lors de l'appel de la fonction) - SI type(self) == "userdata" (c'est à dire le quickapp lui-même ou l'un de ses enfants) ET que ce n'est pas tools lui-même (test inutile car en pratique tools est de type "table") ALORS on renvoie self.id - SI type(self) == "number" ET qu'il est positif (on ne sait jamais, dès fois qu'un ID négatif se perde par là), ALORS on renvoie directement le nombre lui-même (contenu dans self) Dans les commentaires je t'ai justement mis la façon de l'utiliser. Cette astuce, je l'utilise dans plusieurs de mes fonctions de cette librairie tools, c'est hyper pratique à l'usage, je peux faire ce que je veux sur un module, qu'il soit self, child, ou un ID quelconque. Tu verras tools 2.0 quand je le partagerai dans IPX800/EDRT, mais la version 1 a déjà été partagée dans des QA (Kodi, Surv Station, ...)

Ouais j'ai pas compris le truc du backup cloud là, j'ai cru qu'ils allaient faire lever la limitation, mais en fait non. Juste l'option pour pas sauvegarder les logs.... fausse joie Du coup mon script de backup local reste plus que jamais utile

Oui la cohérence est un problème, mais tant qu'on ne pourra pas travailler le design des QA, ça restera moche dans tous les cas (désolé, mais je trouve encore que les VD étaient plus jolis, même si très basiques) La Preview, je n'avais pas pensé à cela.... et Fibaro non plus apparemment

Les fichiers des QuickApp permettent de découper son code.... en plusieurs fichiers ! Exactement comme on le ferait avec n'importe quel langage de programmation, allant du C jusqu'au PHP L'idée, c'est plutôt que d'avoir un seul fichier monolithique de plusieurs milliers de lignes, on a plusieurs petits fichiers dans lesquels il est facile de retrouver la fonction recherchée. Après pour l'organisation, c'est à l'appréciation de chacun, mais perso ce que j'aime bien faire pour les QuickApp : - main : le code de QuickApp lui-même, c'est à dire toutes les fonctions qui appartiennent à la classe QuickApp, donc sont accessibles par l'utilisateur au travers de l'API fibaro.call(). On va retrouver la gestion de actions, des boutons, etc - tools : ma librairie d'outils avec pleins de fonctions utiles dans mes différents codes, et qui manquent dans le LUA natif proposé par Fibaro ("print" améliorés avec des couleurs, createChild amélioré, getVariable amélioré, createVG, Wake-on-LAN, round(), split(), base64(), log(), getView(), etc ...) - notification : pour envoyer des notifcations (Push, SMS, etc) - config : pour que l'utilisateur y stocke ses paramètres (s'ils sont trop nombreux pour tenir dans les variables du QA, comme par exemple GEA, Network Monitor, etc... et prochainement IPX800v4/EDRT2) - XXX : celui là est dépendant du QA, il contient le cœur du QA, c'est à dire toutes les fonctions spécifiques au QA. Donc ça va être SNMP pour l'onduleur Eaton, ou bien KODI pour gérer l'API Kodi, etc Dans cette liste, certains fichiers (notification, tools) vont se retrouver dans plusieurs QA différents, il me suffit de faire un copier/coller pour en bénéficier automatiquement, facile, rien à intégrer dans le code "main", c'est un fichier à part. Note : je n'utilise pas la méthode de recopie automatique des fichiers proposée par @jang, personnellement je n'aime pas ce genre d'automatisme, une nouvelle version de ma librairie tools pourrait casser la compatibilité avec l'existant et rendre inopérant toute une tripotée de QA existants. (pour des raisons un peu similaires, je n'utilise jamais, ou rarement, la dernière version des logiciels, aussi bien sur mon PC, que mon Smartphone, ou bien ma box domotique... je préfère faire les mises à jour manuellement en cliquant sur un bouton, avec un décalage, je n'ai pas envie d'avoir la primeur des nouveaux bugs qui s'installent automatiquement)

Il est en mode labo en test SOUS mon bureau depuis 1 mois... ça n'a toujours pas fumé Mais Krikroff a raison, méfiance quand même.

Bah moi... Je trouve ça pertinent Non sérieux, c'est logique que la vue par défaut propose les contrôles associées aux actions (fonction) obligatoire de chaque type de QuickApp. Par exemple pour un BinarySwitch, par défaut on a la possibilité de faire ON/OFF. Pour un Multilevel (lumière, volet), par défaut on a la possibilité de faire varier la valeur avec un slider. Il est donc tout à fait logique que Fibaro affiche automatiquement les boutons play pause stop volume etc sur un Player. Sur mon QA pour Kodi, j'avais justement ajouté manuellement les boutons manquants... dans la prochaine version je les supprimerai pour ne pas faire double emploi. Seul regret, on va perdre les jolis emojis en couleur que j'avais mis pour chaque bouton.... bon c'est pas forcément une grosse perte. Je trouve dommage qu'on ne puisse toujours pas travailler l'aspect des QuickApps en revanche @TonyC tu vas pouvoir tester le master/slave que tu attendais tant !

pas simple ? Pour un enfant c'est exactement la même méthode que pour le parent, en 1 seule ligne, je ne vois pas où est la difficulté ? Tu y mets de la mauvaise volonté là child:getVariable("mavariable") Ma fonction est un peu longue car elle effectue des vérifications, affiche des messages d'erreurs, permet d'obtenir la variable de n'importe quel module, bref elle se veut juste générique, et c'est pour cela que je l'ai incluse dans ma librairie d'outils, ainsi je peux l'utiliser dans n'importe quel QuickApp, simplement en 1 seule ligne (comme la commande Fibaro officielle) Je trouve que la méthode que tu proposes avec fichiers bien lourde, complexe à maintenir, et qui détourne totalement l'usage prévu des fichiers. Bref, c'est sale. Je ne comprend vraiment pas ce qui te déplait dans les variables de Quickapp ? C'est typiquement fait pour cet usage. 1 seule ligne de code LUA, simple, efficace, portable, pérenne. Parfois faut pas chercher la complication, juste utiliser les outils mis à notre disposition par Fibaro. Ah oui et aussi, faut arrêter de raisonner "HC2", comme tu t'en es rendu compte. On oublie les Variables Globales, il n'y a plus beaucoup de cas de figure où on a encore besoin des VG à vrai dire. Même pour gérer le statut de la maison (présent, absence, nuit, vacances, etc) on n'en a plus besoin, les profils font tout cela et bien plus (mais c'est un autre sujet)

Pour moi pas trop de risque.... j'en ai justement 1 comme ça branché en ce moment même, sans aucune lampe. Il me sert à faire des tests sur la HC3 (sur laquelle je manque de modules)

ça ressemble sacrément à ce que je vais faire pour le QA Alarm de GEA (transposition du VD) Dans un QA, on ne peut plus stocker d'information dans les Labels car l'info n'est plus persistante, donc les labels sont utilisables uniquement pour afficher l'information Donc je pense qu'il faut stocker l'information dans une variable du QuickApp (chaque Child), car elle est persistante (stockée dans son JSON). Après ce qui est pénible c'est qu'on ne puisse pas personnaliser l'IHM des QA enfants.... y ajouter des labels et boutons serait pratique. Je ne comprend pas pourquoi tu dis qu'on ne peut pas lire une variable dans un QA. Il suffit d'aller chercher.... dans le JSON du module justement ! Je me suis fait une petite fonction dans ma librairie tools, on peut obtenir la variable dans self, un child, ou bien n'importe quel QA en donnant juste son ID sous forme numérique. Cerise sur le gâteau, on n'a pas de message d'avertissement disgracieux dans la console si la variable n'existe pas. Dans ce cas, au lieu de récupérer une variable contenant "" (une chaine vide), on obtient nil, ce qui est quand même plus parlant : -- -- Get variable silently without showing warning message in case variable does not exist -- -- Usage : -- local mavariable = tools.getVariable(self, "debug") -- local mavariable = tools.getVariable(child, "debug") -- local mavariable = tools.getVariable(1234, "debug") -- function tools:getVariable(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 find any QuickApp variable") 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

clic clic clic ©

C'est beau Mais quand même.... (et puisqu'on n'est pas ici pour discuter de ton Hass ) Pour être écolo, faut quand même avoir un peu de sous.... voire d'être carrément riche (même si ce terme en veut pas dire grand chose, à partir de quand on est riche ??? vieux débat) Réduire ses émissions polluantes en consommant moins, c'est facile à dire, mais ce n'est pas dans l'air du temps, l'économie elle-même, donc le peuple, a besoin de la sacro-sainte consommation. Et puis comme tu l'as dit, personne n'a envie de se la jouer Amish. Du coup, la solution d'aujourd'hui, c'est bien de consommer mieux. Sauf qu'acheter des produits durables (et non jetables), qui consomment moins (électroménager, voiture, vélo, etc) et bien c'est un investissement conséquent, et soyons honnête, une faible tranche de la population a les moyens de se le permettre. Bon, il se trouve que les gens qui ont les moyens d'être écolos sont justement ceux qui consomment le plus (des biens polluants à la fabrication et au (non-)recyclage, des services (vacances, voyages, etc)), donc il n'est pas illogique qu'ils mettent la main au portefeuille pour faire un peu d'écologie. Mais l'imposer à ceux qui n'en ont pas les moyens, ce n'est pas très honnête. Tiens, un exemple tout simple : j'aimerais bien avoir des panneaux photovoltaïques. Mais je n'ai pas les moyens, en région parisienne, le cout de la main d’œuvre est 2 fois plus élevé, ça fait un investissement trop important, avant de rentabiliser l'installation il va se passer de très nombreuses années (et si tu ajoutes la grisaille parisienne, c'est mort). Ce n'est peut être pas un hasard si on ne voit quasiment aucun panneau sur les toits des maisons sur la région ile de France.... alors qu'on en voit plus dans le Nord !! Même remarque pour l'isolation de la maison d'ailleurs.... problème de non rentabilité.

Ah ben ça, depuis le temps que je dis que les scènes sur HC3 ne servent pas à grande chose, comparées à la puissance des QuickApps !! Le seul intérêt en fin de compte, c'est pour le néophyte, celui qui ne veut pas programmer, alors les scènes en mode bloc permettent d'exécuter des scénarios basiques : si... alors... En multipliant les scènes, il peut se faire quelques scénarios pour sa domotique. Et même sur HC2 c'était déjà un peu le cas, franchement je n'utilisais les scènes que pour 2 situations bien particulières qui n'étaient pas faisables avec les modules virtuels : - déclencheurs instantanés - connexions https Et même si je les ai utilisé au début, ça fait bien longtemps que j'avais viré toutes mes scènes blocs, trop limitées pour mon usage.

Ta règle est mal écrite, tu as 2 conditions séparées par une virgule, mais pas d'accolade autour pour les regrouper. Du coup la 2nde condition est interprétée comme le 2nd paramètre de la fonction GEA.add()..... au lieu d'avoir la durée de 30s, il ne comprend pas.

Ça j'en sait rien, faut étudier le cablage, je ne m'aventure pas à deviner.

Pour les 2 couloirs, il y avait des poussoirs, donc télérupteur au tableau, qu'il a suffit de remplacer par des modules Fibaro, terminé en 5 minutes Pour les combles, là faut trouver les boites dans la laine, identifier les câbles, ce qui prend plusieurs heures... voire journée entière. Parfois par reconnaissance de section et de couleur de câble, ou bien par mesure au multimètre, ou bien avec la méthode bourrin branché/débranché.... Une fois les câbles identifiés, c'est un jeu d'enfin de câbler sa domotique. (j'en ai profité pour déplacer des lignes électriques (radiateurs), ajouté un circuit (volet roulant), amené le neutre là où c'était nécessaire, et surtout, le plus important, descendre la terre dans toutes les prises des chambres (vieille installation de 1990, pas de terre obligatoire à l'époque). Bon comme pour le neutre, il y a une prise qui m'a résisté, je n'ai pas pu y amener la terre. Pas grave, elle est bien identifiée (pas de fiche de terre)

Aucun moyen, c'est un module sur batterie, il est endormi, tu ne peux même pas le faire clignoter. Il va falloir chercher .... dans ta mémoire

A noter qu'il faut parfois prendre le problème à l'envers, selon le câblage en place. Pour plusieurs éclairages, je n'ai pas installé le module derrière l'interrupteur, mais soit directement au tableau (lumières des couloirs), soit dans les combles (au dessus des chambres), et là on y trouve forcément le neutre. Au final, je n'ai que 3 pièces sans neutre. Sur 20 à 25 éclairages domotisés.

"Moi AUSSI je suis surtout sidéré de voir l'énergie déployée pour trouver toutes les excuses possibles pour ne.pas acheter de voiture électrique " Et le pire, c'est que tu juges sans connaitre. Essaye d'en conduire un jour, tu changeras d'avis, le confort de conduite est tellement incomparable aux thermiques Pour moi le seul problème c'est l'autonomie.... et la durée de recharge qui en découle, ce qui rend les voitures électriques inadaptés à mon usage, à mon grand regret (besoin de faire de longs trajets pour le boulot, et cela de façon imprévisible) Normalement je devrais pouvoir obtenir une hybride rechargeable pour ma prochaine voiture, c'est un juste milieu, avec l'électrique pour la ville, et le thermique pour l'autoroute.

Indispensable non Fortement recommandé oui comme expliqué, quand il n'y a pas de neutre, il y a un courant de fuite au travers de la lampe, et ça ne leur plait pas toujours (lampes qui scintillent même éteinte, variation de mauvaise qualité, etc) Le bypass est censé résoudre ces problème, mais en pratique c'est loin d'être aussi simple Il faut parfois ruser d'imagination pour amener le neutre au niveau de l'interrupteur. Avec une aiguille en nylon très fine, et beaucoup de graisse, on peut arriver à repasser dans la gaine pour tirer le fil manquant. D'ailleurs on peut ramener le neutre depuis l'un des 2 gaines : celle venant du tableau, ou celle venant de la lampe. Il faut aussi tenter le passage de l'aiguille dans les 2 sens dans chaque gaine, cela fait donc 4 possibilités en tout. Pour moi, tirer le neutre via l'une des 2 gaines est la première chose à faire. Si on n'y arrive pas, dans ce cas il faut se résoudre à utiliser le module sans neutre... en espérant ne pas avoir les problèmes décrits (la marque et le modèle des LED va alors jouer pour beaucoup)

Le QA unique, c'est l'approche que @jang a utilisé sur le forum officiel, auquel tous les autres QA peuvent souscrire : https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/page/6/?tab=comments#comment-202423 Bon après tu fais comme tu le sens

ah.....ok J'avais effectivement rien compris Bah je ne pense pas que ça soit possible, la déclaration des triggers semble être statique (comme sur HC2) et non dynamique. EDIT : je reviens sur GEA, c'est ce que permet le VD Alarme, que je n'ai pas encore porté en QA, mais c'est prévu