Aller au contenu

OJC

Membres confirmés
  • Compteur de contenus

    390
  • Inscription

  • Dernière visite

  • Jours gagnés

    8

Tout ce qui a été posté par OJC

  1. OJC

    Heating Manager

    Pour régler les paramètres de calcul de la durée de chauffe pour chaque radiateur, il faut déclarer les coefficient P et T avec la fonction HeatingManager:addHeater, paramètres localP et localT : HeatingManager:addHeater(idHeater, [idSonde], [localP], [localT]) + idHeater = ID du module permettant de commander le radiateur + idSonde = ID de la sonde de température à laquelle est asservie le radiateur ou {ID du module virtuel, ID de l''étiquette contenant la température} Paramètre optionnel à défaut duquel c''est la sonde de température principale de la pièce qui est utilisée. + localP = Paramètre optionnel à défaut duquel la variable default.kP est utilisée + localT = Paramètre optionnel à défaut duquel la variable default.kT est utilisée L'algorithme utilisé est expliqué ici et aussi là. Pour la température extérieure : --HeatingManager:setOutdoorSonde(ID Device ou {ID VirtualDevice, ID Label}) Ce n'est qu'à défaut que le programme utilise la température extérieure fournie par le plugin météo.
  2. OJC

    Heating Manager

    Le principe est que tout le chauffage est géré par une seule Scène, dans laquelle il suffit d'identifier tous les id des modules virtuels permettant de commander chaque chauffage, ainsi que l'id de la sonde (ou module virtuel sonde)
  3. OJC

    Heating Manager

    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.
  4. OJC

    Heating Manager

    @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.
  5. OJC

    Heating Manager

    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
  6. OJC

    Borne Wifi

    Bonjour, Comme beaucoup, je suis chez Free et j'en étais resté au wifi de la Freebox. Mais à la suite d'un déménagement dans une maison qui est en fait composée de deux bâtiments accolés, le réseau ne passait pas du tout dans la partie ancienne, la Freebox étant dans la partie plus récente où arrive la fibre. J'ai mis un CPL pour faire un deuxième réseau wifi avec SSID identique avec une grosse limite sur le débit et aucune bascule automatique. Bilan : Madame ronchonne... et le réseau Sonos déconne par moments avec le PLAY:1 de la cuisine en mode lecture mais qui n'apparaît pas sur l'application, et le tout parce que le smartphone est connecté sur la Freebox et pas sur le Wifi CPL... Donc, il fallait WAFer le truc... Du coup, vu le bien qui dit par ici de cette marque, j'ai pris une UAP-AC Pro, qui me met le réseau dans toute la maison. Un bémol cependant puisque dans la partie ancienne, je me retrouve avec du -80dBm maximum... Je sais pas ce qu'il y a dans le mur où les deux bâtiments de rejoignent (enfin, les murs, puisqu'en réalité, ce sont deux murs de façade collés), mais le wifi n'aime pas... Aucun problème pour le réseau Z-Wave, cependant. Donc j'ai pris une deuxième UAP-AC Pro qui vient d'arriver pour mettre dans la partie ancienne. L'USG est arrivé hier et l'US-8-60W est programmé pour demain Obligé... plus de place sur le switch de la Freebox ! Laquelle va donc découvrir le mode Bridge ^^...
  7. OJC

    Heating Manager

    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.
  8. OJC

    Heating Manager

    @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...
  9. OJC

    Heating Manager

    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 ?
  10. OJC

    Heating Manager

    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
  11. OJC

    Heating Manager

    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 ?
  12. OJC

    Dawn & Dusk Manager

    Merci Là je suis sur Heating Manager en train de me pencher sur le code de la régulation PID et de me rendre compte que celui que j'ai repiqué est, disons... limité, mais il faut que je reprenne encore celui-ci puisque je découvre toujours plus de possibilités d'optimisations. A ce sujet, je conseille vivement la lecture de Programming in Lua de Roberto Ierusalimschy lui-même (architecte en chef du projet Lua), qui est une mine d'informations. La première édition du bouquin est librement accessible sur leur site. Et il faut que je rajoute onSolarNoon (midi solaire) que j'ai zappé alors qu'il est disponible sur l'API + la gestion des erreurs retournées par l'API puisque j'ai vu comment faire...
  13. OJC

    Heating Manager

  14. OJC

    Heating Manager

    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 !!
  15. Comme tu dis, on peut mieux faire... Mais cela implique d'abord d'étudier le truc, avant de songer à convertir ça en algo puis en code Lua . Du coup, ma priorité était avant tout de faire fonctionner le chauffage avec le froid qui arrive ! Ton idée d'anticiper sur la consigne pour qu'à l'heure dite, la température réelle y soit déjà, est très intéressante. Le code proprement dit servant à anticiper le démarrage du chauffage en fonction de la température de consigne future et de la durée nécessaire, c'est la partie la plus simple. Le gros morceau, c'est la détermination de cette durée. A vue de nez, je pense que cette durée dépend des caractéristiques de la pièce (volume, valeur a priori constante une fois définie), de l'atmosphère de la pièce (masse volumique qui dépend de l'altitude et, pour être puriste, de la météo, ainsi que de l'humidité de la pièce + capacité calorifique de l'air, une quasi-constante dans la tranche de température applicable à une habitation) ainsi que de la conductivité thermique des murs avec l'extérieur. La partie variable, ce sont donc les déperditions qui dépendent de l'isolation (constante sur une pièce donnée) et de la température extérieure. L'analyse statistique des relevés de température devrait pouvoir permettre d'anticiper la part de joules qui augmentera la température de la pièce et celle qui partira dans les murs, et d'en tirer au final un PID. Un sacré boulot en perspective, rien que pour formaliser un algo...
  16. Mon projet est toujours en cours de développement. La première version fonctionnelle est là, avec dans la présentation le lien vers le post du forum officiel Fibaro où j'ai repiqué le code de régulation PID, que je n'ai pas modifié sur les principes (calculs de l'intégrale et de la dérivée). J'ai récupéré d'autres codes de régulation PID en Lua sur divers forums et blogs liés à la HC2 ou à Domoticz qui utilise également Lua, qui proposent des choses plus évoluées quant aux équations utilisées. J'ai prévu de me pencher là-dessus dans un second temps pour optimiser mon code. Dans l'immédiat, cependant, je travaille d'abord à terminer le code pour la partie 'quelle est la température de consigne ?' (absence, ouvertures, etc.). Ensuite, j'attaquerais le code pour la partie 'comment atteindre la température de consigne ?'.
  17. OJC

    Dawn & Dusk Manager

    Oui, c'est la modification que j'ai apportée suite à la suggestion de @pepite (version pas encore publiée)... J'ai un peu galéré pour comprendre comment fonctionne api, mais j'ai fini par trouver en farfouillant à droite et à gauche. Dommage qu'il n'y ait pas un tuto, la page /docs de la HC2 est intéressante mais pas suffisante.
  18. Bonjour ! Oui, ça m'intéresse pour pouvoir comparer la T° avec la consigne et affiner ma régulation PID.
  19. OJC

    Heating Manager

    @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...
  20. OJC

    Heating Manager

    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
  21. OJC

    Dawn & Dusk Manager

    Merci Utiliser api.get pour récupérer l'ID du Module Virtuel, est-ce vraiment le plus pertinent vu qu'on ne peut pas filtrer a priori pour limiter les itérations de la boucle qui recherche via le nom ? Quel est le gain ? EDIT = OK, oublie la question... La page /docs est bien pratique, mais n'explique pas comment utiliser l'api directement dans le code sans passer par une connexion http... Mais bon, j'ai trouvé... Bien plus pratique, en effet !
  22. Bonsoir, J'essaie de créer un Module Virtuel en passant par l'API via http://xxx.xxx.xxx.xxx/docs mais je me retrouve avec ce message d'erreur : { "type": "ERROR", "reason": "Type not found", "message": "Type 'virtual_device'' is not installed in the system." } S'agit-il d'une sécurité, ou y- a-t-il une subtilité ? Etant précisé que le body que j'utilise est le contenu d'un fichier vfib sorti directement de la HC2.
  23. @Yannick Merci pour l'info sur le changement de serveur ntp Mon HC2 avait déjà dérivé d'un peu plus de deux minutes !! @henri-allauch Il faut le modifier dans Configuration > Situation Géographique > Serveur NTP:
  24. OJC

    Dawn & Dusk Manager

    Bonsoir ! Je continue à améliorer Dawn & Dusk Manager, ce qui me permet surtout d'approfondir le langage Lua que je connaissais pas avant d'acheter la Home Center 2... Au menu de la version 1.2.1, j'ai ajouté un bouton Switch Test Mode sur le Module Virtuel pour pouvoir lancer le mode de test du programme sans avoir à modifier le code. Ce fut l'occasion d'adapter le code de détection de l'ID d'un Module Virtuel à partir de son nom à la détection de l'ID d'une Scène à partir de son nom, pour pouvoir redémarrer la Scène en mode de test après avoir cliqué sur le bouton. Sur ce point de la communication automatique entre une Scène et le Module Virtuel qui lui est rattaché, le programme stocke désormais l'ID du Module Virtuel dans une Variable Globale pour ne pas avoir à faire la recherche à chaque fois. Il ne la fait plus que si l'ID qu'il trouve dans la Variable Globale ne correspond manifestement pas à ce qu'il cherche. J'ai aussi découvert qu'il y avait bien plus simple et élégant pour créer les Variables Globales, en utilisant api.post. Un grand merci @Steven et son wiki sur ce point . Bref... C'est bien sympa, cette centrale domotique... Je ne regrette pas openHab 2, qui m'apparaît avec le recul beaucoup moins souple, en dépit de la rigidité inhérente à un système propriétaire.
  25. OJC

    Dawn & Dusk Manager

    Voilà, ce mode d'enchaînement fonctionne Et j'ai ajouté un mode de test, qui m'a permis d'aller plus vite dans le test du fonctionnement, et qui vous permettra de voir en moins de 10 minutes un cycle complet.
×
×
  • Créer...