Lazer

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)

Pour un binary switch tu n'as pas besoin de connaitre l'ID de l'icone, car tu n'as pas besoin de changer toi même l'icone. C'est lorsque tu changeras la propriété "value" du module (true/false), que l'icone changera automatiquement.

Les variables globales sont visibles de partout dans le même QA. Elles ne sont pas visibles depuis les autres QA. Que les variables soient globales ou locales, elles ne sont connues que dans la mémoire du processus qui exécute le QuickApp. Dans dans la HC3, chaque QA est un processus système (au niveau de Linux) Elles ne sont donc par persistantes, et perdus à chaque redémarrage du QA (sauvegarde, reboot de la box, etc) Ce qui est visible depuis les autres QA (et de façon générale depuis le monde entier via l'API), c'est : - les fonctions exportées (donc membres de QuickApp) - les propriétés du QuickApp (accessibles dans son JSON via /api/devices/ID).... donc la "value", mais aussi tout plein d'autres propriétés. - les variables persistantes du QuickApp (celles qui sont configurées dans l'onglet dédié de l'interface Web... et qui sont en réalité stockées dans les propriétés du QA, cf ligne juste au dessus) A ne pas confondre avec les Variables de la HC3 elle-même, accessible dans l'onglet Général de la box, qui sont accessibles de partout. On les utilisait massivement à l'époque de la HC2 (car c'était à peu près le seul moyen de stocker de l'information, y compris pour transmettre de l'information entre des VD ou Scènes), mais elles sont beaucoup moins utiles sur la HC3.

RoomsConfort est une table à index numériques car elle est définit comme ceci : RoomsConfort = {"SdJ", "Bureau", "Pauline", "Max", "SdBEtage", "Biblio", "SdBRdC", "ECS"} Par conséquent, dans ta boucle for, tu ne peux pas comparer key à la valeur de ta chaine de caractère Room. Il faut comparer value : if Chauf_Maison_Mode == "Confort" then for _, value in ipairs(RoomsConfort) do -- Look for value inside entire table if value == Room then -- Your desired value you want to refrence Found = true end end Note au passage que j'ai viré le key qui n'est pas utile (remplacé par un underscore _ qui est une convention en LUA pour désigner une variable qu'on n'utilise pas) Autre chose, j'ai utilisé ipairs() au lieu de pairs() car la table utilise des index numériques, et ça présente 2 avantages : boucle plus rapide, et index parcourus par ordre numérique (à contrario, pairs() n'est pas déterministe et parcoure les index dans un ordre imprévisible... c'est pénible parfois)

Normal, j'en parlais hier justement, dans un message un peu plus haut. Ta fonction Consigne() est définie comme une variable globale (car il n'y a pas de mot clé local devant) Et comme le contenu de la fonction QuickApp:GoogleThermo() est exécuté après que le compilateur LUA ait parcouru tout le fichier, alors la fonction Consigne() est bien connue au moment de son appel. Cependant, si tu l'avais déclaré en local comme ceci local function Consigne (Room, Mode, Chauf_Maison_Mode) -- blah blah blah end alors ça n'aurai pas fonctionné, car toute variable locale (les fonctions sont des variables en LUA) n'est connue qu'après sa déclaration. On a longuement parlé des variables locales et globales sur le forum, je ne me souviens plus du topic, de mémoire c'était avec @jjacques68. De façon générale, on peut dire que ce n'est pas une bonne pratique d'utiliser des variables globales, pour au moins 3 raisons : - on ne maitrise pas sa portée (puisque par définition elle est utilisable partout dans le code), donc elle peut entrer en collision avec une autre variable du même nom située dans une autre boucle, une autre fonction, un autre fichier, etc... gare aux bugs imprévisibles ! - plus lent à utiliser (car LUA doit parcourir la super table _G pour la retrouver) - consomme plus de RAM, car une variable globale n'est jamais purgée de la mémoire par le garbage collector, même si elle n'est plus jamais utilisée Cela dit, les variables globales sont plus simples à utiliser pour le débutant qui n'a pas saisi les subtilités de la portée des variables locales. Il y a un précis à ce sujet sur le forum : https://www.domotique-fibaro.fr/topic/1199-prã©cis-sur-les-variables-localesglobales/ Je t'aurais bien donné le code pour déclarer ta fonction en local au début du script, puis la définir plus loin, afin de l'utiliser correctement, mais elle aura besoin d'ajouter self en paramètre, donc au final la solution que tu as retenu de définir Consigne en tant que membre de QuickApp est beaucoup plus simple. Même si cela pose un nouveau problème (ou pas), car toutes les fonctions membres de de QuickApp sont automatiquement exportées, c'est à dire exécutables depuis l'extérieur du QuickApp. C'est à dire depuis un autre QuickApp, une scène, via l'API http, etc. Dans 99,99% des cas c'est sans conséquence, mais gare au petit malin qui voudrait s'amuser à exécuter une fonction pour voir ce que ça fait. Pas besoin à priori. Sans return, en LUA la fonction retourne nil, c'est à dire rien du tout. Cela ne pose aucun problème, inutile de mettre des return si on n'a aucune valeur intéressante à retourner.

@Barelle ah ben oui, bravo, au moins toi tu as lu les commentaires du code LUA @jojo attention il faudra que tu appelles ta fonction comme ceci du coup (avec l'ajout de self devant, car ta fonction sera un membre de QuickApp) : self:Consigne(Room, Mode, Chauf_Maison_Mode) Il y a beaucoup de discussions sur le forum, difficile de rattraper ton retard, le meilleur tuto pour comprendre les bases des QuickApp (avec rappel des notions importantes en LUA) c'est sur le forum officiel par @jang : https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/page/21/#comment-207742 https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/page/21/#comment-207789 https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/page/21/#comment-207833 https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/page/54/#comment-223530 EDIT : vous êtes trop rapides, vous faites les questions et les réponses !

Dans la mesure où Consigne() est déclarée en tant que variable globale, je ne pense pas que ça plante lors de l'appel de cette fonction ? Et même si ça n'est pas une bonne pratique (cf les discussions l'année dernière sur un topic quelque part...), ça simplifie l'écriture du code. Autrement il faudrait la déclarer en local, et surtout avant son appel. Mais là on va perdre @jojo, donc j'en reviens à la question : quel est le message d'erreur qui lui fait dire que "ça ne marche pas". De toute façon je n'ai encore jamais vu un QuickApp marcher perso, et encore moins ses enfants

Hum.... d'accord.... et donc c'est Google qui appelle ta fonction QuickApp:GoogleThermo() ? Ensuite tu dis que "ça ne marche pas", mais quel est le message d'erreur ? Je ne suis pas devin, et je t'avoue que je n'ai guère envie de recopier ton code LUA sur ma box pour le tester.... Autre chose, tu n'as quasiment aucune trace de debug dans ton log.... perso quand j'ai un bug que je ne comprends pas, je vais jusqu'à ajouter une ligne de debug entre chaque ligne, pour tracer ligne par ligne. Un peu fastidieux, mais vu qu'on n'a aucun outil de debug à disposition sur la HC3, on fait avec les moyens du bord.

Template, non, de toute façon il n'y en avait déjà pas sur la HC2 pour ces modules (comme de nombreux autres modules de marques non-Fibaro), mais cela n'empêche aucunement les modules de fonctionner. Le seul vrai problème avec les Qubino fil pilote, ce que certains modèles ont un firmware buggé, qui empêche l'inclusion d'aller à son terme. Il faut bidouiller en interrompant le process, etc... On en a largement parlé sur le topic des Qubino Fil Pilote, tu devrais aller y jeter un oeil. Cela dit, ce n'est plus trop la saison de ce genre de discussions En tout cas malgré l'inclusion incomplète de mes modules qui sont concernés par le bug en question, ils ont très bien fonctionné durant tout l'hiver 2020-2021

Cool Tu peux supprimer les labels, mais je pense que tu auras des messages d'avertissements dans le log... Du coup, il faudrait modifier le code LUA, mais pas trop le temps pour l'instant.

C'est un peu long... et donc j'ai arrêté de lire après les 2 fonctions turnOn et turnOff, car celles-ci ne font rien ! (à part mettre à jour la valeur de la propriété value) Du coup, commençons pas le commencement, que cherches-tu à faire ? Ensuite ne peux tu pas simplifier ton code (= supprimer 99% des lignes...) pour nous partager la structure, ce que tu cherches à faire ? Cela sera plus facile de t'aiguiller. PS : pense à mettre la coloration syntaxique du LUA, car en plus d'être long, ce code est illisible pour mes pauvres yeux d'humains.

Géniale la réalisation, et génial le tuto Bravo et merci pour le partage

Je ne pense pas que ce paramètre 3 change grand chose. Le firmware peut être une explication au bug rencontré, mais perso je pense que tu as plutôt un problème de saturation (temporaire) du réseau Z-Wave, donc quelques trames perdues, comme expliqué quelques messages plus haut. Surtout que tu indiques bien que c'est aléatoire. Comme solution de contournement, je t'invite à différer les actions. Au lieu de balancer 10 ordres d'un coup, tu les regroupes en 2 groupes d'ordres distincts, décalés de quelques secondes. L'idée, c'est surtout de se débrouiller pour que les 10 volets ne terminent pas leur manœuvre en même temps, car c'est à ce moment précis que tu as des trames perdues : retour d'état du statut, de la puissance, et de l'énergie... ça fait beaucoup (trop) de trames d'un seul coup. C'est en tout cas la solution la plus simple. En alternative, tu pourrais jouer avec le polling : - soit en le forçant dans ta scène LUA, je le fais pour un FGBS récalcitrant (celui de ma sonnette, derrière le pilier en béton derrière le portail en métal), mais c'est un peu délicat à gérer - soit en attendant le polling automatique (déjà discuté), au bout de quelques minutes le statut des volets en erreur doivent se remettre à jour correctement. Auquel cas ta scène n°27 de vérification doit être exécutée après un timeout adapté)

Oui ça va finir comme ça Dans la prochaine mise à jour... (pas tout de suite)

OK c'est clair pour l'alim des FGBS, on est bien d'accord Pour tes volets, si tu attends devant l'interface de la box (sans parler du script LUA), est-ce que les modules se mettent à jour avec du retard ? C'est ça qu'il faut que tu testes, pour mesurer et comprendre le délai de réaction de ton installation. Ensuite tu ajusteras le scénario en fonction. Perso je me suis toujours méfié des script ajusté à la seconde près, ça n'est jamais fiable. Je préfère prévoir large, la domotique c'est rarement instantané, il y a toujours quelque chose qui temporise (le réseau, la box, ...). C'est une des raisons pour laquelle j'aime l'approche de GEA, on vérifie des conditions à intervalle régulier, minimum 30s, mais souvent bien plus long, exemple : que faire si la porte est ouverte depuis 5 minutes, etc. Pas de prise de tête avec le chronomètre.

OK je comprends le principe de ce que tu veux faire maintenant. Mais si tes volets mettent 40 secondes à se fermer, alors il faut attendre un peu plus longtemps pour faire la vérification, le temps que le retour d'état de tous les volets remontent vers la box. Il peut y avoir quelques secondes de retard, surtout si le réseau est encombré, ce qui est fortement susceptible d'arriver si 10 volets s'agitent en même temps (sans compter les autres modules du réseau, et en particulier les lumières que tu actionnes au même moment) Tu peux attendre largement plus, par exemple 1 minute, à tester. Forcer le polling est une solution, mais attention, ça génère beaucoup de trafic, et donc ça risque d'être contre productif, car un réseau saturé implique des trames perdues. Normalement tu ne devrais pas avoir besoin de jouer avec le polling, il faut trouver l'origine du problème, et tel que tu le décris, je pense que tu n'attends pas assez longtemps (cf mon paragraphe du dessus) Tiens, un exemple. J'ai une scène qui éteint toutes les prises le soit au coucher. C'est "marrant", parce que j'entends tous les relais de la maison commuter au même moment. Et ce "même moment", parfois tous les relais commutent en moins d'une seconde, ça fait presque un genre de clac géant. Et d'autres fois, c'est plus long, les relais commutent à quelques secondes d'intervalles, cette latence est le signe évident d'une saturation du réseau Z-Wave. Normal étant donné le nombre d'action effectuées simultanément, avec tous les retours d'états qui s'enchainent (nouvelle valeur du relai, mesure de puissance, énergie, etc) Des FGBS sur pile ? Ils tiennent combien de temps ? Tu arrives à dépasser quelques jours d'autonomie sans recharger ? Sinon pour la syntaxe, pas de mystère, il faut lire la doc sur le site de Fibaro, ou bien chercher sur les forums (ici et l'officiel)