Lazer

Après la mise à jour, le navigateur est redirigé vers la page 404, qui retourne une erreur... 404 Bug magique Il suffit de retaper l'adresse normale de votre HC3 pour retrouver l'accès.

Dommage en effet. Bon après c'est Qubino, leurs modules ne sont pas réputés pour avoir les firmwares les plus fiables qui soient. Sans compter que Qubino refuse de partager le firmware pour les modules fil pilotes... J'avais relaté mon expérience quelque part sur le forum, un stagiaire avait faillit m'envoyer la mise à jour, mais pas de chance la semaine suivante son chef était revenu et m'avait envoyé balader...

Merci pour ces tests. Mais du coup, j'ai un gros doute là, tu as déjà réussi à modifier la couleur de l'anneau ? Que ça soit en mode bloc, en modifiant le paramètre Z-Wave directement, ou par une autre méthode ? Parce que là j'ai l'impression que tu passes du temps sur GEA alors que si ça se trouve, le problème est ailleurs, au niveau du module... déjà comme tu le soulignes doublement, le nombre d'argument à 0 pour l'action setRingsLightMode, ainsi que la propriété ringLightMode qui reste toujours sur off, ça ne semble pas normal. Je te l'avais dit plus haut, il faut comprendre le fonctionnement de ton module, en LUA s'il le faut, avant de s'attaquer à GEA. Je le rappelle, GEA est juste un "Gestionnaire d'événements automatiques", un moteur de scénario, il ne fait rien de plus que de s'appuyer sur les mécanismes mis à disposition par Fibaro sur la HC3.

Oui les scènes en mode bloc sont ultra limitées. Généralement sur le forum, quand on commence à aborder la question des scénarios évolués, on conseille de regarder du côté de GEA, qui ne nécessite pas l'apprentissage du LUA

OK merci, j'analyserai ça dès que possible. En attendant tu as pu faire le test du Call avec 1 seul ID ? En fait, QA ou module physique, c'est pareil. Si tu modifies la propriété "value" d'un QA, la fonction setValue (ou turnOn, ou turnOff, etc) ne sera pas appelée, et le QA n'aura donc pas agit sur l'appareil qu'il est censé commencer (généralement un appareil sur IP) La bonne pratique pour agir sur les modules (qu'ils soient physique ou virtuel), c'est toujours de passer par les actions (listées comme telles dans le JSON du module) car cela va exécuter le code situé dans la fonction correspondante. A noter, comme je l'ai déjà dit de nombreuses fois sur le forum, toutes les fonctions membre de la classe QuickApp sont automatiquement exportées, dont on peut considérer que ce sont des actions, bien qu'elles ne soient pas nécessairement listées dans les actions du JSON. En revanche, il y a certaines propriétés qui sont juste là pour faire joli... par exemple les champs manufacturer, model, etc... si ça t'amuses, tu peux les modifier en direct, pour le coup ça ne passe pas par une fonction. Mais tout cela n'est pas lié à GEA, c'est lié au fonctionnement général de la HC3.

Bienvenue sur le forum

Si tu ne sais pas, c'est que tu n'en as pas besoin C'est ce qu'on faisait avec les fake devices par exemple, mais c'est du passé, depuis qu'on a les QuickApps, on peut coder proprement.

Un onduleur sur une ligne où tu as des modules fil pilote, et donc des radiateurs électriques ? C'est un monstre de puissance ton onduleur ? Sinon essaye peut être la valeur 1 pour ce paramètre n°30, pour voir dans quel mode il se remet après la coupure de courant.

Bienvenue sur le forum

"unsigned int" généralement. Regarde ce qu'il y a dans la doc de ton module, est-ce que les valeurs permises peuvent être négatives ou bien hexadécimal ? Dans ce cas il faudra choisir le type correspondant.

Ce module 462, c'est un parent ou un enfant ? Est-ce que tu peux essayer avec l'ID du module parent. Ensuite, tu dis que tu as systématiquement un message d'erreur, mais si tu ne dis pas lequel, tu avoueras que c'est compliqué de t'aider Profites en pour activer toutes les traces de debug. Dans la fonction config de ton fichier de config, tu ajoutes les 2 instructions suivantes : GEA.debug = true GEA.lldebug = false Et avant de lancer le test, isole la règle qui fait la modification de paramètre, car le log sera très verbeux, il ne faut conserver que l'essentiel.

Oui tu peux toujours définir manuellement les paramètres des modules Z-Wave, même si la box ne propose pas de template par défaut. D'ailleurs tu peux définir le paramètre et cocher la case "lecture seule" pour interroger le module et ainsi découvrir la valeur courante du paramètre.

Euh... Non... en fait pas sûr de bien comprendre ta demande. Mais si tu veux débugguer le fonctionnement du module, ce n'est pas GEA qu'il faut utiliser, mais le faire à la main en LUA dans une scène dédiée, pour bien comprendre la logique du fonctionnement de ces modules (vu que je n'ai ni Walli Controller, ni BSO, je n'ai aucune idée du comportement attendu) Une fois que c'est au point, même conseil qu'hier, tu pourras le retranscrire dans GEA. Normal, je n'ai expliqué hier pourquoi. Modifier les propriétés d'un module n'agit que sur sa représentation dans la DB, mais ne déclenche aucune action sur le module Z-Wave proprement dit. Et là je viens de comprendre pourquoi, en allant lire le code source. C'est une limitation de GEA, l'action Call ne peut pas prendre un tableau d'ID. Essaye avec 1 seul ID, et ça devrait fonctionner. Si c'est OK, je verrai pour modifier GEA afin qu'il prenne plusieurs ID. PS : la doc de syntaxe ne donne qu'une seul ID pour cette action Call, il n'y a pas d'exemple avec plusieurs ID... du coup la doc est correcte.

Non. Il faut chercher.... pas évident du tout. Souvent quand ça se produit, c'est un scénario qu'on a oublié dans un coin et qui continue d'agir sur les modules. J'ai eu un cas une fois (avec un Wall Plug), c'était une association fantôme qui s'était créée entre 2 modules... j'ai mis plusieurs mois à trouver l'origine du problème !!! C'était sur HC2, qui a connu des firmwares par franchement stables, j'ose espérer que ça ne se reproduira jamais sur HC3.

La résistance, par définition, est toujours compatible. Le souci se pose sur les chauffe-eau évolués, avec courant ACI, thermostat électronique, télécommande, etc... là le routeur n'est plus utilisable simplement. C'est comme pour les radiateurs cette histoire, depuis qu'ils ont des thermostats électroniques, même sur les convecteurs de base, on ne peut plus les piloter en ON/OFF avec un relai, obligé de passer par le fil pilote. Du coup la solution que j'ai appliqué, c'est de "détourner" les fils qui vont entre la carte électronique et les 3 résistances. Ainsi le routeur peut injecter en direct dans les résistance, sans risque de tuer l'électronique du thermostat, et on bénéficie toujours de la protection thermique apportée par le thermostat qui coupera le circuit lorsque l'eau arrive à température. De même, le courant d'anode imposé continue de circuler pour la protéger de la corrosion. Technique que j'avais mise en oeuvre bien avant d'avoir le routeur, pour domotiser le chauffe-eau, sur les bons conseils de @Did qui l'avait fait sur le siens. Sur le net il y a une autre solution qui est documentée, qui consiste à littéralement couper une piste de cuivre sur le PCB du chauffe-eau, je ne suis pas fan du tout....

Je suis en train de penser à un truc en lisant ton dernier message, mais encore une fois sachant que je n'ai pas ce module "Walli Controller". Il est alimenté par secteur ou par batterie ? Car si c'est sur batterie, il est endormi et ne répondra pas aux sollicitations. Autrement dit tu ne pourras pas lui demander de s'allumer/éteindre à la demande. C'est un principe de base du Z-Wave. J'avais fait un récapitulatif à ce sujet d'ailleurs : Ensuite, si ce module est bien sur secteur (attention cela se configure lors de l'inclusion du module, il faut l'exclure et le réinclure pour changer de mode d'alimentation), alors il est réveillé, participe au routage du réseau, etc. Du coup, tu peux le piloter, il faut juste que tu trouves la bonne syntaxe / commande / paramètres à envoyer. Mais attention, modifier les propriétés du module n'est pas la bonne solution. Car ça va modifier les propriétés de la représentation logique du module, c'est à dire celle qui est stockée dans la base de données de la box. Mais ça n'enverra aucune consigne au module physique (trame Z-Wave) Pour cela, il faut bien passer par les actions, donc avec GEA il faut utiliser "Call" comme je te l'ai indiqué. Reste donc à exécuter la bonne action, avec le bon paramètre. Et là dessus je ne sait pas t'aider, n'ayant pas ce module, je ne peux pas reproduire. Remarque, si tu veux mettre GEA hors de cause, tu peux tenter l'opération dans une scène en mode bloc, puis la convertir en LUA. Tu trouveras alors les bons arguments à utiliser.... normalement en LUA ça sera dans une fonction hub.call()

Pour nos 2 voitures, voici ce que je fais : - un simple chargeur de type "CRO" branché derrière un contacteur de puissance => la domotique peut démarrer/arrêter la charge. En cas de temps intermittent, afin de ne pas flinguer le relai / chargeur / batterie, j'ai mis une tempo de 5 minutes minimum. Avec GEA. - un vrai chargeur évolué OpenEVSE qui sait adapter dynamiquement la puissance de charge en fonction du surplus solaire, à 1 Ampère près, soit 240 W environ.... ça fait comme un routeur solaire. Pareil, tempo de 5 minutes intégrée (configurable). J'en ai pas mal parlé sur mon topic photovoltaïque. Je suppose qu'à terme je finirai avec 2 vrais chargeurs, car la solution de type CRO c'est quand même pas super souple, la domotique ne peut pas piloter la puissance de charge.... m'enfin ça marche en charge lente après tout, ça suffit pour la plupart des trajets Puis quand la gamine sera grande, j'imagine qu'il faudra 3 chargeurs Z'ont pas l'air cool ces 2 là Mais si tu les écoutes, alors ça va

@jluc2808 Nickel tu es au bon endroit Pour info sur les subtilités de la HC3 à connaitre : Prenons l'exemple de ton premier module Walli dont l'ID est 452 Dans ton navigateur, tu peux voir son JSON complet en utilisant cette URL : /api/devices/452 Il y a toutes les infos qui concernent le module. Parmi les paramètres importants, il y a les propriétés, qui sont toutes accessibles dans la sous-rubrique "properties". Ces propriétés peuvent généralement être modifiées depuis GEA à l'aide de différentes actions telles que "Value", "Property", etc... En fait l'action "Value" va mettre à jour uniquement la propriété "value" de ton module, alors que l'action "Property" est plus large car il permet de mettre à jour n'importe laquelle des propriétés du module (enfin presque, certaines sont en lecture seule ou bien pas franchement recommandé de les modifier) Dans tes lignes plus haut, tu essayes de mettre à jour la propriété "ringUpperColor". Est-ce qu'elle existe bien ? Car elle n'existe pas sur le Wall Dimmer à ma disposition. Si c'est bien le cas, alors tu peux effectivement utiliser "Property". Ensuite plus bas dans le JSON, tu as la rubrique "actions" : Ce sont des fonctions que tu peux appeler, le chiffre représente le nom d'argument(s) attendu(s). On retrouve les classiques turnOn et turnOff que la plupart des actionneurs disposent (single switch, dimmer, etc), mais aussi des spécifiques à tel ou tel module, comme "setRingOnColor", etc Encore une fois dans mon Walli Dimmer la fonction "setRingsLightMode" que tu essayes d'appeler n'existe pas, mais elle doit exister sur ton Walli Controller je suppose. Quoi qu'il en soit, tu ne peux pas appeler cette fonction comme tu mettrais à jour la propriété d'un module. Dans ce cas, il faudrait utiliser l'action "Call" de GEA : {"Call", {452,457,460,463}, "setRingsLightMode", "on"} Par ailleurs cette suite d'ID ce n'est pas très ergonomique pour s'y retrouver. Tu peux utiliser un tableau d'ID, dont le prototype est présent dans le fichier config donné en exemple à l'importation de GEA. Et de nombreux exemples sur le forum, voir ici ou sur le Showroom GEA.

J'allais répondre la même chose que Jojo à ta suggestion En fait si, sur le sujet du QuickApp GEA pour HC3, dont le lien t'a été donné quelques messages plus haut. Et Jojo te l'avais aussi rappelé ici même. Sans agression aucune, ces derniers jours j'ai remarqué que ça fait plusieurs fois que tu survoles les sujets sans prendre le temps de lire les messages. Du coup, tu cherches partout ailleurs, y compris Google, ce qui t'amène sur de vieilles pages obsolètes, puis tu reviens poser tes questions sur le forum. C'est dommage, ça te fait perdre du temps, ainsi qu'à ceux qui prennent de leur temps pour t'aider. Je sais bien que c'est pas évident de débuter sur une nouvelle solution domotique, tout est différent des autres solutions (Home Assistant, Jeedom, Lifedomus, etc puisque tu as pu en tester quelques unes...) Mais prendre le temps d'étudier les docs ne peut que t'aider dans ta compréhension du bousin. (enfin les docs c'est vite dit, Fibaro n'en rédige que très peu, le forum est beaucoup plus complet, trop même puisqu'il faut pas mal fouiller) Pour revenir sur ta suggestion et la réponse de Jojo, clairement, GEA c'est pas le 1er QuickApp qu'on importe normalement. C'est plus un outil pour les utilisateurs avancés, c'est à dire ceux qui veulent gérer beaucoup de scénarios et/ou des scénarios complexes. En général, on commence par importer des QA tout fait du forum, créer des scénarios simples en mode bloc ou en LUA avant de s'intéresser à GEA, qui permet d'aller plus loin et plus simplement (plus simplement car tous les scénarios sont regroupés au même endroit, ce qui évite de devoir gérer 10 ou 100 ou 1000 scènes différentes...) Bref, bruler les étapes ne t'aide pas à monter en compétence de façon progressive sur HC3, la marche à franchir est d'autant plus grande. Et finalement je me rend compte que cette remarque s'applique au sujet même de ce topic : la table de routage Z-Wave. Je suis assez surpris que tu ailles diagnostiquer ce genre de sujet alors que tu n'as toujours pas la maitrise des fonctionnalités de base de la HC3. Encore une fois, ce n'est pas une agression, mais plutôt un constat, j'espère que tu pourras reprendre ta box en main si tu souhaites l'utiliser sérieusement, ce qui semble être le cas vu le nombre de modules Z-Wave que tu as inclus.

Tu aimes quand c'est compliqué on dirait A trop chercher partout, tu as dû tomber sur de très vieux (plusieurs années) messages concernant GEA pour HC2. Comme rappelé par Jojo, tu importes le QuickApp (fichier fqa), et tu ajoutes tes règles GEA.Add() dans le fichier (onglet) Config, à la suite des 2 ou 3 règles données en exemple, comme le montre la capture d'écran. C'est tout. Pas de Scène, pas de Scénario, pas de Github, pas de Variable globale, etc... Pour la suite des questions, va sur le topic Support GEA car c'est HS ici :

ça c'est intéressant. D'une part ça explique la panne que tu as rencontré, et d'autre part ça permet de relativiser l'étanchéité de ces sondes chinoises à bon marché....

Ah oui effectivement.

Bravo, et merci pour le partage de la solution.

là ça rend bien Presque une oeuvre d'art Ton module tout seul en bas, c'est quoi ? J'ai ce genre de problème pour des Qubino Fil Pilote, dont l'inclusion se passe mal, le module n'est pas entièrement configuré. Il fonctionne très bien, mais du coup sa table de routage est foireuse et le module ne passe jamais en nœud mort, même en le débranchant. J'imagine que ça peut se produire pour d'autres types de modules qui resteraient en "non configurés" dans l'interface.

Super