Lazer

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.

ça tient bien dans le temps la gaine thermo, surtout avec les variations de température ? et il faudra trouver une solution pour appuyer sur le tamper interne, avec genre une micro-cale en bois. Du coup je peux aussi visser une petite plaque en bois à l'arrière pour faire appui. on parle de détecteur d'alarme là , vous me connaissez, il me faut un truc fiable à 100%.

en fait, j'ai 2 capteurs dans la même situation (dans mes 2 détecteurs de mouvement extérieurs Diagral). L'un provient de Orange, l'autre d'un revendeur de domotique connu, mais ils sont strictement identiques (firmware, numéro de révision, ...) Celui d'Orange vient de perdre la garantie car je devais faire sauter le boitier plastique pour des questions d'encombrement. Donc à la limite je peux le souder... Les permuter ne me servira à rien, car ils ont le même comportement à partir du moment où les 2 boutons tamper ne sont pas enfoncés simultanément (intérieur et arrière). Je ne vois pas quel genre de collier je peux utiliser, qui tienne sans bouger (l'hiver -15°C, l'été facilement 45°C en plein soleil)

inertie fluide, parfait Je te conseille donc : - 1 module Qubino Fil Pilote, qui permet de piloter les 6 ordres du radiateurs en se basant sur le thermostat intégré du radiateur - en option, 1 thermostat Secure SRT321, qui sera capable de piloter le module Qubino avec 2 ordres seulement : Confort et Arrêt/délestage. Donc tu règles le thermostat intégré du radiateur sur une valeur supérieure au désiré que tu n'atteindra normalement jamais (par exemple 25°C), et c'est le SRT321 qui fera la régulation de température. Il est très précis (algorithme PID), et surtout il est compatible avec le panneau de chauffage de la HC2/HCL, donc pour la programmation horaire au demi-degré près c'est tip top.

Hier, installation d'un second détecteur. Comme il est orienté différemment (moins d'angle), il y a moins de place derrière celui-ci pour y glisser le FGK. J'ai été obligé de sortir le FGK de son boîtier en plastique (face avant et arrière) : A noter que pour retirer la face arrière, il faut faire sauter l'espèce de collier battu en plastique moulé qui retient le PCB (un coup de forêt 2 ou 3mm suffit, mais adieu la garantie). Pour la petit histoire, c'était le capteur de ma box Homelive Par contre maintenant j'ai un nouveau problème, car à cause du bouton Tamper qui n'est pas enfoncé, le module se met en alerte (breach) dans la HC2.

le scotch, j'y ai pensé, mais comme les 2 capteurs sont dehors (à l'abri de la pluie, mais pas du froid), ça ne va pas tenir. j'ai bien pensé à la colle et à souder, mais plus de garantie. Edit : c'est quand même bizarre que Fibaro n'ai pas pensé à ce genre de situation.

J'ai un souci. J'ai 2 FGK, que je n'utilise que pour contact sec sur les bornes GND et IN. Le souci, c'est que comme ils ne sont pas fixés sur une surface, le bouton Tamper à l'arrière n'est pas enfoncé, et ils se mettent en alerte (Breach) dans l'interface de la HC2. Pourtant, quand mes détecteurs du mouvement ferment le contact sec, la diode bleue s'allume bien, donc il détecte bien cette entrée. Mais vue de la HC2, ça ne change rien. Il y a un moyen d'utiliser ces FGK en ignorant le tamper ? J'ai cherché dans la doc et un peu sur Internet, je n'ai rien trouvé.

Merci Steven, j'ai honte, c'était bien ça. Tout fonctionne maintenant. Et dire que j'ai testé plein de trucs hier soir pendant 2h sans voir l'oubli du "If" en majuscule.

Oui et non. Comme beaucoup, j'ai ouvert un port pour accéder directement à ma box sans passer par le cloud Fibaro. Donc le serveur Web est exposé (mais filtré derrière mon reverse proxy, et en plus il faut connaitre l'URL complète, donc ça limite pas mal). En ce qui concerne le tunnel, un simple script permet de récupérer des centaines/milliers d'adresses IP de possesseurs de HC2 en quelques heures. Le jour où un mec arrive à rentrer sur les serveurs de Fibaro, avec cette liste d'IP il n'a plus qu'à remonter tous les tunnels. Et même sans hacker leurs serveurs, avec la liste des IP récupérées précédemment, il est facile de scanner les ports, il y a probablement 50% de gens qui font du port forwarding. Reste à trouver une faille sur Apache (ou tester le compte admin/password... juste au cas où)