jjacques68

@Nico je commence à m'embrouiller moi-même... (2 soucis sont évoqués : la marche forcée et la latence d'allumage en passant par une scène) on parle bien de la même chose, mais je ne peux pas utiliser l'association directe avec ta méthode car j'utilise les 2 sorties du relais FGS. Et je ne veux/peux pas mettre 2 FGS... Donc je suis obligé de passer par une scène (voir plusieurs d'après la solution proposé par @pepite). Mais allumer qqch via un FGMS et une scène créé de la latence... Chose que j'ai constaté également avec un FGMS et l'action d'une sortie d'un IPX (mais ça semble plus logique et hors sujet ) Donc je trouve pas vraiment de solution à mon problème... même avec vos propositions. Et le fait de chercher à savoir si l'inter est actionné ou non me permettrai de résoudre mon soucis de marché forcé (mais pas celui de la latence). oula j'ose pas me relire

Oui mais ! impossible de savoir si la lumière à été allumé par le fgms, ou pas l'inter !!!!! donc obligé de passer pas une scène, voir 2, si pas trois... et une variable... bonjour le retard d'allumage. un retard que je constate aussi lorsqu'un éclairage, branché sur les output d'un IPX, est allumé par détection du FGMS... en passant car un VD...

Faut que je réfléchisse... En plus on perd en réactivité avec la scène... Envoyé de mon iPhone en utilisant Tapatalk Pro

Ok mais c'est mort ta solution@Nico, j'utilise les 2 relais du FGS... et puis il me semble qu'il y a des soucis avec l'association directe et les relais 1 ou 2 d'un FGS... nan ? Envoyé de mon iPhone en utilisant Tapatalk Pro

Faut que je relise ça tête reposé

Attention le blanc d'Alsace donne mal au crâne

Nan c'est moi dans les 2 topic je voulais avoir des précisions sur le FGMS Et l'assoc directe et les input du FGS

@Nico ton explication dans le topic du FGMS peut me régler le problème ?

ce module me pilote l'éclairage d'une SdB et la VMC. j'ai un FGMS dans cette SdB qui m'allume les 2 lors d'une détection (géré par une scène LUA, pas utilisé association directe... ai posé la question dans le topic du FGMS également). mais je souhaite contrôler la marche forcée par les interrupteur branchés sur S1&S2. Actuellement, je gère ça dans 2 scènes (une pour l'éclairage et une pour la VMC). Et le résultat ne me satisfait pas surtout quand j'actionne l'inter pendant la détection. j'utilise le même système avec l'ipx, et là est nickel car je peux tester la valeur de l'input donc de l'interrupteur. et je souhaiterai faire la même chose avec le FGS. Sais pas si j'ai été assez clair...

Hello tous, j'ai question concernant l'association directe d'un FGMS et un FGS. Comment se passe l'interaction avec une interrupteur relié aux bornes du FGS ? dans le cas où l'on souhaite une marche forcé par exemple ! Et donc ne plus avoir de réaction du FGMS... Actuellement je passe par une scène mais qui ne me satisfait pas, c'est pour ça que je pense à association directe ?

Hello tous ! petite question : est-il de connaître l'état des entrées S1 Et S2 sur ce module ? en gros pour savoir si l'interrupteur connecté aux bornes est actionné ou pas... (comme on le ferait avec les input d'un ipx) merci !!

Merciiiiiiiii !

If fibaro:getGlobalValue("ArmementDiurne") == "Off" then ... else ... end http://www.fibarouk.co.uk/support/lua/library/fibarogetglobalvalue/

alors voici le retour de Eaton France concernant la mise à jour de ma carte... c'est très simple : la carte que j'ai acheté ne pouvait pas allé plus loin dans les mises à jour que j'avais faite car elle était trop "vieille". heureusement j'avais la facture ce cette carte car ils me l'ont demandé et du coup ils m'ont renvoyé gratuitement une nouvelle carte à jour sympas les gars !! Et là je peux monitorer les différentes sorties comme je veux... par contre l'envoi de mail provenant de la carte ne fonctionne toujours pas. D'après la doc j'ai l'impression que les mail doivent passer par un serveur mail local. Les serveur extérieurs (smtp.live.com et autre ne passent pas...) ou alors je rempli mal le champ "serveur smtp"... Maintenant y a plus qu'à s'y mettre...

moi non plus... je viens d'ajouter ça dans mon code de la scène : if os.date("%H:%M:%S") >= "23:59:50" or os.date("%H:%M:%S") < "00:00:20" then fibaro:sleep(30*1000) LastUpDate = os.time() end Mais je trouve ça nul de chez nul de chez nul...

alors là mon pauvre... je sais pas quoi te dire, moi j'ai ça dans presque tous mes VD... ah tout hasard, tu as bien remplacer "Id_Icone" par le numéro de l'icone ?

bon ben même résultat, je ne remets pas le debug car il est identique. Ce qui me surprends, c'est que le os.time() s'affiche bien ! On dirait que c'est la HC2 qui perd les pédales à minuit ! (c'est le timecode qui me fait pensé ça...)

par contre je viens de changer mon calcul en utilisant le os.difftime(), on verra la différence... C'est plus propre effectivement, mais je pense pas que ça règlera CE soucis.

c'est plus compliqué que ça... elle ne tourne pas en boucle toutes les secondes mais toutes les 15 secondes. Cette scène observe la date de modification d'une variable (cette variable est modifiée par le changement de statut d'une input d'un ipx... je passe par 2 boutons on&off qui me mettent la variable a 1&0... bref...) Je calcul le temps entre os.time() et la date de dernière modif de cette variable. voici le début de la scène : local LastUpDate = fibaro:getGlobalModificationTime("IpxIn2") --si heure actuelle - heure de la denrière MAJ de la VG < 5 secondes if (os.time() - LastUpDate) < 5 then ... ... ... et donc cette variable (= input de l'ipx) passe de 0 à 1 en une seconde et ça tourne en boucle... tictac-----tictac-----tictac... je teste le "clignotement" de cette input en fait. et donc j'utilise le os.time(), mais si celui-ci déconne, ma scène déconne aussi.... (le reste de la journée c'est stable) oulà ça semble bien compliqué mon explication... non ?

Pfffff, je vais finir par mettre un sleep de 20 secondes à 23h59:50 dans ma scène Et le problème sera vite réglé... mais c'est nul...

Ok je vais changer mon calcul. pour ma mise jour ntp de la box, pas sÛr qu'elle le fasse elle même, j'ai mis ce VD justement à cause du décalage qui se produisait ! je vais désactiver ce module on verra bien. mais ça n'explique toujours pas le plantage de miniuit, ça me pause un vrai problème.

chose dite chose promis, scène plantée à minuit. voici le debug de la scène qui observe le os.time : [DEBUG] 23:59:40: 1500328780 [DEBUG] 23:59:41: 1500328781 [DEBUG] 23:59:42: 1500328782 [DEBUG] 23:59:43: 1500328783 [DEBUG] 23:59:44: 1500328784 [DEBUG] 23:59:45: 1500328785 [DEBUG] 23:59:46: 1500328786 [DEBUG] 23:59:47: 1500328787 [DEBUG] 23:59:48: 1500328788 [DEBUG] 23:59:49: 1500328789 [DEBUG] 23:59:50: 1500328790 [DEBUG] 23:59:51: 1500328791 [DEBUG] 23:59:52: 1500328792 [DEBUG] 23:59:53: 1500328793 [DEBUG] 23:59:54: 1500328794 [DEBUG] 23:59:55: 1500328795 [DEBUG] 23:59:56: 1500328796 [DEBUG] 23:59:57: 1500328797 [DEBUG] 23:59:58: 1500328798 [DEBUG] 23:59:59: 1500328799 [DEBUG] 00:00:00: 1500328800 [DEBUG] 00:00:01: 1500328801 [DEBUG] 00:00:18: 1500328802 [DEBUG] 00:00:18: 1500328803 [DEBUG] 00:00:18: 1500328804 [DEBUG] 00:00:18: 1500328805 [DEBUG] 00:00:18: 1500328806 [DEBUG] 00:00:18: 1500328807 [DEBUG] 00:00:18: 1500328808 [DEBUG] 00:00:18: 1500328809 [DEBUG] 00:00:18: 1500328810 [DEBUG] 00:00:18: 1500328811 [DEBUG] 00:00:18: 1500328812 [DEBUG] 00:00:18: 1500328813 [DEBUG] 00:00:18: 1500328814 [DEBUG] 00:00:18: 1500328815 [DEBUG] 00:00:18: 1500328816 [DEBUG] 00:00:18: 1500328817 [DEBUG] 00:00:18: 1500328818 [DEBUG] 00:00:19: 1500328819 [DEBUG] 00:00:20: 1500328820 [DEBUG] 00:27:01: error : 2 s [DEBUG] 00:27:05: error : 2 s [DEBUG] 00:27:07: error : 2 s [DEBUG] 00:27:13: error : 2 s [DEBUG] 00:27:15: error : 2 s [DEBUG] 00:27:24: error : 2 s [DEBUG] 00:31:03: error : 9 s [DEBUG] 00:53:08: error : 2 s [DEBUG] 00:53:11: error : 2 s [DEBUG] 02:48:34: error : 2 s [DEBUG] 02:48:37: error : 2 s [DEBUG] 02:48:39: error : 2 s [DEBUG] 04:48:41: error : 2 s [DEBUG] 04:48:44: error : 2 s j'avoue ne pas trop savoir interpréter le résultat. On voit que à 00:00:01 le debug par en cou... mais le os.time reste bon !!! et c'est la que ma scène pédale dans la semoule. de plus, replantage de ma scène à 00:31, et là pour le coup c'est lorsque le VD Clock Sync de @Krikroff se lance... si quelqu'un à une idée !??

Bonjour à tous, Je remarque que très souvent la fonction os.time() manque de stabilité. J'ai une scène qui tourne H24 et qui utilise os.time(). J'ai plusieurs fois par semaine cette scène qui bug à exactement minuit (rien dans le code de cette scène ne peut la faire planter à minuit...) alors du coup j'ai créé une autre petite scène pour observer le os.time() : --[[ %% autostart %% properties %% events %% globals --]] local last = os.time() function loop() --1. test la différence d'une boucle à l'autre, si plus d'une seconde alors debug if os.time() - last > 1 then print("error : "..(os.time() - last).." s") end --2. affiche os.time de 23:59:40 à 00:00:20 if os.date("%H:%M:%S") >= "23:59:40" or os.date("%H:%M:%S") <= "00:00:20" then print(os.time()) end --affecte la nouvelle valeur à la variable last = os.time() --bouclage toutes les 1 seconde setTimeout(loop, 1000) end loop() cette scène à 2 rôles : 1- si plus d'une seconde d'écart entre 2 boucles on affiche dans le debug la différence de temps 2- affiche chaque seconde le os.time() entre 23:59:40 et 00:00:20. J'ai fais tourner cette scène hier soir de 22h à ce matin 6h... voilà le résultat pour le premier rôle : [DEBUG] 23:44:49: error : 2 s [DEBUG] 23:44:51: error : 2 s [DEBUG] 23:45:06: error : 2 s [DEBUG] 00:31:02: error : 10 s [DEBUG] 02:16:19: error : 2 s [DEBUG] 02:16:22: error : 2 s [DEBUG] 02:16:30: error : 2 s [DEBUG] 02:16:34: error : 2 s [DEBUG] 04:13:31: error : 2 s [DEBUG] 04:13:48: error : 2 s [DEBUG] 06:11:02: error : 2 s [DEBUG] 06:11:04: error : 2 s [DEBUG] 06:11:11: error : 2 s [DEBUG] 06:11:16: error : 2 s [DEBUG] 06:11:23: error : 2 s [DEBUG] 06:11:26: error : 2 s on voit que c'est qu'il y a des trucs étrange entre 23h44 et 6h11 (heure à laquelle j'ai arrêté le script) et voici le résultat pour le second rôle : [DEBUG] 23:59:40: 1500242380 [DEBUG] 23:59:41: 1500242381 [DEBUG] 23:59:42: 1500242382 [DEBUG] 23:59:43: 1500242383 [DEBUG] 23:59:44: 1500242384 [DEBUG] 23:59:45: 1500242385 [DEBUG] 23:59:46: 1500242386 [DEBUG] 23:59:47: 1500242387 [DEBUG] 23:59:48: 1500242388 [DEBUG] 23:59:49: 1500242389 [DEBUG] 23:59:50: 1500242390 [DEBUG] 23:59:51: 1500242391 [DEBUG] 23:59:52: 1500242392 [DEBUG] 23:59:53: 1500242393 [DEBUG] 23:59:54: 1500242394 [DEBUG] 23:59:55: 1500242395 [DEBUG] 23:59:56: 1500242396 [DEBUG] 23:59:57: 1500242397 [DEBUG] 23:59:58: 1500242398 [DEBUG] 23:59:59: 1500242399 [DEBUG] 00:00:00: 1500242400 [DEBUG] 00:00:01: 1500242401 [DEBUG] 00:00:02: 1500242402 [DEBUG] 00:00:16: 1500242403 [DEBUG] 00:00:16: 1500242404 [DEBUG] 00:00:16: 1500242405 [DEBUG] 00:00:16: 1500242406 [DEBUG] 00:00:16: 1500242407 [DEBUG] 00:00:17: 1500242408 [DEBUG] 00:00:17: 1500242409 [DEBUG] 00:00:17: 1500242410 [DEBUG] 00:00:17: 1500242411 [DEBUG] 00:00:17: 1500242412 [DEBUG] 00:00:17: 1500242413 [DEBUG] 00:00:17: 1500242414 [DEBUG] 00:00:17: 1500242415 [DEBUG] 00:00:17: 1500242416 [DEBUG] 00:00:17: 1500242417 [DEBUG] 00:00:18: 1500242418 [DEBUG] 00:00:19: 1500242419 [DEBUG] 00:00:20: 1500242420 Et là comme par hasard, je n'ai eut aucun soucis... on voit bien les secondes s'enchainées l'une derrière l'autre. Par contre on voit le time code du debug qui ne correspond pas à 00:00:16 et 00:00:17 Mais c'est la première fois depuis au moins 1 semaine que, cette nuit, à minuit, ma scène n'a pas plantée... je relance le test ce soir pour voir... et vous posterai le debug... Est-ce que quelqu'un à déjà constaté ce genre de comportement ?

Tu as mis quoi comme module pour ouvrir/fermer la porte de garage ? si c'est un module de volet du peux utiliser la propriété setValue du module, où tu fixes le pourcentage d'ouverture. et du coup pas besoin de setTimeout, sauf si tu veux une fermeture automatique après X temps. sinon essaye en mettant un turnOff dans ton setTimeout...