OJC

@gargamel01000 Le retour d'info défectueux ne concerne que l'affichage ou également la propriété 'value' du module ? Ou, autrement dit, est-ce qu'on peut faire varier la luminosité via un code Lua et avoir une information correcte en retour (toujours en code Lua) ?

J'ai pas encore eu le temps de m'y remettre, je ferai ça ce week-end. Niveau mode opératoire, on est d'accord que je commence par brancher le portable tout seul sur la Freebox pour la passer en bridge, et que je ne la branche sur le WAN de l'UGS qu'une fois qu'elle est en bridge ? Pour le transfert du controller, il me semble avoir lu sur le fofo d'Ubiquiti que ça ne marche que si l'adresse IP reste inchangée ?? (bon, ça encore, c'est rien). Merci pour tes tuyaux. PS : sur les DNS j'avais essayé ceux de Free, ceux de Google ainsi qu'OpenDNS, mais le pb ne doit pas venir de là pour ma part... Le fait d'avoir branché l'USG en dernier sur le réseau, après les UAP et le switch (dans l'ordre de livraison en fait ) est plus probablement la cause du problème, doit y avoir un conflit quelque part avec le bouzin de Free qui, comme tout industriel qui se respecte, n'est pas foutu d'implémenter correctement un standard...

Bonsoir Pourquoi le FGD-212 affiche trois modules 'ampoule' dans l'interface de la HC2 (+ le carton et la télécommande, mais ça j'ai compris). Surtout que j'en ai fréquemment un qui reste allumé, avec consommation d'énergie instantanée positive alors que l'ampoule 'physique' est éteinte. A quoi servent les deux modules supplémentaires ? Alors que si j'ai bien suivi le manuel, on ne peut brancher qu'un seul circuit d'éclairage

@pepite déjà s'il fait le job correctement, je serai content... Là, je suis en train d'essayer de le rendre intelligent en adaptant le coefficient utilisé dans la formule de calcul en fonction de l'expérience... Histoire de pas se prendre la tête à les tester soi-même... Le plus délicat, c'est de trouver un moyen de stocker des données dynamiques de manière pérenne, ce qu'un stockage en variable globale ne me semble pas permettre...

En plus, il y a une nouvelle version dans ta signature !!

Nickel, merci beaucoup J'ai repéré une box avec marqué "Rechercher..." dedans en haut à droite des pages du forum... Faudrait peut-être que je voie à m'en servir...

Bonsoir, Est-il possible via un code Lua (scène ou VD) de modifier les paramètres du FGMS ? Je m'explique... J'utilise des FGMS pour récupérer la température à l'intérieur de la maison et gérer les chauffage. Ils sont paramétrés pour remonter la température lorsqu'elle varie de 0,1 °C, et ne jamais rien envoyer sinon. Ce qui est utile pendant la période de chauffe, mais totalement inutile en dehors (je n'ai pas de climatisation). Ce que je voudrais, c'est pouvoir modifier par code ces paramètres à la fin de la période de chauffe pour soulager la pile. Sachant que mes FGMS sont programmés pour se réveiller toutes les 24 heures, ce qui ne pose pas de problème puisque la modification de ces paramètres sera pérenne pendant plusieurs mois.

Bon, voilà un p'tit module virtuel pour se passer des panneaux de chauffage... >> Setpoint Provider for Heating Manager v. 1.3.0.vfib Fonctionnement : Créez une étiquette par panneau de chauffage, dont le nom doit être 'lbl' + le nom de la zone débarrassé des accents, espaces et autres caractères spéciaux Pour définir les températures de consigne, à la fin du Main Loop, juste avant HeatingSetpoint:update(), vous exécutez autant de fois que nécessaire la fonction HeatingSetpoint:add(), en faisant bien attention de respecter au sein de chaque zone un ordre chronologique (le script ne fait pas de tri pour aller plus vite). Il ne vous reste plus qu'à définir ce module virtuel comme source de température de consigne dans le module virtuel d'Heating Manager. Le code du main loop pour @pepite : Et une icône pour la route :

Voilà, publication de la v. 1.3.0. Au menu, il est désormais possible de passer par un module virtuel pour mettre en route ou arrêter le chauffage, et non plus nécessairement par un module 'physique' type Qubino. Egalement, cf. derniers posts, il y désormais trois sources possibles pour la température de consigne : Un panneau de chauffage ; Un module virtuel affichant la température de consigne dans une étiquette ; Une variable globale. Pour la configuration, j'ai mis à jour le premier post, et j'insiste sur le fait que : Dans la scène, la configuration via la fonction HeatingManager:addZone() est exécutée une seule fois au lancement du programme et demeure fixe par la suite tant que la scène n'est pas redémarrée ; Dans le module virtuel, la configuration via les fonctions HeatingPanel sont exécutée à chaque loop, ce qui veut dire qu'avec le jeu des conditions, votre configuration peut évoluer toutes les trois secondes. Concrètement, cela veut dire que si la condition (1) est réalisée, vous pouvez utiliser un panneau de chauffage, sinon si la condition (2) est réalisée, aller chercher la température dans le module ID 220 et l'étiquette soit lblPremiere si la sous-condition (1) est remplie, soit lblDeuxieme si c'est la sous-condition (2) qui est remplie, sinon si la condition (3) est remplie, aller chercher la consigne donc une variable globale, et ajouter ainsi autant de conditions que vous voulez...

@pepite pas de soucis, vos retours et avis sont précieux, ça fait partie de l'intérêt de partager Je préfère seulement ne pas trop m'écarter de l'esprit de départ du programme, qui n'a pas été pensé pour mettre en place le planning de chauffe, mais pour mettre en oeuvre le planning de chauffe. Je suis en train d'apporter la modif évoquée dans mon post précédent, c'est trois fois rien, et ça permet à un autre module virtuel ou une scène via une variable globale de fournir à la consigne à respecter. Le code de @Steven permet de développer facilement un VD ou une scène faisant office de panneau de chauffage. Je verrais pour en faire un générique pour fournir avec Heating Manager.

J'y ai repensé,ce que je vais faire, c'est permettre qu'au moment de la configuration d'une zone, le deuxième paramètre de la fonction HeatingManager:addZone puisse être : soit un panneau de chauffage ; soit l'étiquette d'un module virtuel ; soit une variable globale. Ce qui devrait donc répondre à la plupart des besoins et est assez facile à mettre en place qui plus est ^^ Et merci pour l'appréciation positive

Merci pour ce bout de code Mais je vois toujours pas concrètement l'intérêt d'un VD qui permettrait de faire la même chose que le panneau de chauffage (que ce soit en direct GUI ou via un code Lua) mais avec une interface merdique... Donc, en l'état, je le mets pas dans le cahier des charges

Ben suffit de faire un api.put Parce que gérer un VD avec X boutons en Lua... c'est plus de l'usine à gaz !

Mais si c'est pour la changer de manière pérenne, pourquoi ne pas aller dans le panneau de chauffage ? Vu les possibilités IHM des modules virtuels, ça va être une usine à gaz le truc : > Un label affichant le nom de la zone > deux boutons min. pour faire défiler les zones > Un label affichant le jour de la semaine à modifier > deux boutons min. pour faire défiler les jours > un label affichant l'heure de début de la consigne > quatre boutons pour modifier heures et minutes > un label affichant l'heure de fin de la consigne > quatre boutons pour modifier heures et minutes > un label affichant la nouvelle consigne > deux boutons min. pour fixer la valeur de la consigne > deux boutons, l'un pour annuler les modifications et un pour les valier Oui, fibaro:args() a l'air bien pour ça. Mais le gros problème, c'est d'anticiper un éventuel changement du panneau de chauffage...

L'algo utilisé est déjà fonction de la température extérieure et de la température intérieure. C'est pas le plus difficile. C'est l'implémentation du truc, facile dans les grandes lignes : à chaque exécution du Main Loop, il faut analyser la prochaine tranche de température de consigne, calculer le temps nécessaire pour l'atteindre et, le cas échéant, lancer le chauffage. Ce qui implique de développer la communication entre le module virtuel et la scène, inexistante en réalité pour le moment. Facile sur le papier, et en pratique aussi tant qu'il n'y a qu'un panneau de chauffage à gérer... Mais s'il faut tenir compte du fait que potentiellement dans 30 minutes le panneau de chauffage va changer... ça devient plus acrobatique

Tu veux dire modifier le panneau de chauffage lui-même, de manière pérenne ? Ou juste l'overrider comme en utilisant le mode manuel inclus nativement ?

J'ai mis le code du Main Loop du VD dans un spoiler dans le premier post

Oui, surtout qu'au final, c'est dans le VD qu'il y a le plus gros du programme . J'aurais dû le mettre en spoiler aussi... La température de consigne est bien définie pour chaque pièce (appelée zone dans le programme). Et pour l'algo de l'eedomus, il marche vraiment bien. En revanche, si tu mets une consigne à 22 °C à 7 h dans le panneau de chauffage de la salle de bains, le chauffage démarrera à 7 h jusqu'à atteindre 22 °C. Il ne fera pas 22 °C à 7 h. Je suis en train de regarder comment anticiper la température de consigne pour arriver à ce résultat.

@pepite C'est à dire que le panneau de chauffage utilisé se mette à jour en temps réel en fonction de la réalisation de telle ou telle condition ? C'EST POSSIBLE Supposons qu'il y ait un panneau de chauffage pour les jours où Madame bosse de nuit, et un autre pour celui où elle bosse de jour. Supposons, naturellement, que cette information est enregistrée quelque part, par exemple dans la variable globale horairesMadame : HeatingPanel:addZone("SalledeBains", lib:iif(fibaro:getGlobalValue("horairesMadame") == "nuit", 4, 5) S'il faut tenir compte en plus du week-end ou pas : local horaire = fibaro:getGlobalValue("horairesMadame") local day = ({"Dim","Lun","Mar","Mer","Jeu","Ven","Sam" })[os.date("*t", os.time())["wday"]] local panel = 0 if day = "Sam" or day = "Dim" then panel = 4 elseif horaire = "nuit" then panel = 5 elseif horaire = "jour" then panel = 6 else panel = 7 end if HeatingPanel:addZone("SalledeBains", panel) Et comme ça Madame peut modifier son panneau de chauffage sans avoir à mettre la pagaille les mains dans le code Et @iman, si tu as besoin de définir plus de quatre températures de consigne sur une journée, tu fais deux panneaux de chauffage en divisant la journée en deux et tu déclare comme ça : HeatingManager("Sejour", lib:iif(tonumber(os.date("%H")) > 12, 4, 5) Ainsi, après midi, tu passes sur le deuxième panneau, ce qui te permet de définit huit températures de consignes pour une journée.

@iman Les panneaux de chauffage permettent de définir quatre températures de consigne différentes pour une journée. Je n'ai aucun souci pour ma part. Essaie en mettant un changement à 2 h ou 4 h au lieu de 3 h pour voir ce que ça donne ? Le principe à la base du développement de Heating Manager est précisément d'utiliser les panneaux de chauffage, donc tout le VD est conçu autour de ça. Aller chercher la consigne ailleurs n'est pas en soi impossible, mais il faudrait modifier la structure du programme en profondeur... EDIT = Quoique à la réflexion, c'est peut-être pas si compliqué à gérer en mettant le paramètre panel de HeatingManager:addZone() dans le VD à {ID du VD, ID de l'étiquette contenant la température de consigne} et en réagissant derrière avec type() dans la fonction getSetpoint()... A charge pour toi ensuite de dev un VD faisant office de panneau de chauffage. Je vais regarder ça de plus près ce soir...

@iman alors ça donne quoi avec tes planchers chauffants ? Pour ma part, avec un mélange de radiant et d'inertiel, j'ai la température intérieure qui colle à la température de consigne... Vachement bien pensé l'algorithme de chauffage de l'eedomus !!

Bon, je vais essayer en faisant comme ça. Faut juste que je trouve un créneau pour priver Madame d'Internet Merci pour les infos

Tu parles du dashboard du controller ou de l'USG proprement dit (une seule page pour te dire si tu es connecté à internet ou pas) ? Parce qu'au final, c'est ce que j'ai tenté : oubli de tous les devices dans le controller, reset de l'USG et reconstruction du réseau à partir de celui-ci uniquement, freebox bridge sur le wan et le Lan sur mon pc (sauf que dans cette hypothèse, plus d'accès au controller qui est sur mon serveur et pas sur mon portable (et le serveur n'a pas de serveur X, donc pas possible de bosser dessus directement...) Je n'ai pas changé l'IP de l'USG. Est-il possible que cela entraîne un conflit avec le Freebox ? Normalement pas, mais bon... EDIT : à la réflexion, je peux faire toute la config sur un controller installé sur mon portable, et après je transfère ma config sur le serveur. Si j'ai bien compris, pour que ça marche, il faut juste que l'IP de la machine qui fait tourner le controller reste identique, c'est bien ça ?

C'est pour afficher des logs plus ou moins détaillés = à 1, il te mets tout, à 2 il se contente d'indiquer quand il démarre un radiateur.

J'en doute pas mais pour le quart d'heure, je galère un peu... J'ai mis la freebox en mode bridge, branchée toute seule sur le Wan du routeur, et le switch branché sur Lan. Réseau local opérationnel. Mais pas d'accès internet... Le USG me dire qu'il ne peut pas se connecter à internet Il est configuré en DHCP, et il affiche bien mon ip publique, sur router la même mais sera finissant par 254, le DNS de Free et le subnet mask normal 255.255.255.0... Je trouve pas d'infos... Comment configurer le bouzin pour qu'il fasse son taf de passerelle ?