jjacques68

ça fait combien de temps ? sinon hard reboot... ça m'est déjà arrivé une fois ou deux...

@mprinfo , je me suis fait la même remarque

@Lazer, oui oui tout à fait, je répondais à @idomotique la solution de @Barelle est déjà bien utilisée

attention, ça c'est pas une indirection, tu utilises la propriété "sunriseHour". ça c'est une utilisation classique. Mais par exemple ça, qui est une indirection : local MaVariable = "sunriseHour" fibaro.debug("Scene155", api.get("/settings/info/").MaVariable) ça ne marche pas.

punaise !! Russian !! et bien rebelote ce soir, ce coup-ci pays-bas... Mais je me demande comment ils fond pour arriver depuis le net, sur cette IP locale, sur ce port précis... Le port de la passerelle n'est pas ouvert sur le routeur !!

ben sur le routeur principal, les log ne sont pas activés donc... dommage

hello tout le monde, Par le plus grand des hasard, je me connecte sur mon logiciel (fabrication perso) qui me sert de passerelle entre la HC3 et mon logiciel d'IHM (aussi perso). Et là surprise, je vois cette ligne orange avec cette adresse IP que je ne connais absolument pas : Alors il faut savoir que cette passerelle est un serveur de socket TCP (100 % local). Et que seul les "clients" (toujours locaux), déclarés dans cette passerelle, peuvent s'y connecter. Entre cette passerelle et internet, il y a la box du FAI, mon routeur principale Netgear et l'antivirus du PC !!! Alors comment est-ce possible d'avoir ce genre d'adresse IP venir tenter de s'y connecter ? Il semblerait que ce soit ma pauvre passerelle toute pourrie qui assure sa propre sécurité ????

honnêtement, à part le faire en LUA, je vois pas...

ben si tu n'éteins pas tes lumières elles resteront allumées, et les nouvelles détections ne changerons rien du coup. et tu les fais éteindre à 6h30. EDIT : sinon en LUA, et tu laisse tourner la scène tant que os.time() < 6h30

mouai dans ton cas, c'est un bon exemple. Mais pour des gestion autres, (je pense à de l'éclairage, wifi, ...) ça peut être gênant...

vous parlez de geofencing... je l'ai essayé, ça fonctionne très bien. Sauf que là le rayon de détection minimum d'un point de localisation est de 150m... c'est large, très large... trop large... pas moyen de réduire ce rayon, même directement via l'API, si je rentre autre une valeur plus petite, il ne me l'accepte pas. bien dommage

ah ben ça, si vous lui donnez de la mirabelle avant de partir, c'est le risque...

oui je pense qu'il va falloir ouvrir un topic spécial alsace-lorraine

sinon vous prenez quoi comme groupe ?

chez nous à Cernay, j'ai rien remarqué niveau coupures pour le moment... niveau neige, pareil, 25 à 30 cm et puis 1 ou 2 centimètre en ce moment.

t'es sérieux ???

j'ai quand même relu plusieurs fois ta phrase et bien dit comme ça, c'est claire oui

ça marche très bien le timeout dans l'initialisation de la socket. et toujours en utilisant la fonction readUntil(). Et c'est bien le retour "error" qui est levé. ce qui est un peu bête c'est que le message d'erreur retourné dans le cas d'un timeout est : Operation canceled qui est le même que si y avait une perte de connexion... Donc difficile de faire la différence entre le timeout et une perte de connexion... Je pinaille un peu, parce que je voulais faire marche très bien quand même.

oh punaise j'avais pas pensé à mettre le timeout dans la définition de la socket ! je cherchais à tout pris à le mettre dans la lecture. faut que je teste ça ! merci

Hello tout le monde ! Nouvelle question sur les socket TCP : on connait la fonction readUntil(). Je l'utilise dans toutes mes communications TCP, avec en général le marqueur de fin "\r". Maintenant je souhaite également ajouté un timeout dans la réception de la réponse. Le principe : j'envoie une trame avec send() je déclenche la lecture avec le readUntil() Mais si pas de réponse au bout de x temps, je souhaite renvoyer la trame initiale ! Et c'est là que ça bloque, je ne vois pas du tout comment le faire vu qu'il n'y a pas de notions de timeout dans le readUntil() ... Le readUntil est bloquant, je ne peux rien faire "pendant" ce temps là (genre faire tourner un timer) quelqu'un a une idée ? sans oublié que le tout est asynchrone...

je n'ai plus de HC2 donc je pourrais pas te dire... Ne te fait pas avoir avec le temps de réveil des têtes thermostatique... il se peut qu'il faille attendre plusieurs minutes suivant le moment où la consigne est envoyée ! Chre moi ça peut allé jusqu'à 10 min max...

mouai tu as raison, je vais attendre ...

zut dommage ce module est pas compatible avec V3... Peut être migré un jour en V4... ...

j'ouvre une parenthèse : L'IPX V4 gère le fil pilote ?

merciiiii ! je teste ça ce weekend !