Message populaire OJC Posté(e) le 29 octobre 2017 Message populaire Signaler Posté(e) le 29 octobre 2017 (modifié) HEATING MANAGER v. 3.1.2 - 16/12//2017 Heating Manager est un programme permettant d'utiliser le Home Center 2 pour gérer avec une grande souplesse le chauffage d'une habitation, en permettant de franchir une étape supplémentaires dans la gestion de celui-ci. En effet, s'il est parfaitement capable de fonctionner en suivant une planification, Heating Manager permet de passer à l'étape suivante et d'exploiter pleinement les potentialités de la domotique en se passant totalement de planification et en gérant le chauffage sur une base événementielle exclusivement dynamique. Heating Manager, qui propose de réguler le chauffage sur un mode proportionnel avec prise en compte des déperditions (Ubat) ou sur un mode classique avec hystérésis, est compatible avec n'importe quel système de commande de chauffage, y compris des modules virtuels. Il peut fonctionner en tout ou partie en mode planification via l'utilisation des panneaux de chauffage natifs du Home Center 2, de modules dédiés ou de variables globales. En mode événementiel, il peut s'appuyer sur n'importe quelle propriété de n'importe quel module, virtuel ou non, ainsi que sur des variables globales. L'utilisation de boucles conditionnelles dans la configuration permet en outre de faire varier cette configuration en fonction de n'importe quelle condition. Ces développements doivent beaucoup aux échanges stimulants intervenus sur ce fil de discussion, qui m'ont amené à aller bien plus loin que ce qui était prévu au départ, à savoir simplement pouvoir utiliser les panneaux de chauffage avec les modules fils pilote proposés par Qubino... Que tous soient remerciés , ainsi que ceux qui relèvent des bugs et permettent d'améliorer le script. _ _ _ PRE-REQUIS Ce programme a été conçu et testé sur le Home Center 2 tournant avec le firmware v. 4.140. Il ne requiert aucun matériel particulier et peut s'adapter facilement à toutes les configurations. _ _ _ INSTALLATION 1. Pour une utilisation en tout ou partie en mode planification, il faut commencer par définir les plannings de chauffe souhaités. La première étape dans cette optique de fonctionnement est de définir un planning de chauffe dans lequel Heating Manager ira chercher la température de consigne à atteindre. Ce planning de chauffe peut être mis en place en utilisant les panneaux de chauffage fournis nativement par le Home Center 2. Attention cependant, un bug a été constaté, évoqué dans ce fil, entraînant l'absence de prise en compte du changement de température de consigne après minuit. Il peut également être mis en place en utilisant n'importe quel module virtuel ou bien celui, basique, fourni avec Heating Manager >>>> Heating_Provider.vfib Pour utiliser ce module virtuel, il faut adapter la configuration donnée en exemple à votre cas en modifiant, et en ajoutant le cas échéant, les étiquettes, chaque étiquette correspondant à une zone de chauffage. La définition du planning de chauffe pour chacun de ces zones intervient dans le main loop du module virtuel, dans la partie Configuration : HeatingManager:add(zone, day, time, temperature) zone correspond au nom d''une étiquette du module virtuel day est soit un ou plusieurs jours de la semaine (en anglais e.g. {"monday","friday"}), soit "weekday" (du lundi au vendredi), soit "weekend", soit "week" time est l''heure à laquelle la température de consigne devra être appliquée "hh:mm" temperature est la température de consigne devant être appliquée à compter de l''horaire défini juste avant Il est important que la construction du planning de chauffe soit faite de manière chronologique, le module virtuel ne faisant pas de tri chronologique, ce qui peut entraîner un comportement s'écartant de celui attendu. 2. Pour une utilisation en tout ou partie en mode événementiel, il faut importer un thermostat par pièce concernée >>>> Thermostat.vfib Ce module virtuel permet de définir la température de consigne (mode Confort et mode Economique) pour la pièce, de forcer l'un de ces deux modes ou de passer en mode manuel avec un minuteur permettant de retourner au mode automatique. Les ordres donnés par l'intermédiaire de ce module viruel l'emportent sur toute autre évènement défini dans la configuration de Heating Manager. Il faut juste mettre un module virtuel dans chaque pièce. Sa détection par Heating Manager se fait automatiquement. 3. [OPTIONNEL] Pour afficher de manière centralisée les températures de consigne en cours, il faut installer le module virtuel Heating Viewer >>>> Heating_Viewer.vfib Pour le bon fonctionnement de ce module, chaque pièce dont le chauffage est géré par Heating Manager doit avoir une étiquette, dont l'ID doit être le nom de cette pièce débarrassé de tous les accents, espaces et autres caractères exotiques. Ainsi, pour la pièce "Séjour Principal #1", l'ID de l'étiquette doit être "SejourPrincipal1". Les étiquettes inutilisées peuvent être supprimées, tout comme il peut être ajouté autant d'étiquettes que nécessaire. 4. Création d'une scène en mode Lua avec copier-coller du code >>>> Heating Manager - Scène.lua La configuration de Heating Manager est réalisée par l'exécution de neuf fonctions différentes à paramétrer dans la partie USER CONFIGURATION ZONE qui se trouve à partir de la ligne 100 du code. self:setConfiguration(checkConfig, oldLastTempUpdate, logInfo, pushWarnErrLog, pushTo, popupWarnErrLog, logMemory) checkConfig est un booléen dont la valeur par défaut est true, qui permet de définir si Heating Manager doit contrôler de manière approfondie la configuration (existence des pièces, des modules, des propriétés de modules, des variables globales, etc.) Une fois que votre configuration est rodée et fonctionne sans problème, vous pouvez passer ce paramètre à false. oldLastTempUpdate est un nombre dont la valeur par défaut est 180 et qui est le nombre de minutes depuis la dernière remontée de température d'une sonde intérieure au-delà duquel Heating Manager adressera un message d'alerte et arrêtera la chauffe. logInfo est un booléen dont la valeur par défaut est true et qui permet de définir si l'intégralité des messages doit s'afficher dans la fenêtre de debug, ou uniquement les plus importants (action, survenance d'un événement, changement de la température de consigne). pushWarnErrLog est un booléen dont la valeur par défaut est false et qui permet de définir si les messages d'alerte et d'erreur doivent faire l'objet d'une notification Push. pushTo est une table contenant l'ID des téléphones mobiles auxquels envoyer les notification Push si le paramètre précédent est à true. popupWarnErrLog est un booléen dont la valeur par défaut est false et qui permet de définir si les messages d'alerte et d'erreur doivent faire l'objet d'une notification dans le centre de notification du Home Center 2. logMemory est un booléen dont la valeur par défaut est true et qui permet d'afficher dans la fenêtre de debug, toutes les cinq minutes, la mémoire utilisée par Heating Manager. self:setProportionalMode(default_kP, auto_kP, default_kT, cycle, minCycle, defaultSetpoint) Cette fonction ne doit être utilisée que si vous souhaitez utiliser le mode de régulation proportionnel. default_kP est un nombre dont la valeur par défaut est 60 et qui est le coefficient proportionnel utilisé par Heating Manager dans le cadre de la régulation proportionnelle si aucun coefficient particulier n'est défini pour un radiateur donné. auto_kP est un booléen dont la valeur par défaut est true et qui permet de définir si Heating Manager doit adapter le coefficient proportionnel en fonction de l'expérience acquise lors des cycles de chauffe. default_kT est un nombre dont la valeur par défaut est 1 et qui est le coefficient de déperditions thermiques (Ubat) utilisé par Heating Manager dans le cadre de la régulation proportionnelle si aucun coefficient particulier n'est défini pour un radiateur donné. La valeur 1 correspond à une maison bien isolée. Pour un bâtiment mal isolé, ce coefficient peut être fixé à 3. cycle est un nombre dont la valeur par défaut est 15 et qui est la durée d'un cycle de chauffage en minutes, au sein duquel s'insère la période de chauffe calculée par Heating Manager. minCycle est un nombre dont la valeur par défaut est 1 et qui est la durée minimale en minutes d'une période de chauffe. defaultSetpoint est soit comfort, soit eco (sans guillemets) et permet de déterminer, uniquement pour un fonctionnement en mode événementiel, si la consigne à appliquer en dehors de tout événement est la température de confort définie dans le thermostat virtuel ou la température économique. La valeur par défaut est comfort. self:setHysteresisMode(hysteresis, cycle, defaultSetpoint) Cette fonction ne doit être utilisée que si vous souhaitez utiliser le mode de régulation par hystérésis. hysteresis est un nombre dont la valeur par défaut est 0 et qui est l'écart en degré entre la température courante et la température de consigne au-delà ou en-deça duquel le chauffage sera démarré. cycle est un nombre dont la valeur par défaut est 15 et qui est l'intervalle en minutes entre deux comparaisons de la température courante et de la température de consigne. defaultSetpoint est soit comfort, soit eco (sans guillemets) et permet de déterminer, uniquement pour un fonctionnement en mode événementiel, si la consigne à appliquer en dehors de tout événement est la température de confort définie dans le thermostat virtuel ou la température économique. La valeur par défaut est comfort. self:setEventDefaults(eCumulative, eSetpoint, eDuration, eStep, ePersistence) eCumulative est un booléen dont la valeur par défaut est true et qui permet de définir si les conditions d'un événement doivent toutes être réalisés pour que l'événement soit considéré comme survenu, ou si la réalisation d'une seule condition est suffisante. Il s'agit ici de définir la valeur par défaut qui sera utilisée à défaut de paramétrage contraire lors du paramétrage de chaque événement. eSetpoint est un nombre dont la valeur par défaut est 18 et qui permet de définir la température de consigne qui sera appliquée par défaut en cas de survenance d'un événement lorsqu'aucune température de consigne propre n'est définie lors du paramétrage de l'événement. eDuration est un nombre dont la valeur par défaut est 0 et qui permet de définir la durée en minutes devant s'écouler entre la survenance de l'événement et l'application de la température de consigne correspondante, permettant ainsi de prévoir une diminution ou une augmentation graduelle de la température de consigne. eStep est un nombre dont la valeur par défaut est 0.5 et qui permet de définir les étapes de diminution ou d'augmentation graduelle de la température de consigne. ePersistence est un nombre dont la valeur par défaut est 0 et qui permet de définir la durée par défaut pendant laquelle Heating Manager continuera à considérer qu'un événement est réalisé à partir de l'instant où les conditions de sa réalisation ne sont plus remplies. Si les conditions sont à nouveau remplies pendant le délai de persistence, Heating Manager agira comme si elles n'avaient jamais cessé d'être remplies. self:addHeater(idRoom, idHeater, idSonde, localkP, localkT) Cette fonction permet de déclarer les radiateurs qui seront gérés par Heating Manager. La fonction doit être paramétrée pour chaque radiateur. idRoom est l'ID de la pièce définie dans le Home Center 2 dans laquelle se trouve le module de commande du radiateur. idHeater désigne un module de commande d'un radiateur sous forme de table {ID du module, instruction pour mise en route, instruction pour arrêt, valeur à l'arrêt} : ID du module est l'ID d'un module, virtuel ou non, permettant de commander la mise en route ou l'arrêt du chauffage. instruction pour mise en route est soit la commande à transmettre s'il s'agit d'un module 'réel' ("turnOn" par exemple), soit le numéro d'ordre du bouton d'un module virtuel. instruction pour arrêt est soit la commande à transmettre s'il s'agit d'un module 'réel' ("turnOff" par exemple), soit le numéro d'ordre du bouton d'un module virtuel. valeur à l'arrêt est la valeur de la propriété value lorsque le radiateur est arrêté, et est utilisé pour éviter d'envoyer les commandes de mise en route et d'arrêt inutilement. idSonde désigne une sonde de température qui peut être définie spécifiquement pour un radiateur s'il n'est pas asservi à la sonde de température principale de la pièce définie dans le Home Center 2. Il peut s'agir d'une sonde de température proprement dite ou d'un module virtuel et sera dans tous les cas sous la forme {ID du module, nom de la propriété contenant la température}. Il peut également s'agir du nom d'une variable globale dans laquelle est stockée la température. localkP permet de définir un coefficient proportionnel fixe qui sera utilisé pour calculer la commande de chauffe de ce radiateur. localkT permet de définir un coefficient de déperditions thermiques qui sera utilisé pour calculer la commande de chauffe de ce radiateur. self:addEvent(idRoom, idEvent, conditions, cumulative, setpoint, duration, persistence) Cette fonction permet de définir les événements qui entraîneront une modification de la température de consigne (ouverture d'une fenêtre, absence temporaire ou prolongée, lumière allumée ou éteinte...). idRoom est l'ID de la pièce concernée par l'événement, ou une table contenant les IDs de plusieurs pièces concernées par l'événement. idEvent est le nom de l'événement, qui sera affiché dans la fenêtre de debug lors de sa survenance. conditions est une table contenant les différentes conditions devant être réalisées, ensemble ou séparément, pour que l'événement soit considéré comme survenu et la température de consigne modifiée en conséquence. Cette table contient elle-même une table par condition (il y a donc forcément une double accolade au début et à la fin), sous la forme {nom de variable globale, opérateur ("==", "~=", ">=", "<=", ">", "<"), valeur à vérifier, durée en minutes devant s'être écoulée depuis que le résultat de la comparaison est vrai} ou {ID d'un module, nom de la propriété d'un module, opérateur ("==", "~=", ">=", "<=", ">", "<"), valeur à vérifier, durée en minutes devant s'être écoulée depuis que le résultat de la comparaison est vrai}. cumulative est un booléen permet de définir, pour cet événement particulier, si sa survenance implique la réalisation de toutes les conditions ou si une seule est suffisante. setpoint permet de définir la température de consigne devant être appliquée lorsque l'événement survient. Dans le cadre du mode de fonctionnement événementiel, vous pouvez utiliser les variables comfort et eco qui font références aux températures définies pour la pièce avec le module virtuel Thermostat. duration est la durée en minutes devant s'écouler entre la survenance de l'événement et l'application de la température de consigne correspondante, permettant ainsi de prévoir une diminution ou une augmentation graduelle de la température de consigne. persistence est un nombre qui permet de définir la durée pendant laquelle Heating Manager continuera à considérer que l'événement est réalisé à partir de l'instant où les conditions de sa réalisation ne sont plus remplies. Si les conditions sont à nouveau remplies pendant le délai de persistence, Heating Manager agira comme si elles n'avaient jamais cessé d'être remplies. Dans le cadre de la configuration, cette fonction peut s'insérer dans une boucle conditionnelle permettant de ne laisser l'événement se réaliser que sous des conditions précises, par exemple d'horaires. self:addGlobalEvent(idEvent, conditions, cumulative, setpoint, duration, persistence) Cette fonction permet de définir un événement s'appliquant à toutes les pièces dont le chauffage est géré par Heating Manager, et se configure exactement de la même manière que la précédente, le paramètre idRoom en moins. Attention : le fait que l'événement soit global ne signifie pas qu'il l'emporte sur les événements spécifiques d'une pièce. Heating Manager contrôle les événements les uns à la suite des autres pour chaque pièce, dans l'ordre de leur configuration. Dès que les conditions d'un événement sont remplies, le programme cesse la boucle et n'analyse pas les autres événements déclarés. self:setIndoorSonde(idRoom, idSonde) Cette fonction permet de définir la sonde de température d'une pièce si vous ne souhaitez pas utiliser la sonde de température principale définie dans le Home Center 2. idRoom est l'ID de la pièce concernée. idSonde désigne une sonde de température proprement dite ou un module virtuel et sera dans tous les cas sous la forme {ID du module, nom de la propriété contenant la température}. Il peut également s'agir du nom d'une variable globale dans laquelle est stockée la température. self:setSetpoint(idRoom, idSetpoint) Cette fonction permet de définir, pour une pièce donnée, la source de la température de consigne qui devra être appliquée. L'utilisation de cette fonction n'est requise que dans le cas de l'utilisation du mode planification, et est inutile lorsque le chauffage de la pièce est effectué selon le mode événementiel. idRoom est l'ID de la pièce concernée. idSetpoint désigne la source de la température de consigne et peut être : l'ID d'un panneau de chauffage natif du Home Center 2. une table sous la forme {ID du module, propriété du module contenant la température de consigne} s'il s'agit d'un module, virtuel ou non. le nom d'une variable globale qui contiendra la température de consigne. self:setOutdoorSonde(idSonde) Cette fonction permet définir une sonde de température extérieure. Elle n'est utilise que dans le cas de la régulation proportionnelle qui tient compte de la température extérieure, et est inutile pour une régulation à base d'hystérésis. idSonde désigne une sonde de température proprement dite ou un module virtuel et sera dans tous les cas sous la forme {ID du module, nom de la propriété contenant la température}. Lorsqu'aucune sonde de température extérieure n'est définie et que le mode de régulation proportionnel est utilisé, Heating Manager utilise la température fournie par le plugin Météo. 5. Mise à jour depuis une version précédente Cette nouvelle version apporte des modifications en profondeur du programme et de la manière de le configurer. Il n'est donc pas possible de faire simplement un copier-coller de la configuration d'une version précédente à la 3.0, qui était éclatée entre la scène et un module virtuel, mais il est nécessaire de reprendre la configuration depuis le départ. Depuis la version 3.0, il est impératif de modifier les fonctions self:addEvent pour ajouter dans les conditions le paramètre operator : "==", "~=", ">=", "<=", ">" ou "<". Si le contrôle de configuration est activé, un message d'erreur s'affichera dans la fenêtre de debug sans faire planter le programme. L'ajout du paramètre ePersistence dans la fonction self:setConfiguration et persistent dans les fonctions self:addEvent n'est pas indispensable puisqu'il s'agit du dernier paramètre de ces fonctions. A défaut de les ajouter, c'est la valeur par défaut (0) qui s'appliquera. _ _ _ ROADMAP [VIDE] _ _ _ ICONES Modifié le 23 mars 2018 par OJC Renvoi des fichiers vfib et lua 3 1 7
pepite Posté(e) le 29 octobre 2017 Signaler Posté(e) le 29 octobre 2017 Bonsoir, On ne t'arrete plus ;-) Bravo, sympa, gros boulot ;-)
OJC Posté(e) le 29 octobre 2017 Auteur Signaler Posté(e) le 29 octobre 2017 @pepite Merci ! Faut bien que je refasse mon installation... Je suis en train d'implémenter la gestion des absences via le détecteur de mouvement... 1
OJC Posté(e) le 1 novembre 2017 Auteur Signaler Posté(e) le 1 novembre 2017 Voilà la version 1.1.0, avec la gestion des absences et un code revu de fond en comble . Maintenant, j'attaque la gestion du PID proprement dit !! 1
Steven Posté(e) le 1 novembre 2017 Signaler Posté(e) le 1 novembre 2017 Encore une excellente initiative ... Bravo. Juste encore une remarque ... j'insiste ... sur la manière d'aller récupérer le VD. Ta méthode getDeviceIDbyName parcours tous les devices afin de trouver le bon alors qu'il te suffirait de faire ainsi : function getDeviceIDbyName(deviceName) local device = api.get("/devices?name="..deviceName.."&enabled=true&visible=true") if (device) then return device.id end log("Critical Error : Virtual Device Dawn & Dusk Panel not found !","Tomato",true) fibaro:abort() end C'est juste un peu plus performant. Sinon, il existe : fibaro:getRoomNameByDeviceID(id_du_device) D'ailleurs ... ne serait-ce pas un copier/coller restant "Critical Error : Virtual Device Dawn & Dusk Panel not found !" Je me permet ces petits commentaires car vu le niveau de ton code, manque pas grand chose pour qu'il soit parfait
Steven Posté(e) le 1 novembre 2017 Signaler Posté(e) le 1 novembre 2017 Lol, oublie mon message, je l'ai posté pile poil avant ta révision de code.
pepite Posté(e) le 2 novembre 2017 Signaler Posté(e) le 2 novembre 2017 (modifié) Eh ben, belle optimisation ;-) J'ai pas importé le VD, mais est-il possible de passer le panneau de chauffage en mode manuel ou en mode vacances et inversement depuis le VD ? ou Simple suggestion, enfin question Et si la sonde de temperature est une sonde hors HC2 ? ;-) Modifié le 2 novembre 2017 par pepite
OJC Posté(e) le 2 novembre 2017 Auteur Signaler Posté(e) le 2 novembre 2017 (modifié) Merci Je n'ai pas prévu de pouvoir passer le panneau de chauffage en mode manuel ou vacances depuis le Module Virtuel puisqu'on peut le faire facilement depuis l'app Android ou iOS. Même si ce ne doit pas être bien compliqué à rajouter, je n'en vois pas trop l'intérêt, du coup... En l'état, le programme ne fonctionne qu'avec une sonde de température ZWave présente comme module dans la HC2. Mais ce n'est pas très compliqué non plus de rajouter une option pour qu'il aille la chercher ailleurs que dans le value d'un module (ou qu'il le comprenne tout seul en fonction du paramétrage de la sonde), à condition cependant qu'elle soit enregistrée quelque part dans la HC2... Parce que préconfigurer le programme en fonction de toutes les API des box/sondes les plus courantes... Outre le fait que je n'en ai pas l'utilité, ça va vite devenir indigeste ! Le plus simple serait d'envisager deux cas : > La température est stockée dans un Module Virtuel, donc il suffit de connaître l'ID du module et celui de l'étiquette pour avoir une sonde 'virtuelle' > La température est stockée dans une Variable Globale, il suffit de connaître le nom (voire plus si les températures sont stockées sous forme de table 'jsonée' Comment font ceux qui utilisent des sondes non ZWave ? Plutôt Module Virtuel ou plutôt Variable Globale ? Modifié le 2 novembre 2017 par OJC
pepite Posté(e) le 2 novembre 2017 Signaler Posté(e) le 2 novembre 2017 Pour ce qui est du passage en mode vacances ou manuel, l'intérêt est de pouvoir à partir d'une autre scène ouautre VD qui gere ton absence de pouvoir aller cliquer sur le bouton automatiquement en fonction des conditions ;-) Exemple : avec GEA, je pars en vacances ou en WE pendant la periode hivernale, en fonction des conditions, j'appuie sur le bouton vacances, lorsque je reviens, j'appuie sur le bouton ON ;-).... J'ai des invités..je passe en manuel ;-) Pour les sondes exterieures, je dirais : - VD + VG avec affchage des valeurs dans les etiquettes - VD + affichage des valeurs directement dans les étiquettes, les étiquettes ayant la même étendue que les Variables globales en moins risqué ;-)
OJC Posté(e) le 2 novembre 2017 Auteur Signaler Posté(e) le 2 novembre 2017 (modifié) Sur le premier point, j'ai prévu de faire le pendant de la gestion d'absence en permettant d'overrider la température de consigne du panneau de chauffage en cas de présence dans la pièce, soit détectée par un détecteur de mouvement, soit affirmée depuis un autre Module Virtuel via une Variable Globale (parce que Madame a froid quand elle reste sans bouger à regarder un film ). Je peux du coup faire en sorte qu'une absence prolongée soit notifiée via la même Variable Globale pour passer les panneaux de chauffage en mode Vacances. Mais je n'ai pas très envie d'un Module Virtuel faisant doublon avec le natif Fibaro, surtout avec les limites en terme d'IHM. Et puis GEA permet de modifier une Variable Globale sur conditions Sur le deuxième point, je mets dans le cahier des charges la possibilité de spécifier soit l'ID d'un module, soit une table avec l'ID du Module Virtuel et l'ID de l'étiquette, ex. {12, "lblSejour"}, la fonction type() permettant de faire le distingo et de gérer la suite Modifié le 2 novembre 2017 par OJC
pepite Posté(e) le 2 novembre 2017 Signaler Posté(e) le 2 novembre 2017 Très bon e idée ;-) le WAF toujours le WAF on en est tous là ;-) Je ne pensais pas à un doublon, par exemple avec GEA, scène unique qui gère beaucoup beaucoup de choses ;-) Oui type tu peux décider ;-)
OJC Posté(e) le 2 novembre 2017 Auteur Signaler Posté(e) le 2 novembre 2017 Pour la régulation, je crois que je vais pomper l'algorithme de chauffage de la box eedomus, qui m'a l'air plutôt bien pensé en plus d'être d'une simplicité absolue... Y aurait-il des retours d'expérience sur l'efficacité de cet algorithme ? 1
iman Posté(e) le 2 novembre 2017 Signaler Posté(e) le 2 novembre 2017 ce sujet m'intéresse énormément étant donnée que j'ai un plancher chauffant électrique avec plusieurs zones, actuellement j'utilise des sonde nethamo+IPX800 qui commande les fil pilote (ON-OFF) j'ai conservé les ancien thermostat qui me servent uniquement de commande et j'ai repris un VD qui fait thermostat mais uniquement ON-OFF
Nico Posté(e) le 2 novembre 2017 Signaler Posté(e) le 2 novembre 2017 Hum, mais cela me plait beaucoup On peut avoir un visuel du VD du coup ?
OJC Posté(e) le 2 novembre 2017 Auteur Signaler Posté(e) le 2 novembre 2017 @Nico Je mettrais une image à la prochaine mise à jour. Tu verras toutefois que très basique, juste des étiquettes avec le nom de la pièce d'un côté et la température de consigne de l'autre...
Nico Posté(e) le 2 novembre 2017 Signaler Posté(e) le 2 novembre 2017 Mais je croyais qu'on pouvait changer la consigne directement depuis le VD ?
OJC Posté(e) le 2 novembre 2017 Auteur Signaler Posté(e) le 2 novembre 2017 Non, pour modifier la consigne, il faut aller dans le panneau de chauffage ou avec l'application Android / iPhone dans Température/Zones/Manuel. Je n'ai pas fait un doublon avec ce qui existe déjà nativement. Ce que fait le Module Virtuel, c'est de modifier automatiquement la consigne en cas d'ouverture/fermeture d'un ouvrant et en cas d'absence, en fonction du paramétrage.
OJC Posté(e) le 3 novembre 2017 Auteur Signaler Posté(e) le 3 novembre 2017 Et voici la dernière mouture, avec au menu un algorithme pour la régulation du chauffage qui tient bien la route et qui est celui proposé nativement par la centrale domotique eedomus. J'ai également revu la manière de configurer le module virtuel et la scène, je commençais à me noyer dans ma variable de type table !! Et puis les icônes
iman Posté(e) le 4 novembre 2017 Signaler Posté(e) le 4 novembre 2017 bonjour OJC, lorsque je fais un début sur le module virtuel j'ai cette erreur:[ERROR] 08:57:05: line 209: bad argument #1 to 'decode' (string expected, got nil) alors qu'il n'a rien
iman Posté(e) le 4 novembre 2017 Signaler Posté(e) le 4 novembre 2017 pour la commande du radiateur j'utilise un module virtuel avec 2 bouton ON-OFF, est ce possible d'utiliser ta scène ou quelle motif faire?. Sino bravo pour le travail
OJC Posté(e) le 4 novembre 2017 Auteur Signaler Posté(e) le 4 novembre 2017 (modifié) @iman Il faut supprimer la ligne jT = json.decode(fibaro:getGlobalValue("HomeTable")) située ~ ligne 208, qui est liée à la configuration utilisée en exemple, dans laquelle les ID de tous les modules sont stockés dans une variable globale pour faciliter leur utilisation dans les scripts. Pour la commande de ton radiateur, voir post suivant. Modifié le 4 novembre 2017 par OJC
OJC Posté(e) le 4 novembre 2017 Auteur Signaler Posté(e) le 4 novembre 2017 Tiens, j'ai modifié le code (pas testé de manière approfondie puisque je ne fonctionne pas comme ça pour commander mon chauffage) : Heating Manager v. 1.2.1b.lua Tu fais comme ça : HeatingManager:addHeater({ID de ton module virtuel, n° du bouton ON, n° du bouton OFF}, idSonde, localP, localT) Dis moi si ça marche.
iman Posté(e) le 4 novembre 2017 Signaler Posté(e) le 4 novembre 2017 Merci pour le retour, je test cela en fin de journée
iman Posté(e) le 4 novembre 2017 Signaler Posté(e) le 4 novembre 2017 Doit ton créer une scène pour chaque chauffage ou il suffit d’itentifier tous les id modules virtuel et tous id des sondes?
Messages recommandés