jojo

un cable, avec d'un côté 2 fils et de l'autre un fiche ...

trop puissant cette section ! J'ai encore BEAUCOUP àapprendre ...

pour les 2 premières lignes, tu dois en 3° paramètre mettre le message, comme tu l'as fait pour la 3° instruction Pour la 3° instruction, tu devrais mettre id["PORTE_DE_SERVICE"] en première condition ET mettre l'ID en entête de script (regarde le Wiki -> syntaxe, c'est expliqué)

intérêt : dans tes scripts tu utilises les nom des devices, et comme le script associe au nom (pour peu que le nom n'a pas changé !) l'ID du device dans une table, tu n'as qu'à mettre à jour la table auto-générée en début de tes codes LUA. En fait tu dois tourner le script en mode debug, et à la fin il te montre un exemple d'utilisation

oui, mais pour cela ils devraient être au courant de cette faille, sauf s'ils ont un espion parmi nous

solution = Générateur D'id Pour Gea (Ou Autre Script) by Steven

question : pour pouvoir faire ceci exploite-t-on une faille de Fibaro qui risque d'être refermée lorsqu'ils auront découvert le pot aux roses ? ça me tente de migrer ...

moi non plus, au début je ne faisait pas confiance àce brol. Puis suite àun tuto de Lazer, j'ai appris comment l'exploiter, et c'est FFAACCIILLEE et puissant. exple : ma vrai alarme, qui communique une intrusion àmon HC2, génère, via le panneau d'alarme des actions, style les lampes de la maison qui clignottent (ça ne sert àrien, mais c'est cool)

@PITP2, j'adore "capilotracté" merci de m'avoir ainsi aidé, j'ai vraiment honte de cette faute de typo (IdconeID - InconeDev et les ") Merci pour le code simplifié. Génial qu'il fonctionne pour v4.x, mais (pour ceux qui aiment faire avancer la science), ce n'est pas suffisant en 3.600 (il veut l'id et le name en plus) Maintenant je suis obligé de faire un tuto pour diffuser ce VD... Et tu as gagné HAUT la main le concours.

regarde au niveau du panneau d'alarme, c'est ce qu'il y a de plus simple

c'est du marketing pour l'élection en cours ?

Mon idée serait en effet de remplacer MaxTime, 1 par StopTask dans la tâche en attente, après le NotStarted,. Mais je ferai des essais ce soir Envoyé de mon Nexus 5 en utilisant Tapatalk

C'est valable aussi si elle sort et qu'on ne l'installe pas ?

en attendant la correction, j'essayerais avec {“StopTaskâ€, <id_tâche>} qui devrait pouvoir remplater un {"MaxTime", 1}

ok, et donc si tu prends un ancien qui était ok et que tu l'inclus maintenant et que le soucis apparait, ça veut dire que les modules ne sont pas en cause, mais le firmware de la box

tu as cela qu'avec les nouveaux modules àpiles, ou également avec les anciens àpiles ? Pour savoir si c'est un bug au niveau des modules ou du firmware de ta box ?

pour prolonger la réflexion. Overide, n'a d'utilité que si Simu_presence est à 1 (et permet en effet de lancer la simu avant le couché du soleil) (c'est comme cela que je l'ai compris en tout cas) Donc évidemment que c'est utile, mais on pourrait avoir le même résultat (selon moi) avec 1 variable et 3 valeurs (Simu_presence = 2 aurait la signification de l'actuel Simu_presence = 1 et overide = 1)

Je viens d'implémenter la version 2.6.2. Tout semble ok. Je ne comprends pas trop ce qui s'est passé. Je me suis permis de faire une petite modif dans ton code de débug, afin qu'on puisse voir le jour (et pas uniqueent l'heure) du débug. fibaro:debug(string.format('<%s style="color:%s;">%s</%s>', "span", color, os.date("%a %d/%m", os.time()).." "..message, "span")); [DEBUG] 23:17:36: Wed 20/05 Presence Simulator | v2.6.2 [DEBUG] 23:17:36: Wed 20/05 -------------------------------- [DEBUG] 23:17:36: Wed 20/05 Not starting Simulation (Simu_presence = 0) [DEBUG] 23:17:36: Wed 20/05 Presence Simulator is Terminated [DEBUG] 23:19:30: Wed 20/05 Presence Simulator | v2.6.2 [DEBUG] 23:19:30: Wed 20/05 -------------------------------- [DEBUG] 23:19:30: Wed 20/05 It's sunset time -> Simulation ON [DEBUG] 23:19:30: Wed 20/05 Turning On always on lights: [DEBUG] 23:19:30: Wed 20/05 Device: Lum_SalonTV On [DEBUG] 23:19:30: Wed 20/05 Now randomizing other lights... [DEBUG] 23:19:31: Wed 20/05 light ID:Lum_SdBEtage status:1 [DEBUG] 23:19:31: Wed 20/05 entering loop of 4.73 minutes [DEBUG] 23:23:57: Wed 20/05 exiting loop of 4.73 minutes Autre question : pourquoi a-t-on deux variables (Simu_presence et overideSimuSunset) car overideSimuSunset = 1 seulement si Simu_presence = 1. On pourrait tout faire avec Simu_presence = 0 ou 1 ou 2 (= overideSimuSunset) ? et il faudrait ainsi créer 1 variable de moins (je sais, je suis une grosse fainéasse). D'autant plus qu'en faisant des tests, je me suis trouvé avec Simu_presence = 0 et overideSimuSunset = 1 (ce qui n'a pas de sens) et mes lampes ont commencé à faire la fête (pour des loops de 2 sec ! [DEBUG] 23:24:20: Wed 20/05 Presence Simulator | v2.6.2 [DEBUG] 23:24:20: Wed 20/05 -------------------------------- [DEBUG] 23:24:20: Wed 20/05 It's sunset time -> Simulation ON [DEBUG] 23:24:20: Wed 20/05 Turning On always on lights: [DEBUG] 23:24:20: Wed 20/05 Device: Lum_SalonTV On [DEBUG] 23:24:20: Wed 20/05 Now randomizing other lights... [DEBUG] 23:24:21: Wed 20/05 light ID:Lum_SdBEtage status:1 [DEBUG] 23:24:21: Wed 20/05 entering loop of 9.58 minutes [DEBUG] 23:33:24: Wed 20/05 exiting loop of 9.58 minutes [DEBUG] 23:33:25: Wed 20/05 light ID:Lum_SdBEtage status:0 [DEBUG] 23:33:25: Wed 20/05 entering loop of 2.37 minutes [DEBUG] 23:33:26: Wed 20/05 exiting loop of 2.37 minutes [DEBUG] 23:33:27: Wed 20/05 light ID:Prise_Bureau status:1 [DEBUG] 23:33:27: Wed 20/05 entering loop of 9.22 minutes [DEBUG] 23:33:29: Wed 20/05 exiting loop of 9.22 minutes [DEBUG] 23:33:30: Wed 20/05 light ID:Lum_SdBRez_Douche status:1 [DEBUG] 23:33:30: Wed 20/05 entering loop of 6.65 minutes [DEBUG] 23:33:32: Wed 20/05 exiting loop of 6.65 minutes [DEBUG] 23:33:33: Wed 20/05 light ID:Prise_Bureau status:0 [DEBUG] 23:33:33: Wed 20/05 entering loop of 7.55 minutes [DEBUG] 23:33:36: Wed 20/05 exiting loop of 7.55 minutes [DEBUG] 23:33:37: Wed 20/05 light ID:Prise_Bureau status:1 [DEBUG] 23:33:37: Wed 20/05 entering loop of 6.16 minutes [DEBUG] 23:33:38: Wed 20/05 exiting loop of 6.16 minutes [DEBUG] 23:33:39: Wed 20/05 light ID:Lum_SdBEtage status:1 [DEBUG] 23:33:39: Wed 20/05 entering loop of 10.99 minutes [DEBUG] 23:33:43: Wed 20/05 exiting loop of 10.99 minutes [DEBUG] 23:33:44: Wed 20/05 light ID:Prise_Bureau status:0 [DEBUG] 23:33:44: Wed 20/05 entering loop of 8.61 minutes [DEBUG] 23:33:46: Wed 20/05 exiting loop of 8.61 minutes [DEBUG] 23:33:47: Wed 20/05 light ID:Lum_SdBRez_Douche status:0 [DEBUG] 23:33:47: Wed 20/05 entering loop of 7.28 minutes [DEBUG] 23:33:49: Wed 20/05 exiting loop of 7.28 minutes [DEBUG] 23:33:50: Wed 20/05 light ID:Lum_SdBRez_Douche status:1 [DEBUG] 23:33:50: Wed 20/05 entering loop of 2.91 minutes [DEBUG] 23:33:51: Wed 20/05 exiting loop of 2.91 minutes [DEBUG] 23:33:52: Wed 20/05 light ID:Lum_SdBRez_Douche status:0 [DEBUG] 23:33:52: Wed 20/05 entering loop of 9.65 minutes [DEBUG] 23:33:55: Wed 20/05 exiting loop of 9.65 minutes [DEBUG] 23:33:56: Wed 20/05 light ID:Lum_SdBRez_Douche status:1 [DEBUG] 23:33:56: Wed 20/05 entering loop of 4.81 minutes [DEBUG] 23:33:58: Wed 20/05 exiting loop of 4.81 minutes [DEBUG] 23:33:59: Wed 20/05 light ID:Lum_SdBRez_Douche status:0 [DEBUG] 23:33:59: Wed 20/05 entering loop of 1.31 minutes [DEBUG] 23:33:59: Wed 20/05 exiting loop of 1.31 minutes [DEBUG] 23:34:00: Wed 20/05 light ID:Lum_SdBEtage status:0 [DEBUG] 23:34:00: Wed 20/05 entering loop of 2.62 minutes [DEBUG] 23:34:01: Wed 20/05 exiting loop of 2.62 minutes [DEBUG] 23:34:02: Wed 20/05 light ID:Prise_Bureau status:1 [DEBUG] 23:34:02: Wed 20/05 entering loop of 10.07 minutes [DEBUG] 23:34:05: Wed 20/05 exiting loop of 10.07 minutes [DEBUG] 23:34:06: Wed 20/05 light ID:Prise_Bureau status:0 [DEBUG] 23:34:06: Wed 20/05 entering loop of 3.55 minutes [DEBUG] 23:34:07: Wed 20/05 exiting loop of 3.55 minutes [DEBUG] 23:34:08: Wed 20/05 light ID:Prise_Bureau status:0 [DEBUG] 23:34:08: Wed 20/05 entering loop of 6.29 minutes [DEBUG] 23:34:10: Wed 20/05 exiting loop of 6.29 minutes [DEBUG] 23:34:11: Wed 20/05 light ID:Prise_Bureau status:1 [DEBUG] 23:34:11: Wed 20/05 entering loop of 11.67 minutes [DEBUG] 23:34:14: Wed 20/05 exiting loop of 11.67 minutes [DEBUG] 23:34:15: Wed 20/05 light ID:Lum_SdBRez_Douche status:1 [DEBUG] 23:34:15: Wed 20/05 entering loop of 9.26 minutes [DEBUG] 23:34:18: Wed 20/05 exiting loop of 9.26 minutes [DEBUG] 23:34:19: Wed 20/05 light ID:Prise_Bureau status:0 [DEBUG] 23:34:19: Wed 20/05 entering loop of 9.24 minutes [DEBUG] 23:34:22: Wed 20/05 exiting loop of 9.24 minutes [DEBUG] 23:34:23: Wed 20/05 light ID:Prise_Bureau status:1 [DEBUG] 23:34:23: Wed 20/05 entering loop of 10.7 minutes [DEBUG] 23:34:26: Wed 20/05 exiting loop of 10.7 minutes [DEBUG] 23:34:27: Wed 20/05 light ID:Lum_SdBRez_Douche status:0 [DEBUG] 23:34:27: Wed 20/05 entering loop of 4.23 minutes [DEBUG] 23:34:29: Wed 20/05 exiting loop of 4.23 minutes

Merci Steven pour la confirmation de mon interprétation. Y a-t-il une erreur dans mon code ou s'agit-il d'un bug (comme ça je sais si je dois continuer àchercher une solution) ? -- Mettre ECS àoui pendant 20 min -- Tache en sommeil (NotStarted) -- Cette tache va passer la variable àNon si elle est àOui depuis plus de 20 minutes seulement si elle était passée àOui àcause de LUM_SDBREZ_DOUCHE local autoECSNon = GEA.add (estECS, 20*60, "Variable ECS àOUI depuis #durationfull# => variable ECS = NON", {{"VirtualDevice", DeviceID["VAR_ECS"], 4}, {"Email", UserID["Vincent"], "INFO - ECS"}, {"NotStarted"}, {"MaxTime", 2}}) -- Cette tache va passer la variable àOui si la lumière de la douche est allumée depuis 1 min et que la variable ECS est ànon -- Elle va aussi redémarrer la tache si dessus GEA.add ({DeviceID["ALARME_ACTIVE"], DeviceID["LUM_SDBREZ_DOUCHE"], pasECS}, 1*60, "Variable ECS àOUI car LUM_SDBREZ_DOUCHE allumée depuis #duration#.",{{"Inverse"}, {"VirtualDevice", DeviceID["VAR_ECS"], 3}, {"Email", UserID["Vincent"], "INFO - ECS"}, {"RestartTask", autoECSNon}})

Cool, j'avais pas vu sur tapatalk Envoyé de mon Nexus 5 en utilisant Tapatalk

Sorry, j'avais pas compris. Tu veux faire cela en lua ou en gea ? Envoyé de mon Nexus 5 en utilisant Tapatalk

les paramètres remontés par le FGK-101 le sont en fonction ce ce qui est paramétré dedans. Par exple, le paramètre 12 définit la différence de tmp (si tu as une sonde de tmp) qui doit être mesurée avant de l'envoyer à la box. regarde également ici : http://tutoriels.domotique-store.fr/content/11/29/fr/parametres-du-fibaro-sensor-fgk_101.html

merci @mprinfo d'avoir également regardé. La liste des gens à citer augmente Ceci dit, je peu faire des PUT en 3.600, alors pourquoi pas en 4.x ? Par ailleurs, je ne comprends pas bien ce que tu m'explique avec le schéma des API. Je te mets ici le json d'un device en 4.x { id: 107, name: "104.2", roomID: 48, type: "com.fibaro.temperatureSensor", baseType: "com.fibaro.multilevelSensor", enabled: true, visible: true, isPlugin: false, parentId: 104, remoteGatewayId: 0, interfaces: [ "battery", "zwave", "zwaveWakeup" ], properties: { parameters: [], associationSet: [], associationView: [], zwaveCompany: "Fibargroup", zwaveInfo: "3,3,67", zwaveVersion: "25.25", wakeUpTime: 4000, pollingTimeSec: 0, batteryLevel: "78", batteryLowNotification: "true", configured: "true", dead: "false", defInterval: "0", deviceControlType: "0", deviceIcon: "30", emailNotificationID: "0", emailNotificationType: "0", endPointId: "2", interval: "0", liliOffCommand: "", liliOnCommand: "", log: "", logTemp: "", manufacturer: "", markAsDead: "true", maxInterval: "0", minInterval: "0", model: "", merci @PITP2 pour ton post

En fait ça a bien marché un peu, mais plus maintenant (que le GEA tourne depuis un certain temps). C'est comme si le MaxTime ne se remettait pas à zéro à chaque restart de la tâche. N'est-ce pas comme ça que cela devrait fonctionner ?

@PITP2 : Merci et zut ! On dirait que c'est un bug. Je propose d'attendre le prochain update pour retester, j'ai épuisé toutes mes idées