jojo

vielle ?

Bon anniversaire cher @Lazer, grâce à qui le mot "domotique" est toujours présent dans le dico.

J'avais essayé depuis le parent et depuis 1 des 4 enfant. Je viens réessayer pour toute la famille, sans succès => je crois que je devrai créer une exception dand GEA : test si ce device est mort, et le réveiller si nécessaire. Et concernant mon autre question, 2nd capture ?

si le module est dans ton bureau (pour test donc), il fait bien le auto-off après 1s ?

A te lire, si j'ai bien compris, tu as 2 problèmes distincts : couverture réseau z-wave : 25 m de la box (qui est dans une baie) c'est trop pour une communication directe. Mais passer via un module volet qui est à 8m (j'imagine en direct et extérieur et que le module volet est alimenté en 220V). Tu peux tenter de refaire un re-maillage de ton réseau z-wave avec les modules à leur place définitive. ordre du auto-off : normalement, il s'agit d'un paramètre du module. Donc, si le module reçoit bien le ON, il n'a plus besoin de connection avec la box pour faire le Off. => je ne comprends pas pourquoi le Off le fonctionne que si la communication avec la box est ok. De plus, en général on met que 0,5sec (donc dans ce délais pas de perte de connexion avec la box)

j'ai un FGS224 qui tombe régulièrement mort. Dans sa config avancée si je clique sur le bouton 'Interroger cet appareil", il revient à lui Je me dis donc que si je change le dropdown juste au dessus par "L'appareil utilise la file d'attente d'interrogation globale", ça devrait faire le job. Mais la nouvelle valeur ne reste pas assez longtemps pour que je puisse sauver la config, elle revient après 3 sec à son ancienne valeur (et ce n'est pas mon browser, j'ai testé avec un autre). Ce problème est peut-être lié à celui-ci : je n'arrive pas à modifier la valeur suivant les recommandations de Fibaro J'ai bien l'icône verte à chaque appuis (donc la box reçoit l'info), mais la valeur revient toujours à sa valeur initiale. Suis-je le seul ?

mon QA chauffage n'exploite pas encore cette API. Il va falloir que je prenne mon courage à 2 mains pour m'y pencher (et comprendre ton code) sérieusement. Quand de je fais du reverse enginering, je ne comptrnds pas local id = event.data and event.data.id j'aurais compris : local id = event.data.id idem pour : --self:debug("Event :", json.encode(event)) il faut que j'essaie pour voir ce que ça donne

su la procédure de reset ne fonctionne pas => échange

d'après la box, j'ai 97 appareils z-wave Actuellement, pour la gestion du chauffage, j'ai de la config dans GEA et dans un QA. Afin de réduire les dépendances, je souhaite tout rammer dans le QA (car il fait déjà ce que GEA ne sait pas facilement faire). Et comme dans GEA j'ai des actions qui ne sont faites qu'en fonction du changement d'état d'un appareil, je crois que le refreshState serait plus approprié, mais je me posait la question car il collectait les changements d'état (en fait, uniquement le changement de la propriété Status ou de n'importe quelle propriété ?) de tous les appareils, ou mon QA ne vérifierait qu'un nombre limité de devices ? La question reste donc ouverte ...

je me pose une question "philosophique" : qu'est-il plus intéressant (performance, fonctionnalit, ....) entre l'API Refresh state programmée à 250 ms un main loop (qui tourne également toutes les 250ms) pour interroger le status d'une liste de devices ?

quelle est la raison réelle de tes économies ? Le divorce ou la domotique ? (j'ai mon idée ...)

tu ne vas pas t'y mettre aussi ? Mais ouf, je suis sauvé, car il est sur pile => non

uniquement si tu en achètes alors que n'en n' pas besoin, ce qui ne sera jamais notre cas ...

idem

On fait confiance à personne, sauf à toi ...

en effet, je n'avait pas osé dire qu'avec SAFARI ça fonctionnait.

j'utilisais ce navigateur sur les conseils d'un ami, car il respecterait plus la vie privée. Il est quand-même sur une base Chrome. Ils m'ont juste proposé une mise à jour qui semble avoir solutionné le problème

bonne nouvelle (pour moi en tous cas) : je ne suis pas complètement fou : C'est mon browser (Brave) qui déconne : erreur similaire avec d'autres pages, et pas l'erreur avec un autre browser.

j'avais bien vu que c'était l'url du navigateur. Et avant de poser la question, j'avais réessayé à plusieurs reprises et même fait un reboot de la box ... Maintenant, je le refaisait (pour essayer de prouver que je suis pas encore complètement sénile, et bien c'est ok ... Je n'y comprends plus rien, sauf que mes doigts ont eux aussi décidé de n'en faire qu'à leur mode ...

bonjour, Suis-je seul, ou est-ce le retour de mes chats noirs ? Lorsque je faits un copy du bout de code d'un QA (exemple : une partie de ma config GEA) h'au ceci dans le presse-papier : http://192.168.xxx.xxx/app/settings/devices/quickapp/edit/167

si tu remplaces ton vieux (qui a 5 ans) par le nouveau modèle à 50% => GO!

en effet, je n'ai pas besoins de l'instantané, donc je vais dans une premier temps développer ma fonction dans le gros LUA de gestion du chauffage où j'aurai une main loop qui tournera toutes les 10 sec. En fait j'ai une partie de la gestion du chauffage sous GEA, et une autre dans un QA LUA, ce qui n'est clairement pas optimal. Et comme maintenant je gère mes période de chauffage via mes Google Calendar, il faut que j'étudie la possibilité d'avoir tout en 100% local si internet était mort... (P.S. ne disions-nous pas avant que les meilleurs sujets étaient ceux qui généraient bcp de HS ?)

autrement, tu peux envoyer un mail avec les infos et peut-être le traiter avec IFFFT ?

en effet, c'est ce que j'avais vu également, pas de retour d'état ... la boucle infinie ou une petite scène qui appelle mon lua : { operator = "any", conditions = { { isTrigger = true, type = "device", id = 344, --id["CHAUF_CIRCUL_RDC"] property = "state", operator = "anyValue", }, { isTrigger = true, type = "device", id = 343, --id["CHAUF_CIRCUL_ETAGE"] property = "state", operator = "anyValue", }, { isTrigger = true, type = "device", id = 157, --id["CHAUF_ECS_RADIATEUR"] property = "state", operator = "anyValue", }, } } hub.call(id["GESTION_CHAUFFAGE"], "ChaudOut") dans, les actions, j'ai pu définir id[] -- IDs générés le : 19/03/23 à 17:55:38 local id = { --Chaufferie PAC_TOTAL_W = 661, CHAUF_ECS_RADIATEUR = 157, CHAUDIERE_SOLAIRE = 269, PAC_BACKUP_A = 675, CHAUF_CIRCUL_RDC = 344, CHAUF_CIRCUL_ETAGE = 343, PAC_A = 667, PAC_AUTH = 263, CHAUF_ECS_PID = 889, CHAUF_CIRCUL_RDC_FGS223 = 706, CHAUF_CIRCUL_ETAGE_FGS223 = 705, SOLAIRE_TMPL = 526, SOLAIRE_PRISE = 534, CHAUDIERE_OUT = 268, SOLAIRE_TMPH = 525, SOLAIRE_POMPE = 517, GESTION_CHAUFFAGE = 177, PAC_BAKCUP_AUTH = 264, TISUN_TMP = 528, } Mais j'aurais bien voulu qqch de similaire dns les déclaration, mais sans succès. Y a-t-il un truc ?