Heating & Cooling Manager (PID HC3)

[Felig]

Voici une nouvelle version beta à tester:

- La mise à jour du mode Off sur l'interface par défaut doit être corrigé normalement

- Le 0% s'affiche avec le symbole

- Le QA ne teste plus les radiateurs qu'il a déjà testé une fois (ça devrait éviter les pbs au reboot) @jojo tu peux remettre checkHeaters = true et tester ?

- Le QA va tenter de réveiller les capteurs pas mis à jour depuis longtemps (6h par défaut)

- Au bout de 8h sans mise à jour, les radiateurs sont stoppés @Dragoniacs je te laisse tester

- EDIT (AJOUT): le QA détecte si la HC3 vient d'être rebootée, et retarde son démarrage d'une minute si c'est le cas

 

(pièce jointe supprimée, la dernière version est disponible en téléchargement sur la première page)

 

 

J'ai pas pu faire des tests approfondis donc dites-moi si vous voyez des choses bizarres

 

@jojo D'après les logs la mise mode Manuel au reboot ne vient pas du QA. Soit un QuickApp (GEA ?) envoie cette instruction lorsqu'il démarre (mais a priori ce n'est pas ça car l'origine = User), soit c'est l'interface sur ton téléphone qui se rafraichit quand la HC3 reboot. La version jointe devrait régler le pb (en cas de reboot, le démarrage du QA est retardé et les consignes reçues entretemps sont ignorées).

Modifié le 27 février 2023 par Felig
Trouvé cause du mode Manuel

[Felig]

Il y a 4 heures, jojo a dit :

comprends pas, car c'est juste un FGS-224, et personne ne sait ce qu'il y a derrière. 

En fait en regardant tes logs j'ai compris: le QA démarre avant que les services zWave soient réinitialisés, c'est normal qu'il ait du mal à communiquer avec ton FGS.

Voici un extrait de ton log heat:

[12.02.2023] [11:46:39] [DEBUG] [QUICKAPP866]: HEATING & COOLING MANAGER v. 5.20 beta 10
[12.02.2023] [11:46:41] [DEBUG] [QUICKAPP866]: [-PID-] Loading PID data from variable 'PID_Data'
[12.02.2023] [11:46:44] [DEBUG] [QUICKAPP866]: [-PID-] Retrieving Chauf_Bureau_Radiateur : {"lastI":48.8}
[12.02.2023] [11:46:44] [DEBUG] [QUICKAPP866]: Chauf_Bureau_Radiateur : Testing On / Off commands - Please wait
[12.02.2023] [11:46:47] [TRACE] [ZWAVE]: Z-wave start
[12.02.2023] [11:46:54] [DEBUG] [QUICKAPP866]: Chauf_Bureau_Radiateur : Sensor = 'Bureau_Tmp' (wake up: N/A)

 

Il y a 3 heures, jojo a dit :

Si une telle erreur est détectée, serait-il possible de forcer une sauvegarde du QA 51 ou 2 fois max)? et d'envoyer un mail de notification qu'il y a eu une erreur ? 

Tu as l'option de régler HMCF.pushMobile sur true, et d'ajouter l'id de ton téléphone dans HMCF.pushMobileList. Tu as testé ?

Modifié le 13 février 2023 par Felig

[Dragoniacs]

Merci, je lance le test.....

[jojo]

Il y a 19 heures, Felig a dit :

Tu as l'option de régler HMCF.pushMobile sur true, et d'ajouter l'id de ton téléphone dans HMCF.pushMobileList. Tu as testé ?

juste, mais je ne l'avais pas envisagée, car les notifs sont merdiques.

Ne serait-il pas possible d'avoir une option similaire HMCF.mail, où on préciserait l'id de l'utilisateur à qui envoyer les mails.

Je pense que ta dernière version va régler bcp des problèmes de reboot. Je commence les tests.

[Felig]

Voici une version avec l'option email, et quelques bugs corrigés.

 

HCM v520.12.lua

 

Pour activer les emails, il faut ajouter les lignes suivantes dans User Settings:

  HMCF.sendEmail      = true      -- send email in case of warning or error
  HMCF.sendEmailList  = {2}       -- list of user IDs for email notifications

Pour tester les emails il suffit de faire une configuration invalide (par exemple aucun radiateur configuré).

Modifié le 15 février 2023 par Felig

[jojo]

Excuse ma trop longue absence ...

Merci pour la prise en compte de mes demandes, et jje vois que tu viens d'inclure la possibilité d'envoyer des mails 

J'avais déjà fait un premier test de reboot, et le chauffage de mon bureau repassait à Manuel :

• donc si cela proviendrait d'une instruction de mon GEA ou d'un QA chez moi (ce dont je doute fort, car rien de programmé pour activer le mode Manuel (ok pour Confort ou Eco), mais en tout cas pas avec un délais de 1 min.
• je voulais donc remettre une toute "vielle" version de HCM pour comparer, mais maintenant je recommencerai tous mes tests avec cette dernière version.

A+

[jojo]

ok, grace à la lecture détaillée des logs, j'ai trouvé que l'erreur lors du reboot provenait de mon mastodonte de QA de gestion du chauffage qui n'était pas encore compplètement migr. Une de ses complexité provient du fait qu'il devait être compatible avec les 2 modes de gestion des radiateurs. Ce WE, je bascule tout sur ton PID (ce donnera une petite touche d'amaigrissement à mon GEA, et une groose à mon QA de gestion du chauffage)

[jojo]

Le 06/02/2023 à 17:52, Felig a dit :

Je ne connais pas les Zigbee Aquara mais normalement le QA s'ajuste en fonction du temps de réveil du capteur. Il faut juste que le temps de réveil soit de 15 minutes max.

Si le temps de réveil n'est pas disponible dans 'properties.wakeUpTime' (ce qui j'imagine est possible avec Aquara) le QA va croire que le capteur n'a pas de temps de réveil, et dans ce cas il faut forcer le temps de réveil réel dans HMCF.minCycle (fichier config).

Pour tester, il suffit de regarder les logs au démarrage. Si le QA fonctionne sur des cycles courts (pour l'instant le minimum est 3 min, mais je l'ajusterai peut-être en fonction des tests faits actuellement par jojo, car ça me semble un peu court pour du chauffage classique), c'est que le QA n'a pas trouvé le temps de réveil du capteur.

Je commence ma migration, mais je tombe sur un os imprévu : le temps de réveil.

J'ai un Aeotec Tri sensor, et dans le json, j'ai bien la propriété

"wakeUpTime": 28800,

or, d'après la doc, le paramètre 23 permet de définir le temps (en sec) entre chque remontée de température.

      {
        "id": 23,
        "lastReportedValue": 600,
        "lastSetValue": 600,
        "size": 2,
        "value": 600
      }
 

La température est bien remontée à la box toutes les 10 min, mais comme le wakeupTime existe et n'a pas été modifié le programme refuse de démarrer (j'ai 5 pièces à réguler avec cette son de température) => Que faire ? (y a-t-il moyen de forcer une valeur ?)

Avec le paramètre HMCF.minCycle=600, ça ne va pas mieux, car le programme reçoit une information erronée du wakeupTime

[Felig]

Oui, tu peux forcer le paramètre wakeUp dans la fonction addHeater(). Dans ton cas: addHeater({id=XX, wakeUp=600})

 

Si tu veux mettre à jour ton fichier config avec les dernières instructions, voici:

    SYNTAX: HM:addHeater({
              id = ,         -- heater device ID (numeric), only mandatory parameter
              turnOn = ,     -- ON  string cmd ("turnOn" or "99"), optional (default "turnOn")
              turnOff = ,    -- OFF string cmd ("turnOff" or "0"), optional (default "turnOff")
              property = ,   -- property to read heater state, optional (default = "value")
                             -- IMPORTANT: if heater state cannot be read, set to "NO"
              Kp=,Ki=,Kd=,   -- for PID regulation, optional (see forum for information)
              sensor = ,     -- format: id or {id, property} - optional, temperature sensor
                             -- only use if you need to override the default room sensor
              wakeUp = ,     -- sensor wake up delay (sec), optional, only needed if wake up
            }                -- delay of temperature sensor cannot be read by the HC3

 

Modifié le 17 février 2023 par Felig

[jojo]

ça marche beaucoup mieux comme ça ! => c'est une vrai tuerie ce développement, tout a été prévu.

 

J'ai tout de même une question : pourquoi faut-il rajouter ce paramètre au niveau du radiateur (et quid si plusieurs radiateurs), alors qu'il se rapporte à la sonde de température ? (j'aurais imaginé un paramètre HCMF.temperatureWakeup

[Felig]

C'est un ajout récent, c'est Dragoniacs qui m'en a donné l'idée avec son capteur qui avait un temps de réveil inconnu.

Je l'ai mis au niveau du radiateur car il est possible d'avoir un capteur de température différent pour chaque radiateur.

[jojo]

Il y a 10 heures, Felig a dit :

car il est possible d'avoir un capteur de température différent pour chaque radiateur.

??? tu m'as perdu là ...

Il y a une consigne de température unique pour le QA.

Il ne peut donc qu'y avoir qu'une sonde de température ...

[Felig]

Oui il y a une seule consigne, mais la température peut être différente dans différentes parties de la pièce. Le programme d'origine permet d'avoir un capteur différent par radiateur. Les radiateurs avec thermostat du commerce ont chacun leur capteur de température distinct, ça te permet de faire la même chose, sachant que beaucoup de modules fibaro ont un capteur de température intégré. Je suis d'accord que dans une petite pièce c'est pas très utile mais j'ai laissé cette possibilité. La température affichée sur l'UI est celle du premier radiateur uniquement.

Modifié le 18 février 2023 par Felig

[jojo]

bonjour,

J'ai encore une exception :

Jz migre tous mes thermostats vers le PID.

J'avais un thermostat pour la gestion de mon ECS que, en mode "confort", a une consigne à 60°C. Or ce n'est pas autorisé par le programme :

Mode Confort : Les valeurs Min-Max [60-28] sont invalides

les infos dans le message d'erreur ne sont pas 100% exactes, car voici ma config

  HMCF.range.Confort  = {60, 80}  -- {min, max} values for mode Comfort 

Je n'y ai pas encore réfléchi, mais je pense que j'aurai un problème similaire avec le thermostat de ma piscine, que je chauffe si mes panneaux solaires sont trops chauds (délestage)

 

Existe-t-il un paramètre pour permettre d'avoir des ranges non habituels ?

 

[Nico]

Mais Jojo, tu veux mettre le délestage et l'ECS en PID ??

[jojo]

NON : si (et ça arrive souvent en été) mon ballon ECS (2500 L) est à 90°C et que ma piscine est déjà bien chaude (>29°C), mes panneaux solqires thermique s'arrêtent (pour que mo ECS ne boue pas), alors, pour éviter une surchauffe des panneaux, je continue de chauffer la piscine.

 

je viens de trouver à l'instant une moyen (non propre) de bypasse cette vérification dans le code :

-- vjo 19/02/2023 for ECS
--    local min = math.max(range[mode][1], range["_global"][1])
--    local max = math.min(range[mode][2], range["_global"][2])
    local min = 0
    local max = 100
    if min > max or (mode=="Manuel" and min==max) then self:abort("isNotValidRange",mode,min,max) end
    if min < max then table.insert(self.editable, mode) end
    self.modes[mode] = modes[mode] or math.max(min, max - 1)

en attendant une solution propre proposée par le maître

[jojo]

en fait, je n'ai "résolu" qu'une partie du problème.

Car malgré que j'ai défini un range de 60 à 80,

Il ne voit qu'un range de 60 à 28 ...

et je n'arrive donc pas à mettre une consigne de confor de 70 °C ....

[jojo]

j'ai trouvé plus bas dans le code, comment le faire mieux :

-- vjo 19/02/2023 for ECS
--          _global       = { 1, 28},  -- {min, max} limits applicable to ALL modes and calls
          _global       = { 1,100},  -- {min, max} limits applicable to ALL modes and calls

je suis sûr qu'il est possible de le mettre dans les user settings ... je continue de chercher.

 

En tout cas, à la lecture de ce code  c'est une vraie machine de guerre ...

[Felig]

Oui tu peux l'ajouter dans user settings, c'est dans le mode d'emploi:

 

> LIMITE GLOBALE DE CONSIGNE
  Il existe une limite globale de consigne (par défaut entre 1° et 28°) qui s'applique
  à l'ensemble du thermostat. Toute consigne hors limite sera ignorée. Pour modifier
  cette limite globale, vous devez ajouter le paramètre suivant dans USER SETTINGS:

  HMCF.range._global  = {1, 28}  -- valeurs {min, max} acceptées par le thermostat

 

[jojo]

je suis quelqu'un de têtu, et j'ai fini par trouver le paramètre (qui me permet de ne pas devoir modifier le codeà,

  HMCF.range._global  = { 1, 99}  -- {min, max} limits applicable to ALL modes and calls

 

[jojo]

il y a 9 minutes, Felig a dit :

Oui tu peux l'ajouter dans user settings, c'est dans le mode d'emploi:

 

> LIMITE GLOBALE DE CONSIGNE
  Il existe une limite globale de consigne (par défaut entre 1° et 28°) qui s'applique
  à l'ensemble du thermostat. Toute consigne hors limite sera ignorée. Pour modifier
  cette limite globale, vous devez ajouter le paramètre suivant dans USER SETTINGS:

  HMCF.range._global  = {1, 28}  -- valeurs {min, max} acceptées par le thermostat

 

ourf, si j'avais pris le temps de le lire en détail, j'aurais gagné bcp de temps !

[jojo]

salut,

j4ai finit (enfin presque) la migration de tous mes régulateurs.

Dans les versions précédentes du code, il y avait une variable (numérique) pour la consigne de température des différents modes.

Cela était donc facilement exploitable, par exemple, dans GEA.

Maintenant tout est dans une variable Modes

Y a-t-il une raison particulière ? Serait-ce envisageable de revenir en arrière ? (ou dois-je développer qqch pour le lire ?)

[Felig]

Salut,

 

C'était pour limiter le nb de variables, sachant que j'ai prévu d'en ajouter une autre pour sauvegarder le mode Manuel en cas de reboot.

Pour lire la variable il faut juste un json.decode:

modes = json.decode(variable)
local confort = modes["Confort"]
local eco = modes["Eco"]
etc.

 

[jojo]

merci beaucoup, c'était l'idée que j'avais, mais merci pour le bout de code, je ne dois pas chercher pour le faire. Et tant qu'à faire, aurais-tu le code pour récupérer une variable d'un QA (ici Modes) depuis un autre QA (mon perso de Gestion Chauffage) ?

[Felig]

Le plus simple c'est la fonction tools:getVariable()

 

Sinon voici un extrait du code qui devrait fonctionner:

function getVariable(id, variable)
  device = api.get('/devices/' .. tostring(id))
  if device and type(device.properties) == "table" and type(device.properties.quickAppVariables) == "table" then
    for _, v in ipairs(device.properties.quickAppVariables) do
      if v.name == variable then return v.value end
    end
  end
end

 

Modifié le 20 février 2023 par Felig