Aller au contenu

Messages recommandés

Posté(e)

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.

  • Like 1
Posté(e)

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 :)

Posté(e)

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

Posté(e)

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

Posté(e)

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:angry: et avec ta modification comme disait pepite tous le monde il trouvera son compte;)

  • Like 1
Posté(e) (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é par OJC
  • Like 1
Posté(e) (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

 

5a00e2e137ae3_Capturedu2017-11-0623-31-44.png.97cac63610d16f6f03857a06526a2287.png

 

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 :

 

5a00e2767b401_SetpointProviderforHeatingManager.png.945620b559212507c9f7081db250c2f1.png

 

 

Modifié par OJC
  • Upvote 2
Posté(e)

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

 

 

 

Posté(e)
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.

 

 

 

  • Like 1
Posté(e) (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é par Dgille
  • Like 1
Posté(e)

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).

  • Like 1
Posté(e)

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.

Posté(e)

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

  • Like 1
Posté(e)

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 ?

Posté(e)

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

Posté(e)

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

  • Like 1
  • Upvote 1
Posté(e)

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
--]

Posté(e) (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é par OJC
Posté(e)

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?

×
×
  • Créer...