e1000

Bon, finalement il fonctionne. Suppression puis réinclusion, seulement il ne faut pas oublier de cocher la case "Ajouter au mode sécurité si l'appareil prend en charge" avant de l'inclure...

Bonjour Gandalf Oui. Oui, enfin, un FGS-222, en utilisant une sortie par pièce. Mais ça ne te fera pas 10 zones, mais seulement 5 (3 zones pour les 3 FGD-212, et 2 zones pour le FGS-222). Si tu veux absolument 10 zones, il te faudra au moins 4 FGS en plus des 3 FGD. Je ne conseille pas de supprimer les interrupteurs physiques. Si tu n'as plus de réseau (box internet HS, plus d'app) ou plus de z-wave (box domotique HS, plus de télécommande), comment contrôleras-tu tes éclairages ? Il est toujours possible d'associer directement une télécommande Zwave avec les modules, mais bon, une télécommande ça s'égare facilement... Cela étant dit, il est possible de monter les modules sans connecter d'interrupteur : ça ne change rien au câblage, il suffit de ne pas mettre les interrupteurs. Oui. Oui. J'aurais tendance à dire que si tu ne fonctionnes que avec du Zwave ou des modules supportés par les plugins officiels, la Lite sera suffisante. Si tu as besoin d'interfacer avec des éléments via IP, ou besoin de scènes complexes, le LUA est nécessaire. Je ne connais pas assez la HC lite pour être affirmatif, mais pour tes exemples avec les stores, la Lite sera largement suffisante, à condition d'avoir des capteurs météo supportés par Fibaro, ou de se contenter du module "Weather" intégré. Pour les commandes d'éclairage que tu cites en exemple, oui, c'est possible en mode bloc, et même sans aucun script (en associant ton bouton/télécommande ou ton détecteur de présence directement aux modules concernés). My 2 cents.

Bonjour, Ce (vieux) détecteur fonctionnait très bien jusqu'il y a quelques mois. Je ne saurais pas dire à partir de quelle version du Firmware HC2 il a cessé de fonctionner. J'ai vu ici que certains parlaient d'une compatibilité partielle, puis d'incompatibilité. Quelqu'un a-t-il des news ? Réussi à le faire fonctionner ? Merci.

Oui, c'est ce que je suspectais, d'où ma question pour éliminer un problème de fiabilité éventuellement connu. Ce FGMS est proche de la box (5m mais avec murs) mais à côté du tableau électrique avec perturbations EM possibles... Peut-être qu'un relai a commuté au moment de l'émission de la trame.

Bonjour à tous, Un de mes FGMS m'a indiqué une température folklo à deux reprises (une fois + de 95°C, l'autre fois 75°C), et donc avec les alertes sur un incendie potentiel qui vont avec... Vous avez déjà rencontré ce type de soucis avec ce module ?

Salut Sevetse, plugin SARAH mis à jour sur github : https://github.com/e1000g/SARAH-Plugin-Home-Center Attention, je n'ai pas testé le code. Si tu as des questions, n'hésite pas. Attention, mon plugin ne fonctionne que pour SARAH 4. Pour la 316, d'autres plugins fonctionnent très bien. De plus, ma SARAH ne tourne pas en ce moment, donc je pourrai difficilement aider/debugger en 'live'. Bon courage. e1000

Bonjour Sevetse, Je ne peux rien promettre en termes de délais, mais je vais regarder ça dès que j'ai un moment (ça fait un moment que je n'ai pas touché àSARAH et je n'ai pas de module volet-roulant, mais àpartir de l'API ça ne devrait pas poser trop de problèmes). Cordialement e1000

Yep. Ce plugin est pourri. Làje suis déconnecté, message "sign in failed" ou un truc dans le genre. Mais ça marche quand même.

Si ça fonctionne avec les boutons, alors ça doit fonctionner avec le call. T'as bien changé l'id ? Dans le premier post tu parles de l'id 264, et làde 269 à270. Donc : fibaro:call(269, "changeActivityState") doit lancer (ou arrêter) ton activité 269. Faut reconnaître qu'il est pas au point ce plugin.

@jackd67000 cf l'API Fibaro : la seule "action" possible pour les activités Harmony est : "actions": { "changeActivityState": 0 }, Donc pas de turnOn, pas de turnOff, et pas de pressButton non plus (ce n'est pas un VD). Jamais testé en lua, mais puisque c'est dans l'API, et s'ils sont un peu cohérents, j'imagine que la fonction est accessible en lua. Essaie ça pour voir (je ferai le test ce soir si j'y pense) : fibaro:call(264, "changeActivityState"); Hope this helps. e1000

Je verrais bien un truc comme ça : Une tâche 1 qui éteint la lumière après 1mn si garage fermé. Une tâche 2 qui allume la lumière si nuit et si porte ouverte. Une tâche 3 qui allume et stoppe la tâche 1 si appui manuel. Une tâche 4 qui éteint et relance la tâche 1 si appui manuel. Une tâche 5 qui éteint, ferme la porte et relance la tâche 1 si tu quittes la maison. Y a sans doute moyen d'optimiser, mais sauf àutiliser une variable globale de plus, faut utiliser stopTask je pense. C'est ce que j'utilise pour gérer l'extinction automatique après 1mn (si allumage sur détection de présence) ou après 10mn (si appui sur l'interrupteur) dans un lieu de passage.

Yep, ça marche mais toujours sans retour d'état. Limite inutilisable puisque c'est la même commande pour ON et OFF via l'API, et qu'on ne peut pas être sûr de l'état.

Version 0.3.4 du plugin homecenter sur GitHub avec récupération automatique des modules et écriture des fichiers xml : https://github.com/e1000g/SARAH-Plugin-Home-Center/blob/master/build/homecenter-0.3.4.zip La commande "Sarah, mets à jour les modules de la box" génère la configuration automatique des fichiers xml pour la grammaire et les modules. Il est préférable de modifier les fichiers générés pour avoir des commandes vocales plus naturelles, mais c'est toujours mieux que de tout écrire à partir de zéro.

Oui, je suis bien d'accord, mais si la condition est "true" comme inititialement, ça veut dire que si la variable change, vide ou pas, le script est lancé et l'action (toujours vraie) aussi. Après le problème est que son action est toujours lancée avec le script, pas uniquement avec une modif de la variable, mais c'était pas la question Attendons le retour de Cisco, mais je pense que son problème vient du panneau de variables, pas du script.

Même pas besoin de code, on peut le faire directement avec l'API accessible depuis l'interface : http://IP/docs/#!/devices/modDevice Il faut juste renseigner l'id et le json qu'on veut passer en paramètre. Mais apparemment on ne peut pas faire ce que l'on veut, il doit y avoir un contrôle de cohérence : le binarySensor veut bien être transformé en motionSensor, mais pas en FGMS001 par exemple. Après, faut juste tester, et au pire du pire un "soft reconfigure" rétablit le module avec le template par défaut, donc aucun risque

@Steven Pourquoi tu testes si la variable n'est pas vide ? Si le code initial ne déclenche pas avec une condition toujours vraie, celui-ci ne déclenchera pas non plus Ou alors j'ai loupé un truc, ce qui est fort possible

Tout dépend comment tu modifies ta variable. De mémoire, je crois que la modification manuelle des variables globales par le panneau des variables ne déclenche pas d'évènement : ça ne peut donc pas lancer le script. Pour tester, il faudrait faire un script ou un VD qui modifie la variable.

Bonjour, Certains d'entre vous ont peut-être un bon vieux capteur 3 en 1 EZ Motion : détecteur de mouvement + capteur de température + capteur de luminosité. Le problème de ce capteur est qu'il n'est pas reconnu comme détecteur de mouvement, et n'est donc pas géré par l'alarme Fibaro : on ne peut pas l'armer ou le désarmer. En effet, on voit dans la capture ci-dessus, ou si l'on vérifie les paramètres de ce module via l'API REST, qu'il est de type 'binarySensor'. Adresse : http://192.168.1.12/api/devices/9 (modifiez ce qui est en rouge selon votre config) { "id": 9, "name": "Présence Sà M", "roomID": 6, "type": "com.fibaro.binarySensor", "baseType": "com.fibaro.sensor", Bref, c'est un capteur de mouvement, certes, mais pas un détecteur... Mais contrairement à ce que l'on croit, on peut modifier le type de certains modules (mais on ne peut pas attribuer n'importe quel type à n'importe quel module). Avec la méthode PUT, envoyez une requête à la même adresse, avec le 'body' suivant : { "type": "com.fibaro.motionSensor" } Puis vérifiez le JSON renvoyé en retour (ou nouvelle requête avec la méthode GET) : { "id": 9, "name": "Présence Sà M", "roomID": 6, "type": "com.fibaro.motionSensor", "baseType": "com.fibaro.sensor", Et hop, un détecteur de mouvement parfaitement fonctionnel : Ce module est vraiment pas mal, très fiable pour ce que j'ai pu en juger depuis 3 ou 4 ans que je l'ai, mais il est nécessaire de l'alimenter par un transfo (il est prévu pour), parce que sinon il bouffe des piles. Enjoy. e1000

Merci pour l'ajout.

Update en ligne : https://github.com/e...gin-Home-Center - ajout support de la Logitech Harmony : Le support est basique : pas de test de l'état d'une activité avant de la lancer donc si elle est lancée, ça l'éteint... À corriger plus tard. La consultation de l'état est également fonctionnelle. - modifs de la structure de la grammaire pour faciliter la reconnaissance : Motif optionnel entre le nom de l'action et celui du module (le, la, les, du, des, de la ...) - ajout support modules virtuels pour volets roulants Somfy RTS : Pas très utile sauf si vous avez exactement le même module virtuel (que vous trouverez sur ce forum, cela dit ).

Bonjour, Nouveau plugin pour SARAH (v4) qui supporte la nouvelle API de Fibaro. Devrait fonctionner avec toutes les box, mais je n'ai pas de HCL pour tester. Pour l'instant, seules les fonctions suivantes sont supportées : commande et interrogation des dimmers et switches commande des modules virtuels (boutons et sliders) interrogation des sondes interrogation de la météo C'est sur github : https://github.com/e1000g/SARAH-Plugin-Home-Center e1000

Non, le tamper est associé au détecteur de mouvement (PIR), pas au sismomètre. Il n'a pas de device dédié. Bonne nouvelle alors, je vais pouvoir le "dé-cacher". Non, pas de 5e esclave. Le détecteur de mouvement, c'est ton 4e module, celui que tu appelles FGMS001 (chez moi c'est le premier, mais l'ordre est un peu aléatoire, défini lors de l'inclusion apparemment). ​Dans les propriétés générales, il doit être précisé: Genre: Détecteur de Mouvement Oui, exactement. Oui, parce qu'en fait le sismomètre est une sonde (basetype : com.fibaro.multilevelSensor et type : com.fibaro.seismometer), et non un détecteur : donc il ne s'arme pas.

Tu enregistres bien ta scène après avoir modifié le nombre d'instances ? Perso j'ai mis 3 et pour l'instant plus de messages.

Attention, juste pour être bien sà»r, le détecteur de mouvement c'est le détecteur de présence (mouvement devant le capteur), pas le mouvement du FGMS lui-même. Inutile de le secouer, ça c'est pour déclencher l'anti-sabotage (tamper). Au vu de ton code, tu es sà»r que c'est pas le PIR qui allume ta lumière et non l'anti-sabotage ? Attention au délai de réarmement : il faut attendre le temps défini par le paramètre 6 (annulation de l'alarme mouvement) pour pouvoir redéclencher. Le sismo n'était pas fonctionnel, ça a changé ? Si par "mouvement" tu veux dire "présence", il vaut mieux distinguer les deux tests. Si par mouvement tu veux dire sabotage, a priori inutile : même si maintenant il fonctionne, le sismomètre mesure la même chose que l'anti-sabotage (mais qui lui n'a pas de périphérique dédié). Je ne suis pas sà»r, mais normalement non : cf paramètre 6 (délai pour le détecteur de présence) et paramètre 22 (délai pour l'anti-sabotage). Passé ce délai, le détecteur annule son alarme, et est donc prêt pour une nouvelle détection, mais ne désactive pas l'alarme générale. L'alarme Fibaro empêche l'exécution des scènes. T'a coché la case qui va bien pour GEA ? Parce que là : - 1 - le détecteur déclenche l'alarme - 2 - l'alarme bloque GEA - 3 - GEA ne peut donc pas allumer la lampe

Oui, en cas de sabotage (pour tous les capteurs) et pour le FGFS pour savoir qu'il a été déplacé, et donc potentiellement remis au mauvais endroit (ou s'en servir comme capteur de mouvement ?).