Lazer

Merci Krikroff. Juste une remarque en passant : je trouve que les paramètres de la fonction setMode sont inversés (j'aurais trouvé plus logique 1: Arrêt, .... , 6: Confort). Mais bon, puisque ça correspond à la doc, on va laisser comme ça Sinon, serait-il possible d'avoir une fonction équivalente pour lire le statut du module : getMode() ? A moins que ça ne soit accessible avec un classique getValue ?

Merci couillerot, je vais tester ça

Etrange, une procédure de RMA c'est dans le cadre d'un retour garantie. Ce qui signifierait qu'ils prennent en charge sans frais de réparation. Tu devrais poser la question clairement au support Fibaro avant de l'expédier, afin de ne pas avoir de mauvaise surprise (et une box prise en otage au pays de la Vodka). Pour les frais d'expédition, va voir La Poste, c'est peut-être moins cher (et un peu plus long).

En France, c'est Type E, mais le type F devrait fonctionner également (utilisé en Allemagne je crois et d'autres pays d'Europe) :

Bah quand tu vois qu'ils ont supprimé la norme VDI obligatoire, c'est navrant, donc on va revenir aux vieux câbles coaxiaux pour la TV, la prise gigogne en T pour le téléphone, et pas du tout de réseau informatique Pour les ventes en état futur d'achèvement, je crois qu'environ 50% des ventes ce sont des investissements locatifs, donc des propriétaires non occupants, donc ils se moquent pas mal de négocier la prise électrique/réseau/domotique dans la cave et/ou le logement. Le nombre de propriétaires qui doivent faire ce genre de demande doit être très faible. Gazous, tu as de la chance d'être tombé sur un propriétaire qui a eu le bon goà»t de négocier cela à la construction. Mais finalement c'est pareil en maison, si tu ne demande rien à la construction, tu auras le minimum syndical...

Nico, Gazous a du CPL appartement. Mais déjà, rien que d'avoir une ligne électrique entre l'appartement et la cave c'est une chance.

Oui, c'est le principe en théorie, mais je n'ai jamais essayé. Les modules devraient être accessibles de puis la HC2, et donc tous les scripts LUA tournent sur la HC2. Moicphil ou Krikroff ont certainement essayé je pense.

Oui la HC Lite est vraiment faite pour ça. Mais si tu ne veux pas acheter une HC Lite, bien sà»r tu peux mettre une autre HC2 en passerelle

Ouch, le Turbo Pascal j'ai pratiqué il y a très longtemps.... c'était un peu trop strict à mon gout, même si ça ne fait pas de mal. Redémarrer la box ce n'est jamais nécessaire.... (en tout cas, je n'ai personnellement jamais eu besoin depuis 1 an), les seuls reboot sont dus aux mises à jour, ou à mes travaux sur mon installation électrique. Par contre, un virtual device qui plante, ça arrive régulièrement, et avec la méthode que je t'ai donné, c'est fiable à 99,99999% au moins Ca peut aussi planter à cause de son propre code : par ex, on oublie toujours de tester la valeur d'au moins une variable avant de l'employer.

Non mais laisse, Couillerot àdit qu'il allait le faire Sinon je peux aussi le faire, je ne voudrais surtout pas que vous bossiez tous les 2 pour rien.

Je n'ai pas relu le code en détail, d'autres le feraient mieux que moi (Krikroff, Steven, ...) Puisque tu as un sleep de 5 minutes, il n'y aura aucun problème de performance. Le seul risque, c'est le plantage et donc l'arrêt de la main loop. En effet, tu as tout mis dans la main loop (le code principal et les autres fonctions). A la longue (sur plusieurs jours ou semaines), pour une raison ou une autre, un bug peu arriver et à ce moment là la main loop sera complètement stoppée par sécurité par la HC2. Donc tu n'auras plus de chauffage. Ce qui provoque un plantage à coups sà»r c'est l'emploi de Net.FHTTP() puis GET() et json.decode(). Dans le cas présent tu n'utilises pas le json.decode donc le risque semble limité, mais sait-on jamais ce qui peut se produire... Il serait plus sécurisant de mettre tout ton code dans un bouton de ton module virtuel, et ne conserver que ceci dans la main loop : fibaro:call(fibaro:getSelfId(), "pressButton", "1") fibaro:sleep(5*60*1000) PS : le point-virgule est inutile en LUA, donc je te conseille de les enlever (ou de les mettre à toutes les lignes) pour plus de cohérence.

J'ai testé un module Qubino fil-pilote ZMNHJA2 et il est bien reconnu comme un dimmer, et je peux contrôler les 6 ordres de mon radiateur en jouant sur la pourcentage de luminosité du dimmer. Cependant, il y a un message d’erreur "Echec: Obtention des informations multi-canal" qui ne gêne pas le bon fonctionnement du dimmer. Je suppose que ce message est relatif aux entrées associés I1, I2, et I3 car je ne les ai pas vu apparaitre dans l’interface.

Euh Did, tu m'embrouilles, mais comme tu as posté le résultat en cours de rédaction de mon message, maintenant c'est clair

Je n'utilise pas Domoticz, donc je ne sais pas trop de quoi il est capable. Au pire, il doit bien exister des scripts tout fait sur Internet pour récupérer les horaires de lever/coucher du soleil sur Internet.

as-tu attendu minuit afin que la liste des modules se mette àjour ? Sinon, appuie manuellement sur le bouton 4 du module virtuel Graphiques

Le principe de la main loop d'un module virtuel c'est effectivement de boucler automatiquement avec un sleep de 3 secondes. L'idée c'est que si tu effectue tout un tas de vérifications, pour finalement ne rien faire parce que les conditions ne sont pas remplies, alors du as fait travailler le processeur pendant quelques millisecondes pour rien. Multiple ça par le nombre de modules virtuels, et tu fait travailler inutilement la box. C'est pour ça qu'on dit qu'une main loop est gourmande en ressource. A l'opposé, une scène est inactive tant qu'elle n'est pas déclenchée par un événement (trigger). C'est la HC2 qui active la scène uniquement lorsque c'est nécessaire. Attention toutefois, une scène peut aussi comporter une boucle (à programmer soit même, par exemple avec un simple "while true do ....... end" comme le fait GEA de Steven ou d'autres scènes). A ce moment là , on en revient au principe de fonctionnement d'une main loop de module virtuel. Le truc c'est qu'il y a des situations où on ne peut pas faire autrement que d'avoir une boucle infinie, que ce soit dans un main loop ou une scène. Par exemple : de nombreuses variables à gérer, dont on doit conserver la valeur d'un passage à un autre dans le code... Il serait trop fastidieux de stocker tout ça en variables globales. Il n'y a donc pas d'autres choix que d'utiliser ces fameuses boucles, et on doit alors coder intelligemment pour éviter de surcharger le processeur. Par exemples : éviter de conserver le sleep(3000) si un sleep(60000) est suffisant, essayer de limiter les tâches à effectuer à chaque passage dans la boucle, éviter de faire appel à des fonctions buggées (Net.FHTTP suivi de json.decode) Après il faut relativiser, un programme correctement écrit ne dure pas plus de quelques millisecondes, donc c'est négligeable, et ce n'est pas çà qui va fatiguer la HC2, qui est relativement puissante. L'exemple du script GEA est un bon exemple de la complexité possible tout en conservant d'excellente performances. Les différents modules virtuels de Krikroff également. Dans ton exemple de panneau de chauffage, tu n'as pas d'autre choix que de faire appel à l'API, donc utilisation des fonctions Net.FHTTP() et json.decode()... et cela plantera forcément au bout de quelques passages dans la boucle. La solution est donc de mettre ta routine principale dans un bouton d'un module virtuel, et la main loop se chargera d'appeler le bouton à intervalle régulier.

Fredo, tu rappliques immédiatement dès qu'on parle de concours toi GEA.add(id["CONCOURS"], -1, "Alerte concours", {{"turnOn", id["FREDO"]}})

Steven, content de te revoir Et j'adore ton nouvel avatar Couillerot, excellent le volet en bois, est-ce que tu pourrais me faire une petite variante : une fenêtre avec un seul battant ? Ou tu files le PSD et je me débrouille tout seul.

ah oui c'est vrai dans une scène ce n'est pas supporté. Plus simple : depuis la scène, tu peux directement cliquer sur le bouton d'un module virtuel, ce qui évite de créer une variable globale inutilement, évite une boucle dans un module virtuel qui tourne en rond pour pas grand chose, et surtout permet une réactivité immédiate : fibaro:call(<id>, "pressButton", "1")

Essaye comme ça : HC2 = Net.FHttp("192.168.1.3", 8081) Tu es en v4.018 ? Si ça ne fonctionne pas, c'est que la fonction est supprimée de cette version comme je le disais.

C'est le détecteur qui fait la détection.... Je comprends pas ta question ?

Twist oui j'avais également pensé àfaire comme ça , il est probable que je finisse par modifier le câblage. Le souci du détecteur sur S1, c'est que la plupart des détecteurs ont une durée minimale d'éclairage de quelques secondes, donc ne permettent pas d'utiliser le mode monostable du dimmer. Avec ta solution sur S2 c'est plus souple au niveau scénarios.

Perso j'utilise le même détecteur de mouvement (acheté chez LM) sur un Dimmer FGD. J'avais mis le schéma de montage et les explications quelque part sur le forum.... Voici déjà le schéma, et pour les explications je crois que c'était sur le sujet du Dimmer justement.

Oui Gazous, moi aussi j'avais compris que le module lis la valeur en local quand il doit décider ou non de déclencher un module associé, et ceci indépendamment du paramètres n°40 (ILLUMINATION REPORT THRESHOLD) Plus précisément, ce n'est même pas l'association d'un module qui compte, mais le fait qu'il décide ou non de détecter un mouvement grâce au paramètre n°8 "PIR SENSOR OPERATING MODE". A partir du moment où tu configures "2 - PIR sensor active during the night only.", alors la valeur choisie dans le paramètre n°9 "NIGHT / DAY" va entrer en compte, et ceci indépendamment du paramètre n°40. Donc par extension, dans la HC2, tu n'as même pas besoin d'avoir une valeur de luminosité à jour, puisque le module enverra bien l'info de détection de mouvement à la box lorsqu'il fait suffisamment nuit (en réalité, la box est associée systématiquement au module, c'est comme ça qu'elle reçoit les infos)

ok merci, je verrai si je peux souder, si c'est accessible (le tamper est bien visible sur le dos, mais beaucoup moins sur la face avant.