Lazer

Ouais pas contre, va pas essayer de connecter autre chose qu'une lampe quand il n'y a pas de neutre, même en ayant désactivé le dimmer. Sinon ça va finir comme le module d'un certain Nicolas...

Nous attendons ton retour avec impatience si tu peux t'en procurer un

SELECT answer FROM members WHERE question LIKE '%' AND forum='domotique-fibaro' LIMIT 1

@akrobat, si tu roote, sache que : - tu perds la garantie et le support de Fibaro (sachant que le support logiciel de Fibaro en remote connexion semble être effectif même après la fin de la garantie) - tu ne pourras rien modifier toi même dans le code source, car ce sont soit des binaires compilés, soit des scripts PHP chiffrés. Ils ont bien protégé leur travail.

Steven en bêta, on aura tout vu. Je résisterai, je serai le dernier en v3

Avec le getValue cest parfait, merci

Je me permet de répondre L'idée, c'est d'avoir un système de mesure externe* à la HC2, qui puisse pousser l'information de consommation à la HC2, directement dans le plugin, afin que ce soit pris en compte par le panneau d'énergie de la HC2. * : dans mon cas, ce système de mesure externe est un Raspberry PI associé à une PiFace, avec des compteurs électriques à impulsion dans le tableau électrique. Le Raspberry PI mesure donc la consommation des radiateurs, et met à jour régulièrement la HC2 (mode Push) Au final, grâce à ce plugin qubino fil pilote, on un un seul module, donc une seule icône, qui permet de contrôler le radiateur, et de le mesurer (cela implique qu'il faut cacher le module Qubino initial). En fait, cela permet de palier à l'absence de mesure de consommation native dans ce module Qubino. D'un autre coté, nous aurons le plugin virtual sensor, qui permet de mesurer tout un tas d'autres paramètres de différents équipements (consommation, température, vent, etc...)

oui c'est vrai, beaucoup de prises françaises ne sont pas prévue pour avoir la double compatibilité. Sinon il existe des adaptateurs, mais autant prendre directement le bon Wall Plug. Sur les boutiques françaises, je pense qu'ils sont tous à la norme française. Une mise en garde : il existe de la contrefaçon de ce module, donc attention aux achats dans les boutiques étrangères douteuses.

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"]}})