Sowliny

Tout à fait d'accord avec toi ! J'ai moi aussi des antiquités dont je ne me séparerai que lorsque leur heure sera venue... J'ai rencontré la (presque) même problématique : 4 détecteurs (pour le moment) autour de la maison et de la grange - à ceci près qu'ils sont directement en relation avec la HC3. Pour moi aussi le souci (léger) était que la HC3 soit informée d'une détection. Pour exemple, le détecteur de la grange est un "Steinel sense IQ" d'une portée de 12 mètres. Sa sortie détection fournit un front montant de la tension du secteur (du jus...), normalement destiné à allumer x ampoules. J'ai simplement réduit la temporisation au minimum (soit 5 secondes je crois) et connecté cette sortie sur l'entrée S1 d'un FGSnnn. (bon, dommage d'utiliser un FGS pour cela, mais ça m'évite une petite alim dédiée... - après, c'est une question de place) Avec un trigger en surveillance, le tour est joué. La HC3 déclenche en suite l'éclairage autour de la maison et de la grange pour 5 minutes. (pourquoi tant d'éclairage ? J'habite en lisière de forêt et il y a du "monde" qui circule - et pas seulement les biches... !) J'ai un autre détecteur qui fonctionne différemment : sa sortie "met la charge" au neutre, donc ne peut pas agir sur S1. J'ai donc intercalé un petit relais en sortie, qui lui me fournit un front de phase pour S1 (j'espère être clair). Du "jus" donc... Même procédure ensuite en ce qui concerne la tempo et le trigger. C'est vrai que l'idéal serait d'intégrer un Smart Implant directement dans le détecteur, mais il faudrait prélever directement l'alimentation sur la platine de celui-ci. Le Smart Implant sera donc aussi soumis au potentiel secteur (en fait tout dépend du type d'alimentation - mais souvent on rencontre une alim sans transfo, avec un condensateur tampon). Je n'ai pas encore tenté cela.

Tu as bien dit "module virtuel", donc tu est sous HC2. Tu l'insères donc directement dans le code d'une touche par exemple, ou dans le "Main". Tout simplement comme : fibaro.sleep(5000) Ou si tu as besoin d'une tempo plus longue, avec une boucle comme suit : for CAM_off = (tonumber(fibaro:getGlobalValue("MM_kamery_ON"))*4), 1, -1 do -- *4 : permet de multiplier par 4 la fréquence (sleep(15000) = 15 secondes) d'affichage des messages if (tonumber(fibaro:getGlobalValue("FLAG_kamery")) == 20) -- détection de l'arrêt forcé du timer par action sur la touche "OFF" then fibaro:abort() end INFO_msg("message", "Cameras : " ..math.modf(CAM_off/4) .." minute(s) remaining", nil) fibaro:sleep(15000) -- cadencement du délai "remain" end Ne te focalise pas sur le code (commande de caméra).

Bonjour @adelac, Ton "cas" est finalement très simple . Les entrées IN1 et IN2 du FGBS peuvent être commandées directement par les sorties de l'Abacus je pense, l'une fournissant le signal "mouvement" et l'autre le signal "sabotage" Vu la haute impédance d'entrée du FGBS, il n'y aura pas de dégradation de la tension des signaux fournis. Il n'est donc pas nécessaire de faire "transiter" ces signaux par le FGBS pour ensuite les réinjecter dans ta centrale ou ailleurs. Par contre vérifie bien que la tension des signaux n'excède pas la tension d'alimentation du FGBS. sinon... Et qu'il n'y a pas de (surtension) transitoire générée par un relais. Si cela est le cas, intercale entre IN1 (et 2) et la masse une Zener de 12v. Ou encore un étage à transistors, ou un relais Reed. Tout cela pour la longévité du FGBS... PS1 : je ne considère pas m'être "penché sur ton cas" (ça me fait plaisir de d'aider), je t'apporte mon aide à la mesure de mes moyens - comme j'ai bénéficié moi aussi de celle des membres du fofo. Bien à toi . PS2 : L'Abacus me semble etre "vieux tromblon", mais moi aussi... .

Deux solutions : soit tu programme un fonctionnement monostable de la sortie concernée avec la durée nécessaire, soit tu insère un fibaro.sleep(4000). Pour plus de souplesse, j'avais préféré le sleep (qui permet une retouche facile de la durée, éventuellement via une VG - mais là ça fait beaucoup...) PS : j'ai mis 4000 car je pense que c'est la valeur préconisée ma Microsoft - mais 5 devrait bien coller aussi.

Bonjour @adelac, Ta description me semble un peu confuse et j'aimerai éclaircir tout cela d'abord. Pour l'alimentation du Smart Implant, pas de problème, le 12v est ok, de même que la tension des signaux qui serait du même ordre. Par contre tu dis que "Jeedom ne doit pas pouvoir commander les détecteurs à distance" - or, les ports OUT du SI (Smart Implant) sont des sorties (si le SI a été configuré en ce sens) destinées à exécuter une action, donc ici à agir sur le détecteur/centrale d'alarme (au fait : quelle marque, type... ?). Ta dernière phrase "mais que dois-je faire pour les bornes IN1 et IN2 du Fibaro" : ben justement, je pense que tu dois y connecter d'une part le fil "sabotage", et d'autre part le fil "mouvement". Enfin "ce qui ferait que sur la borne GND du Fibaro, il y aurait 3 fils : le 0V de l'alimentation, 1 fil sabotage et 1 fil mouvement" : si je capte bien du voudrais connecter ensemble 3 fils, dont le 0V ? Je ne comprends pas la finalité - connecter 2 fils pouvant véhiculer une tension (?!) sur un point de masse (0V) ??? Pour résumer, tu souhaites détecter 2 évènements (mouvement et sabotage), les envoyer sur Jeedom par le biais du SI. PS : un p'tit schéma serait le bienvenu...

Avec le Smart Implant, tu peux effectivement faire un reset ou un arrêt forcé - ceci dit, Win10 est beaucoup plus tolérant que les versions précédentes à ce type d'arrêt ! J'en fais usage rarement, mais le redémarrage n'a jamais posé problème. Quant à la tension, je la récupère directement sur la carte mère - sur le connecteur "Chassis intrusion connector" (5v). PS : Comme @Lazer le dit, "Parce que le Wake On LAN ça ne fonctionne que quand ça veut, c'est tout sauf fiable." Alors avec Alexa, tu rajoutes un (autre) maillon (faible ?).

Non, tout à fait, Sur les cartes mères assez récentes (c.à.d. au moins 5/8 ans, il persiste une tension (au moins 5v) pour activer le démarrage (via le bouton poussoir "power") La véritable mise hors tension se fait avec l'interrupteur physique à l'arrière du boîtier. PS : le FGBS accepte 5v

Bonjour @jjacques68, C'est pas une question bête... C'est même la question qui tue... Il est vrai que lorsque j'avais conçu ma petite platine, je savais pas faire un WOL (je sais, la honte......).

Même impossible je reconnais. Mais une version avec un Smart Implant rentrerai facilement.

Certes...

J'ai conçu pour le démarrage (et reset) de mon PC une petite carte à insérer dans un slot. Elle comporte un FGBS et un FGS222. La photo présente l'ancienne version (la nouvelle est dans mon PC qui est en transit actuellement - je le récupère dans quelques jours) L'alimentation est double : secteur 230v pour le FGS et 12v pour le FGBS (recuperd duf le connecteur système de la carte mere X99 WS (Asus) alimentée par un bloc Corsair AXI650 (qui fournit une tension "de veille". Je vais plancher sur une version (bien plus simple) avec un Smart Implant qui permet d'actionner contrairement au FGBS... Mais celle-ci fonctionne parfaitement.

Tout à fait pas propre , ça me gave profond quand je vois ça... comme disent les d'jeun's. On est soumis au bon vouloir de Fibaro pour arranger cela (je parle de "restart running scene"). Je pense sincèrement qu'ils auraient pu se concentrer sur ces fonctionnalités "de base", au lieu de donner dans "l'esbrouffe pour d'autres choses moins fondamentales. Mais bon, tant que ça déclenche correct... Promis, je vais tester sur NO, pour voir...

Bonjour en ce beau matin ! Oui, l'option "Allow..." est bien sur YES (mais il me semble que pour le moment cela n'a pas d'importance, comme le restart n'est pas implémenté). J'ai aussi régulièrement (à chaque redéclenchement alors que l'instance primaire est en cours) cette ligne dans le debug : [30.08.2020] [09:11:28] [ERROR] [SCENE33]: Je pense que cela correspond à ta description. Quoi qu'il en soit, cela ne semble pas avoir d'incidence sur le déroulement de la scène, ni sur son arrêt - toujours correct.

Voici la liste des triggers (hormis la condition "fautive" initialement associée à la condition 54) : -- ID 42 = Wykrywacz stodoły -- ID 54 = Wykrywacz taras -- ID 149 = Jasność tarasu -- ID 211 = Nodon Pink { operator = "any", conditions = { { type = "device", id = 54, property = "value", operator = "==", value = true, isTrigger = true }, { type = "device", id = 42, property = "value", operator = "==", value = true, isTrigger = true }, { id = 211, isTrigger = true, operator = "==", property = "centralSceneEvent", type = "device", value = {keyAttribute = "Pressed", keyId = 2 }}, { id = 211, isTrigger = true, operator = "==", property = "centralSceneEvent", type = "device", value = {keyAttribute = "Pressed", keyId = 4 }} }} Pour le moment, tout fonctionne bien. Il y en a 2 pour les PIR, et 2 pour la télécommande Nodon (211). La scène redémarre à chaque déclenchement - je l'ai vérifié avec le debug des deux PIR. Donc pas de souci ? A quel genre de surprise je devrais m'attendre ?

Ce matin, tout est correct (normal...). Peut-etre demain j'inverserai la logique du test pour éviter le "kill", en incluant tout le processus dans un "if then..." Mais avec quelques réserves dues au fait que cette scène est déclenchée par trois acteurs : PIR de la terrasse, PIR de la grange, télécommande Nodon... Et plus tard PIR du pignon nord-est de la maison, PIR du "couloir" entre la maison et la grange (surtout pour l'entrée de la grange)... Avec une gestion séparée des deux zones "grange" et "maison".

Je me suis douté en écrivant cela que j'aurai bien un commentaire marrant ...

PS : pour répondre à ton interrogation sur le nom de la VG (je te dois bien ça) : MID_ : Module ID wykr_ : détection (wykrywanie...) taras_ : terrasse (facile !) C'est ma syntaxe générale sur les noms de VG.

C'est en effet la VG du PIR. Tu as bien compris. J'ai fait comme cela en attente de : 1) tester sur plusieurs jours (quoique le résultat soit déjà certain. 2) trouver ce qui coince dans le trigger (quoique là aussi, il n'y a plus grand chose à attendre...) Ta solution est plus élégante bien sûr, et je l'adopterai certainement. C'est bien sur mieux que de "killer" !

Bon, retour à la case départ... Rien n'y fait, le déclenchement en plein jour persiste ! Du coup, j'ai supprimé le test de la luminosité dans la section trigger : { type = "device", id = 149, isTrigger = true, operator = "==", property = "value", type = "device", value = 0 }, et remplacé par un test au début de la scène elle-même : if sourceTrigger.id == tonumber(fibaro.getGlobalVariable("MID_wykr_taras")) and tonumber(fibaro.getValue(149, "value")) > 5 then fibaro.debug("debug","Scene "..sceneId.." killed (swiatlo = "..fibaro.getValue(149, "value")..")") fibaro.scene("kill", {sceneId}) end "si le trigger est le détecteur terrasse et que la luminosité est > à 5" alors tuer la scène. Pas très élégant, mais ca ira en attendant de trouver une solution à ce (bug ?).

Jamais essayé - ce n'était qu'une hypothèse basée sur des "value" que j'ai déjà rencontré sur différents modules... Je crois que je vais en rester là (avec un test "< 3" s'il n'y a plus de déclenchements en plein jour. J'ai bien d'autres projets en cours et en vue. Aujourd'hui je viens de réactiver (c.à.d. de transférer la scène depuis la HC2) ma boîte à insoler les circuits (imprimés). Réalisée à partir d'une boîte de rangement Ikéa. Elle me permet de tirer des cartes au format europe.

In fine : à la nuit, ça fonctionne parfaitement. J'en déduis donc que le trigger "operator "==" ... value = 0" pose un problème. Surtout value = 0. Le test ne semble pas fonctionner (du moins avec ce module). Soit il s'agit d'un bug (lié à la jeunesse de la HC3 ?), soit le "zéro" renvoyé par le module n'est pas un "vrai" zéro (peut-être une valeur de type 0.0) et ne peut donc pas répondre au test "= 0". Ou alors le bug vient de moi !

J'avais déjà testé (au début) seulement motion et lux; Ca fonctionnait parfaitement. Le debug donne la valeur correcte de luminosité. Par contre, j'ai reproduit (et supprimé l'erreur - enfin je pense), car ma (?) HC3 est un peu fantasque, et ne supporte pas bien les enregistrements successifs de scènes, sans un reboot de temps en temps. L'éclairage extérieur s'allume (puisqu'il s'agit de cela) avec operator "==" et value = 0, ce qui ne devrait pas se produire puisque la luminosité extérieure est à plus de 300. Par contre, l'allumage ne se produit pas avec les valeurs : operator "<" et value = 3 - ce qui est le but ! Ce qui laisserait à penser que la valeur "zéro" n'est pas vraiment nulle - cela pourrait être 0.0 ? Je testerai à la nuit pour voir... Merci pour ta réponse et ton éclairage

J'espère que je ne "déterre" pas ce sujet ? Je sèche sur une combinaison de triggers (qui par ailleurs fonctionne à la perfection). Le hic c'est qu'une condition dit toujours "oui". La première. Elle est censée trigger quand un détecteur (Aeon Multisensor 6, à cause de l'option humidité) se déclenche ET quand la luminosité est à zéro. Mais la condition est remplie et "trigge" même en plein jour. Voici le listing : { operator = "any", conditions = { { operator = "all", conditions = {{ type = "device", id = 54, property = "value", operator = "==", value = true, isTrigger = true }, { type = "device", id = 149, isTrigger = false, operator = "<", property = "value", type = "device", value = 3 }} }, { type = "device", id = 42, property = "value", operator = "==", value = true, isTrigger = true }, { id = 211, isTrigger = true, operator = "==", property = "centralSceneEvent", type = "device", value = {keyAttribute = "Pressed", keyId = 2}}, { id = 211, isTrigger = true, operator = "==", property = "centralSceneEvent", type = "device", value = {keyAttribute = "Pressed", keyId = 4}} }} L'ID "motion" est le 54, et celle de la luminosité est 149 (en tête de listing). J'ai testé plusieurs syntaxes operator/conditions, mais on a vite fait le tour. Je penche maintenant pour soit une erreur de property, soit un bug du concepteur (moi...).

Désolé du retard... (j'ai pas reçu de notif ?) Non, ce type de maison est extrêmement répandu dans tous le pays (bon, surtout dans les montagnes...) Pour en connaître une, il y a effectivement beaucoup de chambres, avec sdb à tous les étages siouplaît ! Utilisation en chambre d'hôtes, mais surtout à but familial/générations.

J'avais comme l'impression que c'était pire avec un peu d'humidité/ombre..