Lazer

Bienvenue sur le forum

debug => affichage de messages basiques, pour aider l'utilisateur à comprendre le fonctionnement (ou non) de ses propres règles lldebug (pour Low-Level) => affichage de messages supplémentaires pour aider les développeurs (= moi et quiconque voudrait bien se joindre à l'aventure) à comprendre les bugs dans GEA

cette histoire d'ordre des règles ressemble à un effet de bord dans la logique de gestion des statut des devices, mais je n'arrive pas à comprendre. Quelques remarques cependant : - je vois dans ton log que GEA est suspendu, c'est normal ça ? Parce que s'il est suspendu, il ne va pas gérer les règles correctement. - tu as mal dû positionner le GEA.lldebug = true, car il doit être dans la fonction config()

Oui pourquoi, tu as des soucis ? Si tu as des problèmes, il s'agit plus probablement d'incompatibilité avec le modèle de robot.

Welcome to the forum

La syntaxe semble correcte. Tu peux activer le mode GEA.lldebug = true et relancer, et surtout regarder les logs que tu as pour cette ligne, puis 10 secondes plus tard.

Il n'y a pas de raison, tout ce qui peut être fait en LUA peut également être fait par HTTP, pour la simple et bonne raison que tout passe par l'API. Pour les scènes, voir le Swagger : /api/scenes/ID/execute Cependant, sur HC3, il y a une limitation par rapport à la HC2, puisque les scènes ne peuvent plus recevoir de paramètres.

Oui ça m'a l'air bon.

Il faut que tu entoures les 2 actions par des accolades.

Effectivement, sur la VF aussi j'ai Integration pour le module GEA, c'est la 1ère fois que je vois ça, ils ont dû changer l'affichage lors d'une mise à jour intermédiaire, pourtant c'est bien le type com.fibaro.deviceController Je trouve que ce n'est pas parlant du tout, mais bon, la logique polonaise est parfois très différente ("Notation polonaise inverse" pour ceux qui connaissent, souvenirs de calculatrice HP...) En fait les fichiers FQA contiennent le JSON du QuickApp.

Tu as édité entre temps, mais je répond quand même à la question. Tous les types de QA ne sont pas dispos lors de la création d'un QA via l'interface Web. L'astuce consiste à créer un QA de type bidon (par exemple generic), de l'exporter, modifier le fichier fqa avec un éditeur de texte sur ton PC afin de changer la valeur du champs type, puis de le réimporter. Il aura alors le bon type. Et tu peux supprimer l'ancien que tu as utilisé temporairement avant l'extraction (ou l'utiliser pour autre chose) Bon pour toi le type rollerShutter existe bien de base donc l'astuce n'a pas lieu d'être : Je ne connais pas le type 'Integration', je ne vois pas de quoi tu veux parler.

Welcome to the forum

Rien de surprenant en fait, il a été confirmé que l'intervalle de réveil n'aurait aucun impact sur la lecture de la sonde, cf discussion ci-dessus. Tu dois avoir un paramètre dans le module qui permet de configurer l'intervalle d'envoi des mesures de températures. Je n'ai pas ces têtes thermostatiques donc je ne fais que supposer, mais en tout cas ça fonctionne ainsi pour tous les modules (Motion Sensor, etc...) EDIT : tu parles de mise à jour le 20 avril, mais de quoi ? Du module, de la box ? C'est une piste en tout cas.

Bienvenue sur le forum

Tu devrais poser ta question dans la section appropriée (éclairage) Mais perso je déteste les montages complexes (va et viens, permutateur, etc), c'est ingérable. Dès que j'ai au moins 2 points de contrôles, je fais un montage de type télérupteur. Simple et efficace.

L'ajout de boutons, sliders, labels etc sur un child device n'est officiellement pas supporté. On peut y arriver via un hack, mais c'est pas simple (surtout si tu n'es pas à l'aise en LUA avec l'API de Fibaro), et surtout aucune garantie que ça fonctionne éternellement. Bref, je ne te le conseille pas. Pour gérer les volets, le plus simple est de créer un QA du bon type, à savoir un rollerShutter, qui présentera d'office les boutons haut/bas nécessaires, ensuite tu as juste à coder le contenu des fonctions open et close. Le plus simple est de créer un QA tout simple du bon type via l'interface Web et de s'inspirer du code généré automatiquement par Fibaro.

Jarvis déjà entendu parler, Snowboy en revanche pas du tout. Mais je ne suis pas le bon interlocuteur pour le choix d'assistant vocal, car je n'aime tout simplement pas parler à la machine. Et cela indépendamment des problématique de vie privée, de toute façon Google possède déjà toute ma vie numérique, et ce depuis plus de 10 ans. Pour mon plus grand bénéfice, c'est un contrat gagnant/gagnant (jusqu'à présent en tout cas)

C'est bien dans dans la section Petites Annonces qu'il faut poser ton annonce.

Bienvenue sur le forum Sacrée présentation détaillée L'application Fibaro n'est plus maintenue depuis pas mal de temps, et n'a jamais été compatible avec la HC3. Elle date de la HC2. L'application Yubii fonctionne bien, malgré ses défauts ergonomiques agaçants. Étrange le comportement que tu as observé... Après le contrôle vocal en local, bon courage, il me semble que tout passe par le cloud de nos jours (et c'est bien dommage). Cela dit, un des objectifs principaux de la domotique c'est d'automatiser, si tu dois systématiquement parler à ta montre pour toutes les actions, je ne trouve pas que cette solution aille de pair avec ta fainéantise croissante

+1 Sujet abordé dans le mini tuto que tu avais déjà mis dans tes favoris @jojo, dans ta précédente vie où tu étais sur HC2

Toi tu as trop trainé sur le forum Jeedom, ou plus généralement toutes les solutions domotiques qui utilisent le librairie OpenZwave, aussi appelée librairie la plus merdique de toute l'histoire de la domotique Ne t'inquiète pas, le module fonctionne super bien, est parfaitement reconnu par toutes les box Fibaro, et tu pourras faire la mise à jour du firmware si celui-ci n'est pas déjà à jour lors de la livraison. Non, que les lumières et certains capteurs pour l'instant.

Tu sembles bien sûr de toi, mais si tu comptes sur Fibaro, es-ce bien sûr ? C'est pas sûr cette affaire...

Non, la migration "formate" la box cible. (et elle formate également l'ancienne box) C'est assez violent comme processus en fait. Par contre attention à la migration au fil de l'eau... gérer 2 réseau Z-Wave, ça fonctionne. Mais si chaque réseau n'a pas suffisamment de modules, le maillage ne sera pas bon, et les problèmes de transmissions nombreux. Idéalement il faut exclure/inclure les modules assez rapidement, perso je l'ai fait en 4 jours je crois (sans me presser, ça aurait été faisable en 1 ou 2 grosses journées) Cela dit je t'invite à te faire la main sur la HC3 avec quelques modules Z-Waves et QuickApp pendant un certain temps avant d'envisager la bascule définitive. On reste dans l'esprit Fibaro, mais il y a quand même pas mal de différences avec la HC2.

J'aime bien "It is a problem with watchdog" Donc en gros, le watchdog détectait une erreur qui n'existait pas, donc il rebootait la box et mettait un message d'avertissement, juste pour faire flipper les gens

S'agissant d'un QA de gestion des modes de chauffage, donc que tu vas changer... quoi... 4 fois dans l'année... tu te prends la tête pour rien à vouloir cliquer directement sur l'icone. Un QA générique, tu ouvres sa vue, et tu cliques sur l'un des 4 boutons, me semble de loin le plus simple. Et tu pourras gérer l’icône simplement sans hack tordu en essayant de contourner le mécanisme du binaryswitch. Autre possibilité, utiliser le nouveau type QA MultiPosition. Mais ça ne résoudra pas ton problème d’icône, car le QA multiposition peut avoir plusieurs valeurs, mais seulement 2 icônes, exactement comme un Binary switch, et ça c'est très bête (raison pour laquelle je ne l'utilise pas sur mes fils pilotes, je préfère le multilevel switch qui permet 10 icônes)