jjacques68

Alors la... je sèche... t'as pas changé les login de l'IPX ?

D'après ce que j'ai pu comprendre (échange rapide avec @Krikroff Sujet ici), L'API V3 de la HC2 sera vouer disparaître en faveur de la V4. ça change la forme des requêtes HTTP et surtout elles seront en POST et non en GET. Et notre IPX V3 ne fait que du GET les IPX V4 sont ok car on peut choisir GET ou POST. ça c'est ce que j'ai compris.

pour tester dans le navigateur MAIS PAS IE !!! (moi j'utilise Firefox...) : commande HC2 API V3 compatible avec IPX V3 : http://user:mdp@192.168.xx.yy/api/CallAction?deviceID=501&name=turnON le user ne doit pas être le superuser ! chez moi ça marche nickel ! D’ailleurs ça me fait penser, que le jour où l'API V3 de la HC2 disparait, on peut tous jeter notre IPX V3 !!! nan ?? je me trompe ??? Va falloir anticiper le coup !!

et l'IP de l'IPX ? parce que le problème peut peut--être venir de l'autre sens ? HC2 ---> IPX en fait pour tester la communication entre IPX ---> HC2 : au lieu d'actionner une lampe, tu actionnes une scène où tu rajoutes un debug, et tu verras bien si l'IPX communique avec la HC2. pour tester la communication entre HC2 et IPX : tu utilises les VD manuellement...

si tu testes ta commande push de l'IPX directement dans ton navigateur, ça donne quoi ? http://.........../api/CallAction?deviceID=501&name=turnON

oui ok. et dans les paramètres push ? login:pass ? port ? question bête, l'IP de la HC2 n'a pas changé ?

attends là je sais pas si on parle de même chose. Le problème du login c'est dans les paramètres push des entrée/sorties de l'IPX. On peut plus utiliser le superuser de la HC2 car pour l'IPX V3, il n'y a pas assez de caractères possible dans le champs login:pass. C'est pour cela que je parlais de créer un autre user sur la HC2, sans adresse mail comme login. Afin de pouvoir saisir entièrement le couple login:pass. Le %40, permet il me semble de remplacer dans une requête http le @. Sujet déjà abordé sur le forum. Tu utilises quoi comme commandes pour faire communiquer la HC2 et l'IPX ?

On peut le remplacer par %40 je crois... mais jamais testé !

Moi le Bug est apparu dès le passage au fibaro ID... Pour être tranquille, tu crées un user sans @ dans la HC2 (ce ne sera donc pas un superuser), tu lui donnes les droits d'accès au scènes et VD qu'il faut, et tu utilises ce user dans l'ipx.

Si tout marche en commandes locales, ce serait pas ton capteur de mouvement qui ferait des siennes ? S'il n'envoie pas l'info, rien ne s'allume !

Mais tu passes par une scène ? Un VD ?

J'ai eut des soucis également quand le login du superuser de la HC2 est passé à l'adresse mail... C'est quoi exactement ton soucis ?

@pepite : tu peux m'expliquer de nouveau la différence entre : fibaro:sleep(60*1000) ... code ... et setTimeout(function() ... code ..., 60*1000) ???? merciiiiii

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...