jjacques68

Il me semble qu'elle n'a pas l'option multi room comme google Home ? Si ? Et si l'on ne passe pas par le Cloud Fibaro, comment cela va se passer ? Il faudrait alors utiliser IFTTT avec Alexa ?

oui j'ai aussi vu mais je crois que je préfère toujours la commande vocal après ça peut se compléter... environnement bruyant...

possible aussi, mais cela va faire beaucoup de connexion à l'IPX pour le contrôle de l'état des sorties. Donc encombrement du réseau et cela peut être éviter...

@jojo j'allais le dire Moi j'ai déjà changé plusieurs piles dans plusieurs FGK et autres, je n'ai jamais eut de problèmes ! J'attends qu'il se réveille tout seul ou je fais un réveil manuel et c'est reparti !

@Nico j'espère que tu a raison @cybersquat ultime solution, reboot de HC2 et IPX

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