Steven Posté(e) le 6 novembre 2017 Signaler Posté(e) le 6 novembre 2017 Perso, j'avais créé ce bout de code lorsque les panneaux de chauffage était bugé, je ne l'utilise presque plus. C'est à dire que les plages horaires et les températures viennent toujours d'un panneaux de chauffage mais par contre, je le parcours par programmation pour déterminer la température. A savoir que dans le bout de code que je t'ai cité. local datas = {...} est à l'identique de local datas = api.get("/panels/heating/"..<id_panel>).properties Je fais cela pour des raisons simples : Le panneau ne permet que 4 températures ce qui limite certaines personnes (pas moi). Perso, j'ai les enfants une semaine sur deux donc 2 panneaux de chauffage différents (horaires et températures différentes). Si je souhaite géré les congés ou les vacances, cela m'obligerais à en créer 4 en tout. Dans mon cas, c'est simple, je pars du principe que lorsque je suis en congé, je me calque sur le dimanche soit : if (JourChome="OUI") then day = "sunday" end Donc par programmation, on peux faire évoluer selon ces souhaits (et compétences) un panneau de chauffage. Prenons l'exemple de @pepite function userFunction(panel) if (madame_crie_fort) then if (madame_crie_encore_plus_fort) then return 28 end return 25 end return panel.properties.currentTemperature end Par contre, et la je te soutiens à 1000% cela ne sert à rien de faire une usine à gaz pour des choses qui existe déjà. Ce que tu pourrais peut-être faire pour rendre tout le monde content, c'est un truc comme cela : function getSetPoint(ID) local panel = api.get("/panels/heating/" .. ID) if (userFunction) then return userFunction(panel) end return panel.properties.currentTemperature end Tu garde ainsi un code super légé sauf pour ceux qui souhaite s’embêter a implémenter leur propre composante et tant pis pour eux s'ils doivent faire attention au mise à jour. Ils peuvent ainsi créer leurs propres VD et utiliser cette fonction pour aller chercher eux-même les valeurs. Tu ne dénature pas ton code mais ajoute juste une petite dérivation laissant l'utilisateur agir à sa guise. Je dis cela mais je dis rien ... vu que je n'ai qu'un poêle à pellets et que je n'utilise donc pas ton Heating Manager. Par contre, je m'intéresse à son évolution que je trouve géniale ... donc encore félicitations et désolé pour mon grain de sel. 1
OJC Posté(e) le 6 novembre 2017 Auteur Signaler Posté(e) le 6 novembre 2017 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
pepite Posté(e) le 6 novembre 2017 Signaler Posté(e) le 6 novembre 2017 Moi j essaie juste de penser aussi pour le plus grand nombre :-). Mon chauffage n'est pas domotise. Donc mme peut crier fort mais oour le moment je n y suis pour rien :-)..Mais les emplois du temps différents sont vrais:-)Et moi j aime aussi ce code:-)Envoyé de mon Nexus 5X en utilisant Tapatalk
OJC Posté(e) le 6 novembre 2017 Auteur Signaler Posté(e) le 6 novembre 2017 @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.
iman Posté(e) le 6 novembre 2017 Signaler Posté(e) le 6 novembre 2017 OJC, justement j'utilisé le code de steven pour planifier mon chauffage car avec le panneau de chauffage comme je te disais la consigne apres 3H n'était pas pris en charge alors que sur le panneau elle apparaissait bien et avec ta modification comme disait pepite tous le monde il trouvera son compte 1
OJC Posté(e) le 6 novembre 2017 Auteur Signaler Posté(e) le 6 novembre 2017 (modifié) 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... Modifié le 6 novembre 2017 par OJC 1
OJC Posté(e) le 6 novembre 2017 Auteur Signaler Posté(e) le 6 novembre 2017 (modifié) 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 : Révélation --[[ Setpoint Provider for Heating Manager v.1.3.0 (2017) by OJC This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses></http:>. --]] local panels = {} local HeatingSetpoint = {} function HeatingSetpoint:add(name, day, time, temperature) if type(panels[name]) ~= "table" then panels[name] = {} end if day == "weekdays" then day = {"monday","tuesday","wednesday","thursday","friday"} elseif day == "weekend" then day = {"saturday", "sunday"} elseif day == "week" then day = {"monday","tuesday","wednesday","thursday","friday", "saturday", "sunday"} elseif type(day) == "string" and string.find("monday tuesday wednesday thursday friday saturday sunday", day) ~= nil then day = {day} else fibaro:debug("[CRITICAL ERROR] " .. day .. " is not a valid day !") fibaro:abort() end for _, k in ipairs(day) do table.insert(panels[name], {k, string.match(time, "([0-9]+):"), string.match(time, ":([0-9]+)"), temperature}) end end function HeatingSetpoint:update() local list = api.get("/devices?id=" .. fibaro:getSelfId()) for _, row in ipairs(list.properties.rows) do if row.type == "label" then for _, element in ipairs(row.elements) do panel = string.gsub(element.name, "lbl", "") if panels[panel] ~= nil then fibaro:debug(panel) HeatingSetpoint:get(panel) end end end end end function HeatingSetpoint:get(panel) local day = string.lower(os.date("%A")) local now = os.date("%H") * 60 + os.date("%M") local p = panels[panel] for _, k in ipairs(p) do if tostring(k[1]) == day then local h = k[2] * 60 + k[3] if now >= h then setpoint = k[4] end end end fibaro:call(fibaro:getSelfId(), "setProperty", "ui.lbl" .. panel .. ".value", setpoint .. " °C") end ---------------------------------------------------------------------------------------------- -- CONFIGURATION -- ---------------------------------------------------------------------------------------------- --[[ Configuration MUST BE chronological ordered within each zone, i.e. monday before tuesday and 00:00 before 14:00. If not, the virtual device won''t have the expected behaviour Syntax is HeatingSetpoint:add(zone, day, time, temperature) where : > label is the name of the panel, and should have a linked label named 'lbl' + label > day is : "monday" {"monday", "friday"} {"weekday"} which stand for {"monday","tuesday","wednesday","thursday","friday"} {"weekend"} which stand for {"saturday", "sunday"} {"week"} which stand for {"monday","tuesday","wednesday","thursday","friday", "saturday", "sunday"} > time "hh:mm" --]] --CONFIGURATION EXAMPLE HeatingSetpoint:add("Zone1", "week", "00:00", 18) HeatingSetpoint:add("Zone1", "week", "06:30", 22) HeatingSetpoint:add("Zone1", "week", "10:00", 18) HeatingSetpoint:add("Zone1", "week", "18:30", 22) HeatingSetpoint:update() fibaro:call(fibaro:getSelfId(),"setProperty","ui.lblHeatingSetpoint.value","Heating Manager v. 1.3.0") Et une icône pour la route : Modifié le 6 novembre 2017 par OJC 2
pepite Posté(e) le 7 novembre 2017 Signaler Posté(e) le 7 novembre 2017 Yeah, gros boulot, ca va devenir un incontournable ;-) !!! Merci beauoup pour le code ;-) j'apprécie le clin d'oeil ;-)
OJC Posté(e) le 7 novembre 2017 Auteur Signaler Posté(e) le 7 novembre 2017 @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...
pepite Posté(e) le 8 novembre 2017 Signaler Posté(e) le 8 novembre 2017 Il y a 11 heures, OJC a dit : s'il fait le job correctement, je serai content. tu peux déjà l'etre à mon avis. Il y a 11 heures, OJC a dit : variable globale ne me semble pas permettre Que dans une, non, c'est bien le souci, c'est pour cela que beaucoup passe par du php hebergé en perso ;-) pour utiliser une base de données. 1
Dgille Posté(e) le 13 novembre 2017 Signaler Posté(e) le 13 novembre 2017 (modifié) Bonjour à tous, super boulot, j'avais un module qui faisant la même choses, mais en moins bien. Top. Par contre, je ne sais pas si vous êtes confrontés au problème, il semble rester un bug dans le panneaux de chauffage depuis quelques versions (y compris les dernières bétas) Si vous prenez ce panneau par exemple: {"id":6,"name":"Rez de Chaussée","properties":{"monday":{"morning":{"hour":6,"minute":30,"temperature":15.0},"day":{"hour":16,"minute":0,"temperature":19.0},"evening":{"hour":22,"minute":30,"temperature":15.0},"night":{"hour":4,"minute":0,"temperature":19.0}},"tuesday":{"morning":{"hour":6,"minute":30,"temperature":15.0},"day":{"hour":16,"minute":0,"temperature":19.0},"evening":{"hour":22,"minute":30,"temperature":15.0},"night":{"hour":4,"minute":0,"temperature":19.0}},"wednesday":{"morning":{"hour":6,"minute":30,"temperature":15.0},"day":{"hour":16,"minute":0,"temperature":19.0},"evening":{"hour":22,"minute":30,"temperature":15.0},"night":{"hour":4,"minute":0,"temperature":19.0}},"thursday":{"morning":{"hour":6,"minute":30,"temperature":15.0},"day":{"hour":16,"minute":0,"temperature":19.0},"evening":{"hour":22,"minute":30,"temperature":15.0},"night":{"hour":4,"minute":0,"temperature":19.0}},"friday":{"morning":{"hour":6,"minute":30,"temperature":15.0},"day":{"hour":16,"minute":0,"temperature":19.0},"evening":{"hour":22,"minute":30,"temperature":15.0},"night":{"hour":4,"minute":0,"temperature":19.0}},"saturday":{"morning":{"hour":6,"minute":45,"temperature":19.0},"day":{"hour":9,"minute":45,"temperature":19.0},"evening":{"hour":23,"minute":0,"temperature":15.0},"night":{"hour":4,"minute":0,"temperature":19.0}},"sunday":{"morning":{"hour":6,"minute":30,"temperature":19.0},"day":{"hour":16,"minute":0,"temperature":19.0},"evening":{"hour":22,"minute":30,"temperature":15.0},"night":{"hour":4,"minute":0,"temperature":19.0}},"handTemperature":0.0,"handTimestamp":1509725422,"vacationTemperature":0.0,"currentTemperature":15.0,"rooms":[1,2,3,4,10,117,132]},"created":1510423601,"modified":1510423601} Vous constaterez que le champ "currentTemperature" retourne la mauvaise valeur entre minuit et 5:00. J'ai le problème sur tous les panneaux qui décident de chauffer avant 5h du matin. Je dépose un ticket sur bugzilla si vous confirmez le problème. Modifié le 13 novembre 2017 par Dgille 1
pepite Posté(e) le 13 novembre 2017 Signaler Posté(e) le 13 novembre 2017 Bonjour, Regarde ici, @MAM78 a l'air d'avoir aussi rencontré un souci avec currentTemperature. Le bug se précise ;-)
Dgille Posté(e) le 13 novembre 2017 Signaler Posté(e) le 13 novembre 2017 Merci, effectivement, il y a quelque choses de pourris au royaume des panneaux :). Je précise que j'ai constaté cela même sans changement manuel. Je pense que les développeurs Fibaro ont modifié les panneaux (extension de la nuit jusqu'à 5h du mat) après une longue soirée arrosée, et ne calcule pas correctement l'horaire associé pour la température (en tenant compte de la journée d'avant ou d'après selon les cas). 1
iman Posté(e) le 13 novembre 2017 Signaler Posté(e) le 13 novembre 2017 je te confirme avoir le même souci impossible de faire prendre une valeur après 3h dans mon cas
Dgille Posté(e) le 13 novembre 2017 Signaler Posté(e) le 13 novembre 2017 Bug créé chez Fibaro. wait and see. 1
OJC Posté(e) le 15 novembre 2017 Auteur Signaler Posté(e) le 15 novembre 2017 @Steven Citation vu que je n'ai qu'un poêle à pellets Concrètement, ça se gère comment ? Hysteresis ?
Steven Posté(e) le 15 novembre 2017 Signaler Posté(e) le 15 novembre 2017 Oui c'est bien cela, j'utilise juste un hysteresis de +/- 0.7 degré et c'est parfait. Je suis sûr que l'on peut mieux faire mais je ne me suis jamais posé la question.
OJC Posté(e) le 15 novembre 2017 Auteur Signaler Posté(e) le 15 novembre 2017 Petite mise à jour avec pas mal de nouveautés : absence/présence forcée, mode hysteresis, apprentissage automatique, etc... Plus tout ce qui ne se voit pas au niveau de l'optimisation du code... 1
pepite Posté(e) le 16 novembre 2017 Signaler Posté(e) le 16 novembre 2017 Yeah, gros gros boulot. Merci beaucoup. 3 VDs Avec l'ajout de l'hysteresis, ca devient utilisable avec un poele normalement ;-) @Steven. Et ca devient utilisable avec n'importe quel type chauffage ;-) Sinon, tu peux faire confiance aux Variables Globales de Fibaro (pas au sens programmation). Faut juste éviter de cliquer sur la disquette ;-) Autre question : Quel est la partie du code pour l'apprentissage automatique ?
Steven Posté(e) le 16 novembre 2017 Signaler Posté(e) le 16 novembre 2017 Je ne doute pas de l'utilité de cela pour des radiateurs mais pour un poêle c'est moins transcendent. On arrête pas un poêle à l'ouverture d'une fenêtre, le temps de chauffe d'un poêle est trop long pour utiliser la gestion de présence (il doit chauffer avant qu'on arrive). Perso, mon poêle est le seul moyen de chauffage de toute la maison, je n'ai qu'une seule zone. Je modifie le mode de chauffe (éco/normal) (en pilotant les turnOn/turnOff*) selon l'état de la TV ou autre. Donc dans mon cas bien précis, mes besoins ne correspond malheureusement pas à ce développement. Par contre, je plussoie à 1000% pour un usage électrique à 90% pour du poêle. * Si mon poêle détecte un "ON" constant, il est en mode NORMAL ... un "ON" de 2-3 secondes toutes les 5 minutes il passe en mode ECO
OJC Posté(e) le 16 novembre 2017 Auteur Signaler Posté(e) le 16 novembre 2017 @pepite Mais les VG Fibaro ne sont pas concernées par le backup ? Leur contenu, j'entends. Du coup, l'intérêt de stocker dans le VD est de pouvoir bénéficier d'une sauvegarde automatique avec le backup natif. La fonction d'apprentissage est setCoefficients. Pour le moment, elle est un peu basique puisqu'elle se contente d'incrémenter ou de décrémenter le coefficient si la moyenne des écarts en fin de cycle sur les 10 derniers cycles est supérieure à 0,1 ° C. Il faut que je la retravaille, mais autant j'arrive à me débrouiller pour ce qui est du codage, autant je patauge un peu pour ce qui concerne la chauffe proprement dite, et il n'est pas évident de trouver des infos détaillées sur le net. @Steven Effectivement, sur des chauffages très inertiels, la gestion des ouvrants et des absences temporaires n'a qu'un intérêt très limité, à plus forte raison s'il n'y a qu'un seul outil de chauffe pour toute l'habitation. Heating Manager est en fait plus un gestionnaire de température de consigne qu'un gestionnaire de chauffage... 1 1
iman Posté(e) le 16 novembre 2017 Signaler Posté(e) le 16 novembre 2017 pas d'autre mots pour le travaille..il ya plus cas voir ça ce week-end
iman Posté(e) le 16 novembre 2017 Signaler Posté(e) le 16 novembre 2017 je suppose qu'il faut toujours renseigner en début de la scène le rappel du VD ?: --[[ %% autostart %% properties 1039 ui.lbldressing.value 1039 ui.lblsalle.value 1039 ui.lblbureau.value 1039 ui.lblsalledebains.value %% globals --]
OJC Posté(e) le 16 novembre 2017 Auteur Signaler Posté(e) le 16 novembre 2017 (modifié) Non, fini ça La scène gère tout dans la même instance sans triggers. J'ai fait comme ça cas c'était trop galère de faire passer des infos d'une instance à l'autre de la scène puisqu'en cas de modification de la consigne, le programme ne se contente pas de couper ou démarrer les chauffage jusqu'à la fin du cycle, mais recalcule une commande de chauffe. Et il me fallait éviter que l'ancienne commande ne vienne foutre le bazar, donc lui transmettre l'info... Modifié le 16 novembre 2017 par OJC
iman Posté(e) le 16 novembre 2017 Signaler Posté(e) le 16 novembre 2017 donc il n'y a plus cas contiguë cette partie: HeatingManager:addHeater({437, 1, 2}, 642, localP, localT) HeatingManager:addHeater({511, 1, 2}, 453, 0.6, 0.01) HeatingManager:addHeater({438, 1, 2}, 682, localP, localT) HeatingManager:addHeater({439, 1, 2}, 415, localP, localT) et l'id de la sonde EXT, et pour le KP et Kt par défaut faut -il également les renseignés ou plus besoin?
Messages recommandés