Lazer

Nice c'est comme Somfy ou Bubendorff, le meilleur conseil qu'on puisse donner, c'est d'éviter les technologies radios propriétaires. C'est compatible avec la HC3, et alors ? Dans 20 ans tu auras encore tes volets.... ton HC3 ça fera longtemps que tu l'auras remplacé. Rien ne vaut le filaire, quand on peut passer les câbles bien sûr, tu peux y installer le module, et donc le protocole de ton choix.

Ah dommage, ben c'est fini le Black Friday, fallait en profiter Déjà que ça a duré 15 jours, c'était plutôt pas mal cette année ! Avec la bêtise des commerçants français de réclamer un décalage d'une semaine, ça a durée en fait 2 fois plus longtemps que d'habitude sans en porter le nom, bien joué les gars

Chez qui eux du coup ? Parce que les meilleurs tarifs, c'est chez proshop.de, et la traduction de leur site passe parfaitement. Seule contrainte, ils ne livrent pas en France, il faut passer par un service de réexpédition. Ce qui rajoute un délai supplémentaire de 3 ou 4 jours et 15 à 20€ de frais, largement rentabilisés sur une grosse commande. Voir cet autre topic de notre serial-dealer mprinfo préféré :

Merci pour tes recherches complémentaires et ton retour Espace domotique = boutique à bannir. Pour les sites allemands, il suffit d'utiliser Chrome, il fait nativement la traduction automatique des pages dans la langue de ton choix, vraiment pratique. Et clairement, les allemands sont plus rigoureux que les français, ça se ressent dans le commerce en ligne.

Parce qu'elle était toute bugguée, ça fait 10 fois que je le dis.... Tu avais bien un problème, c'était que ça ne fonctionnais pas. Et toi tu penses que le non fonctionnement était normal.... Allez, suite sur le topic du Support GEA. Fin de la discussion avant que je ne fasse le ménage de cette page de discussion stérile.

Et bien c'est normal non ? Cette règle détecte l'appui sur les boutons : GEA.add({"SceneActivation", id["VL_BAR"] , 14}, -1, "", {{"OnOff", id["SUSPENSION_CUISINE"] }}) Mais pendant ce temps là, puisque tu as appuyé sur les boutons, la lumière le volet de ton bar s'est allumée ouvert Donc il est tout à fait normal que la seconde règle se déclenche : GEA.add({{"Value+", id["VL_BAR"], 70 }} , -1, "VLBAR OUVER 70T", {{"Global", "VL", "ok"} }) C'est une conséquence de ton action sur la lumière le volet, pas de la 1ère règle (elle ne serait pas présente, la 2nde règle s'exécuterait également) Bref, typiquement un problème de logique, ça fonctionne comme attendu. La suite de la discussion a plus sa place sur le topic Support GEA, car c'est générique et pas lié à ce QuickApp pour HC3.

Ah tu vois Mais euh... ton "SceneActivation" aussi fonctionne ?

7.02 OK, bon la détection des conditions était déjà toute bugguée. Toutes les versions avant la 7.11 de ce jour devraient être abandonnées. Ton Wall Plug, c'est donc bien un Binary Switch, tu coup tu comprends bien que jamais il ne prendra la valeur 1, donc ta condition ne sera jamais valide. Il faut utiliser true comme je te l'ai déjà dit. Bref, relis les derniers échanges, notamment ceux avec @Dragoniacs car le sujet a été traité. Un truc dans le genre (non testé) : GEA.add( {{"Value", id["DECO_AV"], true}, {"Time", "07:00", "17:00"}}, -1, "", {{"turnOff", id["DECO_AV"]}} ) GEA.add( {{"Value", id["DECO_AV"], true}, {"Time", "07:00", "17:00"}}, 30, "", {{"turnOff", id["DECO_AV"]}, {"Repeat"}} ) Pour le "SceneActivation", je vais faire quelques tests et tenter de reproduire.... à suivre

Mais c'est quoi le type de ton module DECO_AV ? Tu es certain qu'il ne prend pas les valeurs true et false ? Typiquement si c'est un binary ou sensor switch GEA 7.2 n'existe pas (encore). Et tu ne peux pas te baser sur le fonctionnement des versions betas précédentes, comme expliqué plusieurs fois, le test des conditions était buggué, c'était du rafistolage et de l'adaptation du code HC2 existant. Depuis la version 7.1, j'ai réécris la fonction qui teste les valeurs des QuickApps. Mais je le répète, et c'est lié au changement de comportement de la HC3 par rapport à la HC2 (et non pas à GEA), il faut que tu testes des valeurs qui existent dans ton module, et pas n'importe quoi au prétexte que ça marchait avant. Il faut bien comprendre que 1 et true, ce sont 2 valeurs totalement différentes qui ne peuvent jamais déclencher une condition. Pour ton dernier message, c'est laquelle des 3 lignes qui ne fonctionne pas ? Je veux bien t'aider, mais je vais te redire ce que je t'avais déjà dit au début du topic : un peu de rigueur dans ton code STP, et si tu veux qu'on t'aide, aide-nous... en commençant par donner les logs. Parce que "ça marche pas", c'est le meilleur moyen de ne pas avoir de réponse.

Certes, mais que dit le log (avec GEA.debug = true) ? EDIT : il y a de grandes chances que la condition ne soit pas remplie car c'est ton module DECO_AV qui ne prend pas la valeur value = 1 Regarde son JSON On en a parlé avec @Dragoniacs il y a quelques jours, les valeurs prises par les modules ont changé entre la HC2 et la HC3.

Je vais remettre ce que j'ai mis en premier post : " Ne semble pas encore disponible en Europe. " Donc à part être très patient, sachant que le produit n'arrivera peut être jamais en France, tu as toujours la possibilité de l'importer en direct des US, sachant que venant de ce continent, tu as de très grande chance de te prendre des frais de douane à l'arrivée.

Bienvenue sur le forum

Apparemment pas. Je ne sais même pas si c'était déjà le HC2, car je n'ai jamais utilisé ces notifications intégrées (uniquement sur les détecteurs de fumée) Pour la sonnette (et tous les autres scénarios), j'utilise GEA en pratique. Sinon faut remonter l'info à Fibaro pour qu'ils ajoutent cette possibilité, ça ne doit pas être bien difficile.

En effet, je ne sais pas comment j'ai pu passer à coté Voici le correctif dans la version 7.11 : GEA v7.11.lua

Mise à jour majeure de GEA v7.10 : Major bug fixes (ouais, rien que ça .... espérons que ça résolve une bonne fois pour toute les problèmes de détections des différentes conditions) Amélioration de la gestion des zones d'alarmes : permet de spécifier plusieurs ID de zones à armer/désarmer dans une seule commande "setArmed" ou "setDisarmed" Ajout des thermostats : "ThermostatMode", "ThermostatFanMode", "CoolingThermostatSetpoint", "HeatingThermostatSetpoint" Ajout des profils : "Profile" Ajout de labels dans le QuickApp : Running Version Intervalle Portables Debug Ajout de boutons dans le QuickApp : ON / OFF => permet de reprendre / suspendre GEA Suppression des Variables Globales (vous pouvez les supprimer manuellement). Les variables sont maintenant stockées dans le QuickApp GEA, ce qui est plus propre, et permet de faire tourner plusieurs instances de GEA simultanément et indépendamment (par exemple une instance de prod, et une autre de test) Remarque : plutôt que d'utiliser des boutons ON et OFF que je n'aime pas du tout, j'aurais pu faire un QuickApp de type Binary Switch, donc directement activable depuis l'interface Web / Mobile. Mais il est si facile de cliquer par inadvertance sur une icône, que cela aurait risqué de désactiver malencontreusement GEA, qui est un élément critique aux fonctionnement de box box car il gère tous les scénarios. Donc finalement, utiliser des boutons, peu accessibles par nature, permet de sécuriser le fonctionnement de GEA. Étant donné les modifications sur la structure du QuickApp, plutôt que de vous partager le fichier LUA, cette fois-ci je vous partage directement le fichier FQA qu'il faudra importer. Vous pouvez supprimer l'ancien QuickApp ou le réutiliser pour autre chose. GEA_v7.10.fqa

Un Sensor c'est un capteur Un Switch c'est un actionneur Pour pour remonter le statut de la sonnette, sans aucune hésitation il faut un binarysensor C'est déjà comme ça sur HC2, y'a pas de raison de faire différemment sur HC3. (j'utilise un vrai module, un Fibaro Universel FGBS)

Binarysensor tout simplement

Oui la syntaxe est la même, les nouvelles versions de GEA apportent des fonctionnalités supplémentaires, mais l'existant est toujours conservé.

/api/quickApp/availableTypes

"autant de lignes qu'il y a de type" Sachant que plusieurs types peuvent utiliser la même classe. Une autre façon de le dire : une seule classe peut gérer plusieurs types différents Exemple valide avec 2 classes différentes : self:initChildDevices({ ["com.fibaro.binarySensor"] = MyInput, ["com.fibaro.motionSensor"] = MyInput, ["com.fibaro.doorSensor"] = MyInput, ["com.fibaro.windowSensor"] = MyInput, ["com.fibaro.gateSensor"] = MyInput, ["com.fibaro.rainDetector"] = MyInput, ["com.fibaro.temperatureSensor"] = MyInput, ["com.fibaro.humiditySensor"] = MyInput, ["com.fibaro.lightSensor"] = MyInput, ["com.fibaro.multilevelSensor"] = MyInput, ["com.fibaro.powerSensor"] = MyInput, ["com.fibaro.binarySwitch"] = MyDigitalOutput, })

Oui mais non, tu confonds la création du child, et ses initialisations ultérieures relis mon message précédent, j'ai édité.

ça OK, mais faut que tu associes ta classe MyChild à tes modules enfants maintenant. Ce que tu dois faire dans onInit() Regarde le log, tu dois voir un message d'avertissement si tu as oublié de le faire. EDIT : avec self:initChildDevices() comme indiqué dans la doc, chapitre "Initializing child devices on Quick App startup" : https://manuals.fibaro.com/knowledge-base-browse/hc3-quick-apps-managing-child-devices/ C'est d'ailleurs surprenant que Fibaro nous laisse créer un Child avec une Classe donnée, puis en changer plus tard lors des redémarrage ultérieurs du QuickApp dans le onInit(). Bon l'avantage c'est que ça permet de faire évoluer son code dans détruire/recréer les children.

Je pense que tu associes la mauvaise classe à ton child lors de l'initialisation au début de la fonction onInit() du device parent.

Attention à cette version 7.05 que je me suis (trop) empressé de partager hier soir, elle corrige bien le "Time" et quelques autres conditions, mais ramène des bugs qui avaient été corrigés lors de la version précédente. Toujours la même origine, le fait que le JSON des modules à changé entre la HC2 et la HC3 : sur la HC2, les propriétés étaient de type "string", et Steven avait écrit son code en se basant sur cela. Sur HC3, les différentes propriétés peuvent prendre n'importe quel type (boolean, string, number, table). C'est plus logique, mais ça m'oblige à adapter GEA un peu plus profondément que je ne le pensais. J'ai déjà réécrit la fonction qui fait la comparaison (copy.check) et quelques bricoles autour, ça a l'air de fonctionner. En cours de test... J'en profite pour ajouter quelques petits trucs supplémentaires à venir dans la prochaine version (gestion des Thermostats notamment)

La "totale" Les relais, les entrées analogiques, les entrées numériques, etc Mais comme je n'ai pas les extensions Volets roulants, Dimmers, Fil Pilote, etc, pour l'instant elles ne seront pas supportées... mais ça sera possible de rajouter ultérieurement.