fel-x

Après lecture de la syntaxe, j'ai trouvé la solution et donc je réponds moi-même à ma question. Corrigez-moi si j'ai mal compris. Tout d'abord la configuration de base, où il faut rajouter les ID's des modules pour pouvoir y faire appel via leur numéro plutôt que par leur nom (par exemple "746" au lieu de "id.RAPHAEL_FENETRE") -- Définition des ID des modules local id = { METEO = 3, -- YR Weather -- Ajouter ici les autres ID RAPHAEL_STORE = 514, RAPHAEL_FENETRE = 746, } Ensuite les conditions : -- Mise en protection du volet de Raphael si sa fenêtre est ouverte GEA.add({"Value", 746, true}, -1, "Fenêtre de Raphael ouverte --> Volet en mode protection.", {{"Portable", 535, "Fenêtre de Raphael ouverte --> Volet en mode protection."}, {"Protection", 514, "Local_RF", "On"}}) GEA.add({"Value", 746, false}, -1, "Fenêtre de Raphael fermée --> Protection du volet désactivée.", {{"Portable", 535, "Fenêtre de Raphael fermée --> Protection du volet désactivée."}, {"Protection", 514, "Local_RF", "Off"}}) J'y ai ajouté un message PUSH sur mon portable pour m'assurer que ça fonctionne, mais je vais le supprimer, car les tests sont 100% concluants. Le volet se met bien en protection locale et RF dès que la fenêtre est ouverte. J'ai deux remarques quand même : 1/ si la pile du détecteur (746) tombe en panne, l'ouverture de la fenêtre n'activera pas la protection, et alors crac boum... donc je vais bosser sur une condition du genre "si le niveau de batterie du 746 est inférieure à 25% --> alerter tout le monde et commander des piles" 2/ Dans la syntaxe GEA v7.38 Syntaxe.lua les modes de protection sont définis comme ceci à la ligne 742 : <mode> : Off | Local_RF | Local | RF Mais les exemples des lignes 745 à 753 emploient ces modes parfois avec une majuscule et parfois avec une minuscule ("local_rf", "Local", "#r#local|local_rf"). Idem avec "on" qui parfois est écrit "On", et "off" qui est pourtant écrit avec une majuscule "Off" dans les règles de syntaxe. Puis-je en déduire que GEA est non sensible à la casse ? On peut écrire "Value" ou "value" ? on peut écrire "False" ou "false" ou "FALSE" ?

OK je me lance à la découverte de GEA J'ai parcouru plein de pages du forum à travers divers topic relatifs à GEA. Je voudrais juste m'assurer de lire la syntaxe récente de GEA, car certains exemples remontent à plus de 10 ans. Est-ce que la première page de ce topic est bien celle où je peux pêcher la syntaxe de base (version 5.00 modifiée le 8 décembre 2014): J'ai cru comprendre que malgré les mises à jour et le passage vers HC3, la syntaxe a évolué mais ne contient aucune commande obsolète. Je pense que GEA v7.38 Syntaxe.lua est la version adéquate de la syntaxe actuelle @jojo je suis preneur d'une copie de ton fichier Notepad++ si tu l'as annoté de tips&tricks

En effet je le trouve mais bizarrement uniquement dans un seul des modules enfants ; dans le 493.0 (qui est caché dans l'interface car je ne me sers pas des modules enfants) De toute façon, ça fonctionne très bien comme tu l'avais dit @Lazer : La protection locale empêche les commandes via l'interrupteur et la protection à distance empêche les commandes via le GUI et l'app Fibaro/Yubii C'est donc bien ces 2 protections que je voudrais activer dès que la fenêtre est ouverte, et les désactiver lorsqu'elle est fermée. J'imagine qu'il est possible de les activer (ON/OFF) via un appel LUA ? Ou alors comme l'a dit @jojo ce type de paramètre n'est pas modifiable en LUA ou via l'API ? Je vais essayer de lire le document de syntaxe de GEA en espérant y comprendre assez pour trouver comment lui faire surveiller l'état en temps réel de la fenêtre. Si quelqu'un a un script ou un code de ce type, je suis preneur

Pas certain de trouver le bon paramètre... C'est bien là qu'il faut chercher celui dont tu parles ?

Ok Donc je vais installer GEA. Je n'ai encore jamais employé cette QA c'est le moment de découvrir ! Quand je vois qu'il y a 27 pages sur le topic, je me dis qu'il y a de la lecture à faire et de l'apprentissage derrière... J'espère que ce n'est pas trop compliqué De toute façon ce ne sera pas perdu. Mais d'abord je vais aller vérifier si le module dispose bien d'un paramètre de blocage de commande (je ne sais pas trop ce que c'est en fait). Comme il s'agit d'une vieille version du roller shutter (il n'est même pas Z-Wave+ il me semble) il est possible que ce ne soit pas dispo si ce type de paramètres est lié au firmware du module.

Salut, je bloque sur la façon d'écrire une QA (ou une simple scène LUA) qui doit surveiller l'état d'un module 24h/24 et 7j/7 pour empêcher un autre de s'activer. Je m'explique : J'ai un capteur d'ouverture fibaro FGK (ID: 746) sur une fenêtre dans la chambre de mon fils, que la Home Center 3 affiche "détecté" quand la fenêtre est ouverte et "non détecté" quand elle est fermée. Cette fenêtre s'ouvre vers l'intérieur. Il a ouvert la fenêtre il y a 1h40 et donc je vois ceci : Sur cette fenêtre il y a un store électrique occultant intérieur, il est piloté par un Fibaro Roller Shutter (ID 516). Actuellement il est ouvert : Le problème est mécanique : si la fenêtre est ouverte, il doit être interdit et impossible de faire descendre le volet, car il va rencontrer le bord de la fenêtre et se bloquer, et n'ayant pas de capteur de résistance, il continue à descendre et se déchire et surtout fait exploser le caisson contenant l'enrouleur. C'est déja arrivé , car le fiston n'est pas attentif et appuie sur le bouton physique de commande de descente, ou parce qu'une scène avait déclenché la descente de tous les volets de la maison lors d'une alarme intrusion ou d'une vague de chaleur.... Bref les situations qui peuvent casser le volet ne manqueront pas. Je voudrais donc un script ou une quickapp sur ma HC3 qui surveille en permanence l'état de la fenêtre et qui empêche la fermeture du volet si celle-ci est ouverte. Merci d'avance si vous avez une idée élégante et propre de coder ceci ?

Allez voici la version 1.0 de la QuickApp Merci aux testeurs et pour les retours. Omlet_Coop_Door_v1.0.fqa

@jang Thanks indeed I was looking for a way to disable a button while still being visible. (no need to press "open" when the door is already opened) I will use the single button solution I guess, or just leave it as it is, since pressing "open" when the door is already opened doesn't do any harm. Best regards

Tiens d'ailleurs... j'ai réussi à faire en sorte que l'image affichée dans le label soit différente selon l'état de la porte (OPEN/CLOSE) : mais je suis à la recherche de la méthode qui permettrait d'inactiver (griser) le bouton d'ouverture si elle est ouverte, et le bouton de fermeture si elle est fermée... Je sais faire disparaître le bouton (visible > false) mais ce que je cherche c'est de le rendre inactif mais toujours visible. Si quelqu'un a une idée ?

Et voilà le travail avec l'API de Omlet C'est pas mignon tout plein ? Et on peut ouvrir/fermer la porte encore un peu de debug et je la partage si quelqu'un est intéressé...

Oui c'est perturbant mais il faut se dire qu'avant d'exécuter onInit() (que ce soit automatique ou parce que tu sauvegardes) la HC3 va relire tout le code et toutes les pages du QA, et donc inclure les fonctions des pages annexes. C'est pourquoi il faut faire attention à ce que tu déclares dans les pages autres que main.lua !

Merci @Lazer ! Grâce à ta réponse, j'ai compris un élément essentiel : Dès lors, j'ai vu les choses autrement et ça m'a permis d'avancer à grands pas... Ma première QA est écrite et fonctionnelle Je l'ai mise à disposition dans le sujet en question et sur marketplace.

Ca y est j'y suis arrivé ! Ma première QA fonctionne. La voici pour ceux qui veulent tester... évidemment il faut un compte chez Blueriiot sans quoi vous n'aurez pas accès à l'API. De toute façon ça n'a aucun intérêt en dehors du contexte d'une sonde Blue Connect (Plus/Go). Je joins l'icône. Je l'ai mise à disposition sur le Fibaro Marketplace aussi, pour voir si ça intéresse d'autres personnes que moi sur cette terre Tous vos retours et/ou conseils sont bienvenus. BlueRiiot_Blue_Connect_v1.1.fqa

tout d'abord la sonde que tu proposes (Blue Connect Go) est uniquement fonctionnelle en local en bluetooth ou alors avec le kit wifi etc. Moi je dispose de la Blue Connect Plus (ici) Elle a une batterie de 3-4 ans et se calibre toute seule. J'ai changé la batterie il y a peu, ça m'a couté 8 Euro je pense. Mais le sonde Blue Connect Plus est chère à l'achat par contre. Elle se connecte au réseau SigFox (ancien réseau militaire je pense) chaque heure et transmet toutes les valeurs mesurées au serveur de BlueRiiot. Une application gratuite te permet de vérifier à tout instant les mesures (soit en bluetooth si tu es à côté) soit par internet car elle se connecte au serveur de BlueRiiot. Grâce à son API (non public ou en tout cas très peu documenté) j'ai réussi à simuler une connexion par un script Lua pour récupérer les mêmes valeurs. Je n'en suis pas encore à les faire afficher de façon jolie dans un QA mais je les reçois ! Pour ce faire, j'ai installé un proxy sur mon ordinateur et fait passer mon iPhone par ce proxy pour récupérer tout le code qui passe dans les deux sens ! Ca m'a donné plein d'infos sur la méthode d'authentification de l'appli et sur les requêtes et les endpoints. J'ai aussi cherché des indices dans des scripts publiés sur GitHub et testé dans les langages que je connais sur ma raspberry... puis tenté de traduire en LUA. Bref, j'ai écrit un premier scénario en LUA et quand je l'active, il récupère l'ID de mon BlueConnect Ce script ne sert qu'une fois, car l'ID ne change pas. Mais j'en avais besoin pour le mettre dans un second scénario qui se connecte à l'API, envoie mes données d'identification et l'ID du BlueConnect, et récupère un token que j'emploie pour générer une requête signée AWS4 et recevoir en retour les dernières mesures que ma sonde a envoyées au serveur. Il me debug ces dernières valeurs. Exactement comme si j'allumais mon appli sur mon iPhone. Je suis occupé à essayer de mettre tout ce code dans une QA pour que ce soit automatisé et pouvoir le partager avec toi et le monde Mais c'est compliqué

Salut les amis, je parcours des dizaines de forums et de topics ces derniers mois pour me familiariser avec les quickapps durant mon temps libre. J'ai écrits des scénarios en LUA qui fonctionnent individuellement... mais je voudrais les combiner dans une quickapp. Et évidemment ça ne marche pas du premier coup, surtout en l'absence de connaissances profondes en programmation. Ci-dessus dans ce post je pense avoir trouvé une piste pour ce que je veux faire. En gros, je voudrais séparer plusieurs fonctions dans des fichiers (certains disent "onglets" mais ce sont bien des fichiers LUA) de la même QA afin de ne pas l'alourdir. Disons que je crée une QA qui s'appelle QA_Test avec dedans 3 fichiers lua : main (il est obligatoire lui), tools et utils Ma structure serait : QA_Test ├─ main.lua ├─ tools.lua ├─ utils.lua Disons aussi que tools.lua contient un long code rempli de variables locales et de fonctions et exécute ces fonctions et termine par enregistrer les résultats obtenus dans des variables de la QA avec setVariable() Disons enfin que utils.lua est du même acabit mais sert à faire d'autres calculs et exécuter d'autres fonctions, et termine lui aussi par enregistrer les résultats obtenus dans des variables de la QA avec setVariable() Si je comprends bien il n'y a pas de fonction aussi simple que "require()" ou "include()" en Lua sur HC3. Cependant on peut appeler une fonction ou plusieurs fonctions d'un autre fichier de la même QA ? Mais peut-on simplement faire exécuter tout le code lua d'un fichier ? Dans mon cas, main.lua devrait par exemple vérifier une variable "machin" et si elle est vide (= "") alors il exécute tools.lua et sinon il exécute utils.lua. C'est possible ça ? Ou bien je dois lui faire exécuter un scénario via son ID ? Car en effet le contenu de tools.lua et de utils.lua provient de 2 scénarios que j'ai écrits et qui fonctionnent. Ce serait quand même plus propre d'avoir tout le code dans une seule QA, de façon à pouvoir la partager non ? Merci pour vos conseils avisés