jjacques68

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 !

t'as fait un travail de dingue !! superbe

voilà la trame complète : I=10110000000000000000000000000000& O=00111110000000000000000000000000& A0=0&A1=0&A2=0&A3=0&A4=0&A5=0&A6=0&A7=0&A8=0&A9=0&A10=0&A11=0&A12=0&A13=0&A14=0&A15=0& C1=2093786&C2=8388608&C3=0&C4=0&C5=67108864&C6=58720256&C7=0&C8=8388608

j'ai un vieux souvenir qui traîne dans ma tête... je crois... quand j'avais voulu utilisé cette option, il me semble que ça ne marchait pas. J'avais contacté GCE, et il me semble qu'ils m'avaient envoyé un firmware, ou m'ont fait télécharger sur leur wiki un nouveau firmware. L'IHM avait complètement changé... c'était en mars, pendant le confinement, ou je débutait avec la HC3...

si si elles y sont, c'est juste que j'ai tronqué lors du copié/collé. Mais justement, je serais curieux de savoir ce que ça donne, vu ton explication plus haut. J'imagine que ça doit bombarder sévère sur la socket... Je peux pas le tester, je n'ai rien sur les input analogique.

tout à fait, mais c'est vachement pratique !! bon, la fonction qui extrait les données de la trame reçue, pour mettre à jour les child est vraiment ... "moche" foutu traitement de chaîne de caractères... en lua c'est pfffff

mouai j'ai l'impression à chaque fois que je parle de ça que personne ne voit ce dont je parle voilà ce que j'ai chez moi (V3 !!!) du coup sur le socket je récupère ça : du coup j'ai déclaré aucun retour dans les push des IN/OUT. A chaque changement d'une IN, OUT, COUNTER, ... je reçois cette trame avec les valeurs à jour. Ensuite je mets les child à jours.

Directly, I don't think it's possible. but through a bridge, yes ! (with HC3) I'm sure it's possible with HC2, but HCL... not sure I use this diagram : One QA that get all informations I need ---> Bridge ---> SGBD <--- Web application to retrieve informations The EDI I use to create the bridge is Windev. This EDI has his own SGBD (HFSQL). This SGBD can be use with SQL server with a "connector" (I don't use that) The communication support between HC3 and the Bridge is a socket TCP. I have an another QA to manage this socket. I save in database all informations about : events of devices (value, state, ...) debug messages (debug, warning, trace, error) NotificationCreatedEvent These informations are recovered from the API refreshStates of HC3. The web application is created with Webdev. it's a simply table with some filters.