Lazer

Bienvenue sur le forum

Ouh là là, l'idée est bonne, mais ça me parait bien compliqué. Pourquoi passer par une seconde HC3 ? Tant qu'à doubler les appels à postAPI, je ferai non pas vers une autre HC3, mais directement vers le second serveur NAS. Plus simple à mon avis.

Top, bienvenue sur le forum Le topic en question, où le sujet du changement des piles a souvent été évoqué avec différentes solutions données :

Ici c'est la section intitulée "Nouveau ? Présentez-vous". Je pense que le titre parle de lui-même Pas obligé de faire un roman, mais se présenter en ne serait-ce qu'une ou 2 phrases c'est toujours plus sympathique que de débouler directe avec ses questions... surtout en concluant par " Merci de votre implication " . Car on est sur un forum d'échange, pas le SAV de Darty. Il y a le forum entier et ses différentes sections pour poser les questions, en fonction du sujet abordé. D'ailleurs il y a même un topic dédié à ce module particulier dans la section dédiée aux modules Fibaro.

Je ne sais pas où tu as vu que le bypass était limité en puissance. Mais je ne me suis jamais posé la question, car les endroits où j'ai une très forte puissance lumineuse installée, j'ai toujours le neutre. Et là où je n'ai pas de neutre, donc que le Bypass est nécessaire, j'ai une faible puissance, juste une lampe ou quelques spots. Je peux juste te dire que dans ma salle à manger, j'ai un total de 57 W de LED sans neutre, avec le bypass, et ça ne pose absolument aucun souci.

Tu sais que cette régulation de chauffage basique (= avec hystérésis) la box peut le faire pour toi, dans le panneau de chauffage avec un module lié. Perso je n'utilise pas, mais ça a déjà été décrit sur le forum.

Ah oui le C j'aime bien, c'est vrai qu'on est vite fixé sur notre sort dès qu'on fait une boulette, ça pardonne pas ! Oui sur HC3 tu peux manipuler les cookies, car la librairie net.HTTPClient() te renvoie tous les headers de la réponse, ce qui permet de récupérer les cookies. Et de même, on peut ensuite envoyer les cookies en les positionnant dans les headers de la requête. Voir mon mini tuto, il y a un exemple de définition de quelques headers.

LED qui clignotent, c'est le signe qu'il faut installer le bypass. Idéalement il faut faire un câblage du module avec Neutre également, je ne sais pas si c'est ce que tu as fait. EDIT : pense bien à lancer l'autocalibration également.

Mouais... drôle de présentation

Sinon en Zigbee, mais quid de l'intégration sur HC3 ?

à priori aucun risque, les moteurs Velux embarquent un contrôleur avec butées électronique, même si la tension continue d'être présentée (ce qui est le cas avec le module Qubino pendant 1 seconde) après la fin du mouvement, l'électronique de contrôle ne force pas sur le moteur. Au contraire, ces Qubino Flush Shutter DC sont les meilleurs modules pour cet usage. Avant ça, on devait bricoler, ou utiliser un gros module VRT-IP. Maintenant est-ce qu'il y a d'autres alternatives sur le marché, je ne sais pas. En Z-Wave j'en doute, mais peut être en Zigbee ou Wi-Fi...

Oui il faut virer le télérupteur, il est inutile et ajoute même de la complexité.... le FGD agit lui-même comme un télérupteur en quelque sorte.

Facile, une ampoule pour signaler le jour rouge, tu prends n'importe laquelle et tu l’éteins. Car c'est comme ça qu'elle consomme le moins de kWh

Ah bien

Si tu as bien câblé un FGS-214, c'est un relai, pas un dimmer, donc il n'y a pas de notion de variation / gradation qui entre en jeu. Et effectivement attention au type d'interrupteur mono/bi stable. Cela dit, si je t'ai proposé de testé depuis la box domotique, c'est justement pour t'affranchir des problématiques d'interrupteur.

Bienvenue sur le forum

Tu as inversé les bornes O et S1 O = Output => vers les lampes S1 = Switch 1 => vers l'interrupteur 1 S2 = Switch 2 => vers l'interrupteur 2 EDIT : désolé, n'importe quoi, j'ai regardé trop vite le schéma, faut que j'aille manger Du coup je ne sais pas.... et si tu pilotes depuis la box domotique, ça s'allume ou non ?

Au désolé j'avais pas compris que tu voulais mettre à jour le log, je pensais que tu voulais un label. Perso j'utilise peu le log, car il ne s'affiche que sur l'interface Web, qui n'est que de l'administration dans mon usage. En pratique c'est l'App mobile que j'utilise pour contrôler manuellement ma domotique, donc là le label est utile pour avoir un retour visuel. Et myLabel c'est un exemple de nom pour le label en question.

Il faut utiliser : self:updateView("myLabel", "text", "Hello World") Doc de référence : https://manuals.fibaro.com/home-center-3-quick-apps/

Ah j'avais pas vu. Non il ne faut pas la ré-instancier à chaque appel, il vaut mieux l'instancier une bonne fois pour toute durant la vie du QA, un des meilleurs endroits pour ça c'est dans le onInit() Il y avait une vieille discussion sur ce sujet là quelque part sur le forum.

Non en effet... après tu peux tenter de contacter le support Fibaro, mais sur ce genre de problème très pointu, et surtout aléatoire, je n'ai pas beaucoup d'espoir.

Bienvenue sur le forum

Non je parlais bien au sein du même QA, pas dans des QA différents, car les espaces mémoires sont isolés (process différents au niveau OS Linux) En tout cas chez moi j'ai des dizaines de QA, dont certains qui enchainent les requêtes HTTP, et pas de souci particulier. J'ai juste eu des soucis, notamment avec mon QA Network Monitor, car lui il faisait pleins de requêtes en parallèle vers différents appareils, et ça c'était pas bon du tout.

Ah OK... bon bah du coup c'est très embêtant. Est-ce que par hasard, ça ne serait pas une réponse mal formée par le NAS, qui est envoyée à la box HC3, qui ferait planter le code à l'intérieur de la fonction request() ? On n'a pas vraiment d'outils pour débugger cette étape, mais c'est une piste... Autre chose à savoir aussi : la libraire net.HTTPClient() n'aime pas du tout les requêtes en parallèle, donc assure toi que le code LUA de ton QuickApp effectue bien les requêtes séquentiellement, et jamais 2 en parallèle, c'est à dire en attente de réponses provenant de 2 requêtes distinctes.

En fait, ce que tu dis, c'est qu'avec pcall(), tu arrives bien à attraper l'erreur, et ton script LUA continue son exécution ? Donc si c'est bien ça, alors tout va bien, puisque c'est justement la méthode à employer pour traiter les erreurs pour lesquelles on n'a aucun contrôle.