Sowliny

Je n'ai rien trouvé aussi sur la conso du smart... reste à le tester avec un ampèremètre pour avoir une estimation assez précise. Mais ça doit se situer entre +/- 0,6 à 1,nnn watt, soit très peu (en mode "tranquille", et sans commande aux deux switchs). Bien moins que les 30mA boulottés (inutilement pour 99% du temps) par les afficheurs. Le courant de travail <30mA me paraît correct, compte-tenu que c'est un affichage multiplexé et certainement en PWM. Quoi qu'il en soit, 30mA à longueur de journée est (beaucoup ?) trop pour ton système. Fais le test avec les afficheurs éteints d'abord, pour voir le tenue sur 24h.

Tu vas être surpris je pense en comparant les deux consommations (afficheurs vs Smart Implant) Pour les afficheurs, coupe leur retour a la masse (ou au + le cas échéant) en intercalant par exemple une ampoule Reed juste derrière le couvercle transparent - ce qui préservera "l'étanchéité"... Tu pourras ensuite activer l'affichage avec un simple aimant.

Points à vérifier/corriger : ■ l'orientation du panneau par rapport au soleil (azimut, élévation) ■ est-ce que les afficheurs sont alimentés ou allumés en permanence ? Ce sont certainement les plus gros consommateurs. Vérifie la consommation du Smart Implant SEUL en configuration "de travail" Après tu pourras calculer la durée théorique de la batterie. PS : une LED draine jusqu'à 20/25 mA, alors un afficheur avec "2" par exemple ça fait 100mA au pire (sauf bien sur en cas de multiplexe, ce qui est la règle pour ces petits afficheurs.

Désolé du retard... Tu dis "car j'ai transféré dans mon ancienne hc2" : là je ne te comprends pas. Tu les as transférés DEPUIS ta HC2 ? Pour "l'ancienne appli Android" il est normal je pense que tu voies tous les modules - sûrement un effet mémoire (?). Il est notoire également que les applis Android ne jouissent pas d'une grande fiabilité - surtout la nouvelle. (là, je vais peut-être me faire corriger, je n'ai pas une grande expérience dans les applis). Par contre pour la HC3, il faut impérativement utiliser la nouvelle version. J'ai également transféré tous mes modules de la HC2 vers la HC3, sans aucun problème, et les mises à jour des modules se sont toujours bien passées, même en version actuelle (5.040.37). Autre chose notoire, tu passe d'un système HC2 STABLE vers un système HC3 encore non abouti - et je ne parle pas des innombrables (bugs) et autres fonctions pas encore ou incomplètement implémentées. J'ai fait ce choix par "obligation", en toute connaissance de cause - ma HC2 se trouvait à 2000 km et je n'avais localement qu'une HC lite (parfaite bien sûr, mais inadaptée à l'envergure de mon nouveau projet). Cela dit, mis à part une période "faste" en emmerdes de tout genre... la HC3 tourne correctement (après déverminage de la base de données interne - qu'ils ont dit). Bien sûr pas de folies - que du basique, avec des scènes limitées au seul Lua.

Je viens de recevoir un mail relatif à un module passerelle entre le système Nice et Fibaro (HC3). Le bidule s'appelle "BiDi-ZWave" Et voici le pdf de présentation : Nice BiDi-ZWave - InstalatON.pl.pdf Et les notices : Nice BiDi-ZWave - InstalatON.pl.pdf Guide FG-IBT4ZWAVE .pdf Déjà en vente chez Domadoo... Bonne lecture ! Notice IBT4ZWAVE.pdf

Bonjour @gregmmat, Tout d'abord, avant d'intégrer tes modules, les as-tu bien dissociés "à vide" vis-à-vis de la HC3 ? Quasi indispensable avant de les intégrer de façon sûre.

Les Smart Implants risqueraient plutôt de provoquer une baisse de tension (certes faible) dû au drainage via les entrées IN1 et 2. Mais cela me paraît très improbable - je ne pense pas que l'alarme (vu son âge) soit en mesure de détecter une si infime baisse de tension. Toutefois, une solution radicale serait d'insérer un étage à transistor (MosFet par exemple - à très haute impédance d'entrée) ou une porte logique (pourquoi pas un trigger de Schmitt ?). Mais ça fait beaucoup... Teste plutôt directement en connectant le Smart Implant. Pour voir, et provoquer des situations qui pourraient perturber la centrale (?).

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" !