jjacques68

Alors ça porte le nombre à 993 caractères

oui c'est ça, mais avec tout... ouverture, on/off, thermostat, ... Mon script est bien mais le mail est tronqué

Observation : Vous avez déjà remarqué qu'on soit limité à exactement 988 caractères dans les notifications par mail avec la commande sendEmail ? C'est un peu embêtant quand on cherche à faire un mail de checkup des états des devices... Il tronque le mail !!

Bon alors ça je savais pas... Bon ça compliquer encore plus les choses... 1 scène... 1 VD... ... Je crois que je vais garder ma scène Mais dès que j'ai le temps d'essayer pour pas mourir bête, je le fais, c'est intéressant, je te tiens au courant... En attendant, pour mon problème de temps de réaction, j'ai réussi à l'améliorer considérablement en jouant avec le paramètre 3 qui était à 1-2 impulsions par défaut. Je l'ai mis à 0-1 impulsion.

Mais je pense pas qu'il soit la solution au problème car il faut spécifier un temps, et moi je n'ai pas de temps à spécifier.

il faudrait trouver un moyen de mettre en pause le script tant que la fonction n'a pas retourné sa valeur ! Je tourne autour du settimeout denouveau...

j'ai essayé avec ton code, en le copiant simplement dans une scène, aucune erreur !!! Mais exactement la même réaction, le test de la variable Input renvoi false parce que le fonction n'a pas renvoyé la valeur. Le code continue à s'exécuter et donc il crois que l'input est à 1 au lieu de 0... D'où l'ordre d'affichage dans le debug qui est inversé par rapport à ce que cela devrait être. Je pense vraiment que cela vient du fonctionne asynchrone de la requette http... C'est pas très clair cette histoire d'asynchrone, si qqun pouvait l'expliquer !!! Dans mon premier script, ce problème n'apparait pas car j'ai imbriqué les commandes dans les requêtes HTTP même ! L'une à la suite de l'autre. J'avais déjà eut ce soucis d'enchainement pour mes script de patrouille des caméras...

Alors, dans un premier temps j'ai essayé en ajoutant une fonction de test: Mais du coup je pense qu'il y a un soucis à cause de la méthode asynchrone de la requête http. C'est à dire que le retour de la fonction n'apparait qu'après le premier test de la variable Input, donc elle n'est pas prise en compte ! --[[ %% properties 298 value %% events %% globals --]] if fibaro:countScenes() > 1 then fibaro:abort() end local http = net.HTTPClient() --Fonction qui test l'input 3 de l'IPX --return True si l'input 3 = 0 (pas d'interrupteur enclenché) --return False si l'input 3 = 1 (interupteur enclenché) function TestIpx() http:request("http://192.168.2.41/api/xdevices.json?cmd=10", { options = {method = 'GET', headers = {['Authorization'] = "BASIC YWRtaxxxxxxx="},}, success = function(response) jsonResponse = json.decode(response.data) if jsonResponse.IN3 == 0 then print("Input à 0") return true else print("Input à 1") return false end end, error = function(response) fibaro:debug("Error: " ..response) end }) end if tonumber(fibaro:getValue(298, "value")) == 1 then --si passage sur ON -- test l'input de l'IPX ne fait rien si lumière enclenchée par interrupteur) if TestIpx() then --on allume print("<font color='green'>Escalier = ON</font>") fibaro:call(296, "pressButton", 1) while tonumber(fibaro:getValue(298, "value")) == 1 do --tant que sur ON, on boucle fibaro:sleep(2*1000) --tempo 2 secondes end --retest de l'input avant d'éteindre (cas d'un allumage forcé par interrupeteur) if TestIpx() then fibaro:call(296, "pressButton", 2) --on éteint print("<font color='red'>Escalier = OFF</font>") else --sinon on laisse allumé print("<font color='yellow'>2 eme test : Escalier = manuel</font>") end else --sinon on laisse allumé print("<font color='yellow'>1er test : Escalier = manuel</font>") end end Voici le debug qui me le fait penser : [DEBUG] 18:03:56: 1er test : Escalier = manuel [DEBUG] 18:03:56: Input à 0

Je viens de survoler ton code, jolie !!! J'essaye ce soir ! le fonction de test est bien vu ! Ça va alléger... par contre il va y avoir un effet de clignotement, je veux dire par la que on rallume que si elle s'est éteinte ?! Nan ? JE te confirme cela ce soir ! merci !

Tient étrange, j'avais répondu à ta question mais visiblement, ça n'a pas pris !!! Donc je recommence, en effet le sleep n'a pas vraiment d'intérêt là. Je pourrais l'enlever et ne garder que le while .... do ça mettra le code en pause tant que le FGMS n'est pas repasser à 0. J'avais mis le sleep car je me suis dis que cela pourrait clamer le proc de la HC2 ! Et puis mettre une boucle while do avec rien dedans ça faisait bizarre ! nan ?

On avait déjà parlé du setTimeout J'y avais pensé, mais je vois pas comment l'intégrer dedans. Car dans ce cas, la durée est gérer par le FGMS lui-même ! Tant qu'il est en alerte ! Elle n'est pas fixe.

Ah bien vu, j'y avais pas pensé, c'est vrai que chez moi j'utilise un port > 1000...

Tu n'as pas un firewall sur ton routeur qui bloquerait les redirections de ports ? Parce que au vu de tes print screen, tout a l'air ok !

Bonjour à tous, J'ai essayé cette après midi de faire un éclairage sur détection pour une cage d'escalier. ça marche comme je veux mais !!! Je trouve qu'il y a un certain temps de réaction de l'installation... (2-3 secondes) Matériel : - 1 FGMS dans la cage d'escalier - 2 interrupteurs montage classique va et vient relié sur l'input 3 d'un IPX - Eclairage branché sur output 7 de l'ipx (via un contacteur jour/nuit) Configuration du FGMS : Param 1 = 10 (défaut) Param 2 = 2 (défaut) Param 3 = 1-2 impulsions (défaut) Param 4 = 2-12 secondes (défaut) Param 6 = 10 secondes J'ai VD avec 2 boutons ON/OFF qui me permet d'allumer ou éteindre depuis le Tél ou autre. (ce VD commande la sortie de l'IPX) C'est ces boutons que j'actionne depuis la scène. J'ai créé une scène pour gérer tout cela : -Cette scène est déclenchée lors du changement de valeur du FGMS. -lors du déclenchement de la scène, je teste d'abord si un interrupteur n'a pas été actionné (en testant l'input de l'IPX) -si pas le cas j'allume pendant le temps définit par le param 6 du FGMS -avant d'éteindre, je teste de nouveau si pas d'interrupteur actionné -si pas le cas je coupe la lumière La voici : (désolé pour la syntaxe du code, mais l'éditeur de texte du forum fait un peu ce qu'il veut avec les indentations...) --[[ %% properties 298 value %% events %% globals --]] if fibaro:countScenes() > 1 then fibaro:abort() end local http = net.HTTPClient() if tonumber(fibaro:getValue(298, "value")) == 1 then --si passage sur ON du FGMS -- avant test pour voir si un interrupteur n'a pas été actionné http:request("http://192.168.2.41/api/xdevices.json?cmd=10", { options = {method = 'GET', headers = {['Authorization'] = "BASIC YWRtaW46xxxxxxxxx="},}, success = function(response) jsonResponse = json.decode(response.data) if jsonResponse.IN3 == 0 then --allume si pas allumer par interrupteur print("<font color='green'>Escalier = ON</font>") fibaro:call(296, "pressButton", 1) while tonumber(fibaro:getValue(298, "value")) == 1 do --tant que FGMS sur ON, on boucle fibaro:sleep(2*1000) --tempo 2 secondes end --reteste si pas action d'interrupteur http:request("http://192.168.2.41/api/xdevices.json?cmd=10", { options = {method = 'GET', headers = {['Authorization'] = "BASIC YWRtaW46xxxxxxxxxxx="},}, success = function(response) jsonResponse = json.decode(response.data) if jsonResponse.IN3 == 0 then --éteint si pas allumer par interrupteur fibaro:call(296, "pressButton", 2) --on éteint print("<font color='red'>Escalier = OFF</font>") else print("<font color='yellow'>Escalier = manuel</font>") --sinon c'est que qqun a actionné interrupteur end end, error = function(response) fibaro:debug("Error: " ..response) end }) end end, error = function(response) fibaro:debug("Error: " ..response) end }) end ça marche très bien tout ça ! Si qqun actionne un interrupteur manuellement, c'est bien gérer ! Mais, je trouve qu'il y a un temps de réaction entre mon apparition devant le détecteur et l'allumage de la lumière (2 secondes). Après quand je vois la complexité de mon code pour une chose si simple ! c'est peut être normal ?! Vous avez d'autres idées plus simples pour l'amélioration ?

Ouah ! le boulet que je suis !! Je désactivais la seule scène qui pouvait cliquer sur le bouton de mon VD, mais celle-ci était contrôlée par le WatchDog... donc elle s'était réenclanchée sans que je me rende compte !!! Bref du coup tout marche comme je le voulais Désolé pour le temps perdu !

Ce que veux faire : ON sur le VD éclairage ----> IPX : relais Activé ------> push de l'IPX -------> action sur un bouton du VD de notification -------> réception de la notification Et mise jour de l'icône sur le VD éclairage. La mise jour de l'icône se fait bien, Mais ne reste pas !

Oui mais si j'actionne l'éclairage depuis le VD éclairage, ça va faire une boucle pour ré appuyer sur le même bouton !

De plus, l'icône doit s'afficher sur le VD éclairage et non sur celui des notifications... c'est comme si le VD faisait un refresh toutes les X minutes. ET toujours rien Dans le main...

J'y ai pensé, Mais ça fait une sacré usine gaz ! plus un risque de bouclage nan ? bon après dans l'absolu, Je n'allume les lumières que Par le VD éclairage ! Pas par un autre moyen. mais c'était histoire d'avoir une sorte de retour d'état de la sortie de l'IPX.

Non non rien non plus dans le Main du (des) VD.

J'ai pensé à une autre action qui clique sur le VD Eclairage, mais non, j'ai pris soin de désactiver la seule scène qui pouvait le faire. oui en effet c'est ce que j'ai fait pour le VD de notifications. J'ai un autre compte qui a les droit sur ce VD en question.

Bonjour à tous. Je me suis rendu compte d'un comportement étrange avec les icones des VD. Certainement tout bête, mais... J'ai un VD Eclairage qui me pilote une sortie de l'IPX (2 boutons On/Off pour de l'éclairage extérieur) Ce VD à les icones ampoules classiques (allumée et éteinte) associées aux boutons respectifs. Jusque là tout va bien. ça marche très bien. Quand je clique sur ON, la lumière s'allume et l'icone du VD éclairage aussi. C'est du standard, classique, normal quoi... J'utilise un autre VD pour envoyer les notifications (de l'action des sorties de l'IPX) sur mon tél, avec des boutons on/off pour chaque sortie, actionné par une commande push (de l'IPX). (oulà... je sais, ça devient plus compliqué... ça marche très bien... ça m'évite d'avoir 16 scène de notifications... ça c'est depuis que on est passé en login avec adresse mail sur la HC2... l'IPX V3 ne supporte pas ce login dans les paramètres push... on en a déjà discuté... c'est pas le problème...) Mais donc ! Si j'actionne la sortie de l'IPX sans passer par le VD Eclairage de la HC2 (depuis interface IPX par exemple), les icones du VD Eclairage ne changent pas d'état ! (de nouveau logique car j'actionne pas le VD éclairage, on est d'accord ?) Du coup je me suis dit, tient, pourquoi pas utiliser le VD des notifications de l'IPX (je rappelle : actionné par le push des sorties) pour ajouter la commande suivante après la commande de notification : quand l'IPX passe a sortie à ON : fibaro:call(ID_Phone, "sendPush", "Eclairage Ouest Allumé") fibaro:call(ID_VD_Eclairage, "setProperty", "currentIcon", ID_Icone_ON) quand l'IPX passe a sortie à OFF : fibaro:call(ID_Phone, "sendPush", "Eclairage Ouest Eteint") fibaro:call(ID_VD_Eclairage, "setProperty", "currentIcon", ID_Icone_OFF) Et j'ai donc remis, dans le VD éclairage, la bonne vielle icone carré bleu sur les 2 boutons ON/OFF (vu que c'est le VD des notifications qui va lui faire appliquer les bonnes icones) Et ça marche très bien ! à chaque changement de la sortie, j'ai la bonne icone dans le VD éclairage ! ça fait une sorte de retour d'état ! MAIS au bout de quelques minutes (1 ou 2), l'icone du VD Eclairage repasse en carré bleu !!!!!! et beuuuuh pourquoi ?? y a une raison ?? Si vous avez pas tout compris, je peux vous éclairer !! (désolé mais depuis le début j'essaye de la placer celle-la ) merci pour vos lumières !!! (hôplà... encore une )

Oui j'ai le même comportement avec la batterie, je pense que j'ai quand même du me servir du tél hier... Et pour la stabilité, j'ai le même soucis depuis la mise à jour hier soir d'IOS. @nigao : tu as quelle version d'IOS ?

Oui alors je confirme après plusieurs tests que la dernière mise à jour d'IOS 10.3.1 fait planter Media5. J'ai testé avec un simple ping de mon tel avec l'argument /t (en continu) et au bout de 2 ou 3 min après la mise en veille du device, le ping ne répond plus. Plus possible de faire des appels entre les device (iPhone-iPad). C'est embêtant ça ! ça a marché 1 jour. Va falloir espérer que Media5 fasse un correctif également ! Put... de bord... de m... de sal... de conn... de mise à jour de m... !!!!!! désolé... vais me coucher.

Je sais pas je vous ferai un rapport demain soir. Par contre je viens de faire la mise à jour IOS 10.3.1 et j'ai l'impression que Media5 est moins stable d'un coup J'ai des déconnexion quand l'iPhone est en veille !