Lazer

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

Ah ok, je n'avais pas compris que tu voulais déclencher sur 2 conditions. ..... mais .... dans ce cas pourquoi ne pas utiliser GEA ? Tu as envie de réinventer la roue ?

"fibaro.getGlobalVaraible()" dans un trigger, surement pas, y'a aucune chance. Mais on doit pouvoir y mettre "global-variable" d'après ce que je vois. Après je n'ai pas testé, mais c'est possible, forcément. Je récupère le trigger des variables globales via l'API RefreshStates dans GEA, donc ça déclenche bien un événement. Faut juste que tu trouves la bonne syntaxe.

Comme Dragoniacs, pour moi il faut que tu structures ton code avec des fonctions qui vont s'appeler les unes et les autres. Alors il sera facile avec setTimeout() de relancer une fonction quelques secondes ou minutes plus tard. Pour les déclencheurs de scènes, c'est bien documenté : https://manuals.fibaro.com/home-center-3-lua-scenes/ Mais je n'ai pas encore testé, je n'ai que des QuickApps, et GEA est mon moteur de scénarios pour l'instant.

voilà tu as ta réponse, il faut le neutre pour alimenter le transfo en ON/OFF Sans neutre, ce n'est pas du ON/OFF, car le courant, au lieu de repartir par le neutre, part par la charge... qui est donc toujours alimentée.

Les transfo c'est rarement dimmable, et quand ça l'est, la variation est souvent de piètre qualité.... bon courage pour en trouver un qui fonctionne bien ! Le tiens, comme tu l'as dit, n'est clairement pas dimmable. En l'état, la seule chose que tu puisses faire, c'est de la piloter en ON/OFF sans variation. Concernant les lampes en 230V, si tu veux maximiser tes chances, c'est toujours la même histoire : - utilisation du FGD-212 (et pas le FGD-211) - présence du neutre pour alimenter le module - installation d'un bypass en parallèle avec la charge - utilisation d'ampoules dimmables (évidemment) - utilisation d'ampoules marque reconnue. Même si ça ne garantie rien, ça maximise les chances, l'électronique d'une ampoule de qualité n'a rien à avoir avec l'électronique d'une ampoule low-cost. Et même concernant les grandes marques, si tu prends Osram (l'une des références), ils ont une gamme grand public et une gamme pro. Inutile de te dire que la gamme pro ne présente que des avantages (lumière blanche de meilleure qualité, meilleur rendu des couleurs, meilleure gestion de la variation, meilleure durée de vie, etc), et un seul inconvénient : le prix Et même quand toutes ces conditions sont réunies, que l'alignement des planètes est parfaite, tu n'auras jamais une aussi bonne qualité de variation que ce qu'on avait avec les bonnes vieilles ampoules à incandescence et halogènes. Quelle tristesse de les avoir interdites....

lol merci il faut 2 "t", @MAM78 tu aurais dû copier/coller l'URL que je t'ai donné Mais donc tu n'as pas testé l'URL dans ton navigateur avant de le faire en LUA ?

Bienvenue sur le forum

Bah oui, tu as ajouté networkConfig en trop, ça ne fait pas partie de l'URL Si tu veux récupérer directement la valeur il faut le faire ainsi : local networkConfig = api.get("/setings/network").networkConfig

Pas un bug, c'est voulu à mon avis.... en phase avec la volonté de Fibaro de couper les accès directs aux box, pour des raisons de sécurité, trop de gens ont simplement ouvert et redirigé un port sur leur routeur directement vers la box domotique, sans aucune sécurité. Ce qui est malheureux, c'est que ça nous oblige à passer par leur cloud, ce qui est inacceptable. J'ai aussi changé de téléphone récemment, et j'en pouvais plus de la connexion en remote via leurs serveurs, beaucoup trop lent. L'astuce donnée par @ADN182 fonctionne bien, perso j'ai pris l'avant dernière version, la 1.26.0.0 On la trouve sur apkpure : https://apkpure.com/fr/fibaro/com.fibaro/versions Ou mieux, directement sur le site de Fibaro (tant qu'ils ne la retirent pas) : http://android.fibaro.com/ Procédure en moins de 5 minutes : - désinstaller la dernière version (1.27.0.0 aujourd'hui, mais je pense que ça restera la dernière car Fibaro a arrêté son support) - télécharger la version 1.26.0.0 - installer la version 1.26.0.0 (il faudra autoriser les sources inconnues si ce n'est pas déjà fait) - lancer l'application, accorder les droits d'accès demandés, se connecter via le Fibaro ID, puis entrer le nom d'utilisateur et le mot de passe de la box (éviter de se connecter avec le compte admin) - ensuite aller dans les paramètres : Settings => Choose HC => Edit => Entrer le nom de domaine complet dans le champ HC IP => Save - quitter l'application - aller sur le Play Store - installer la mise à jour proposée (pour revenir en version 1.27.0.0) - couper son Wi-Fi, relancer l'application, et vérifier qu'elle se connecte bien en "local" via la 3G/4G/5G. Voilà, ça fonctionne, ne surtout pas toucher aux paramètres de connexion réseau, il va conserver le FQDN tant qu'on n'y touche pas. Malheureusement cette astuce est impossible sur la nouvelle application (compatible avec la HC2, et obligatoire pour la HC3), son fonctionnement est totalement différent et il est impossible de bypasser le Cloud. EDIT : package en pièce jointe : Fibaro-1.26.0.0.apk

Bienvenue sur le forum