erreur lors de passage consigne manuelle

[Lazer]

Oui, c'est pas ce que tu voulais faire ?

 

Suffit de récupérer l'API utilisée par l'interface graphique lors de l'ajout.

 

Même si perso je suis pas fan, créer un child c'est un processus simple, l'ajouter automatiquement dans une zone, ça correspond à ton besoin présent, mais pas forcément générique.

[jjacques68]

en effet, il faut passer par l'API du climat panel pour y ajouter la QA Thermostat...

Je viens de trouver.  

Suis pas très fan non plus ...

Y a de quoi mettre une sacré pagaille.

[jjacques68]

c'est un bug d'affichage, ou ma logique qui bug : 

 

quand le climat panel est sur OFF : 

 

 

et que JE VEUX mettre une consigne manuelle, l'affichage du thermostat m'en empêche.

Je peux pas sélectionner la consigne, mais que la durée ??

 

 

 

alors qu'en passant par l'API c'est possible !!

(ici j'ai passé les 22°C par l'API)

 

pourtant je me dis que c'est pas déconnant de vouloir demandé une marche manuelle même si le panel est sur OFF...

 

 

[jjacques68]

J'ai terminé... pffffffff 

 

Alors je sais pas si c'est plus simple, mais c'est logique.

Je sais pas où elle est la méthode KISS sur ce coup là...

 

Pour résumé :

 

Chaque zone du climatePanel (9 au total) a un seul et unique device : un QA Thermostat.

J'ai viré des zones les Danfoss.

 

J'ai un QA Parent qui me "gère" les 9 Child (toujours aussi moches les QA)

 

 

Les Child sont de type "com.fibaro.hvacSystemHeat".

 

Donc la zone du climatePanel pilote le QA thermostat (Child).

Qui lui même relaie l'info au(x) Danfoss.

c'est assez simple, seules 2 fonctions sont utiles : setThermostatMode() et setHeatingThermostatSetpoint().

Pour chaque Child, j'ai une variable avec la liste des Danfoss qu'il doit gérer (ça c'est pourri).

 

Tout le pilotage (mode OFF/HEAT, Schedule/Manual) se fait soit depuis le QA parent, soit depuis le climatePanel.

 

Ce qui est déroutant, c'est qu'on pourrait tout aussi piloter directement la zone depuis son QA thermostat, voir même directement la tête.

ça fait 4 point de paramétrages, y a de quoi perdre le nord !!

limite, ça mériterait de masquer les child et les Danfoss dans la HC3.

 

J'ai pu garder mes rôles supplémentaires, comme la mise à Off d'une zone lorsqu'une fenêtre est ouverte,

ainsi que la cohabitation avec mon IHM sous Windev (ce qui était le plus chiant d'ailleurs, du coup j'a simplifié, celui-ci utilise une méthode dans le Parent)

 

Mais maintenant j'ai un vrai "Off" de la zone et non plus une sorte de consigne pourrie d'une durée supérieur à l'espérance de vie de la planète  

 

une question reste en suspend, que je vais tester, et qui me fait peur  :

Si une zone est sur OFF,

et qu'on lui passe une consigne manuelle,

à la fin de cette consigne,

sur quel mode revient la zone ?? OFF ou HEAT ??

Je le sens trop le coup de la zone qui revient en mode HEAT toute seule, je sais pas pourquoi...

 

Concernant l'usage des QA Child :

 

il n'y a toujours pas de solutions plus simple pour accéder, depuis le Parent, aux ressources du Child, comme une variable ?

on est toujours obliger de parcourir la liste des Child, afin de tomber sur le bon "index" dans la liste :

local indexChild = 0
for index,child in pairs(self.childDevices) do 
	if child.id==MonId then indexChild = index break end
end

et ENFIN pouvoir faire :

self.childDevices[indexChild]:getVariable("MaVar")

 

[Lazer]

A la fin de la consigne manuelle, pour moi, la zone revient à la programmation horaire préenregistrée.

A tester.

 

Pour les child, il faut te construire un tableau index des childs pour pouvoir y accéder rapidement sans devoir parcourir la liste.

 

Ensuite, chacun de mes child charge ses propres variables et les conserve dans son instance (self.mavariable), du coup le parent peut y accéder directement : child.mavariable (en supposant que child pointe sur la bonne entité, cf la suggestion du tableau indexé)

[jjacques68]

il y a une heure, Lazer a dit :

our les child, il faut te construire un tableau index des childs

truc comme ça :

 

(dans le onInit() du Parent)

for id,child in pairs(self.childDevices) do 
        self.ListeChild[id] = id
end

et pour accéder au child depuis le parent : 

self.childDevices[self.ListeChild[MonId]]:getVariable("MaVar")

 

EDIT :

 

nan mais attend c'est con mon truc !!

autant faire directement :

 

self.childDevices[MonId]:getVariable("MaVar")

 

Modifié le 25 mars 2021 par jjacques68

[Lazer]

Tu construits le tableau que tu veux en fonction de l'index que tu vas utiliser. Ce n'est pas forcément l'id, ça peut être autre chose, tout dépend de ton besoin.

Par exemple dans mon QA GCE, l'index du tableau, c'est le port de l'IPX800 (ou de l'EDRT2).

Ex : myTable["A1"] pour le child qui gère l'entrée analogique n°1.

Etc...

 

La limite c'est ton imagination

 

[jjacques68]

oui je comprends tout à fait.

Je sais pas pourquoi sur ce coup là, j'ai chercher à faire une grosse m...

Au bout d'un moment, les neurones suivent plus  

 

PS : pour info, 

 

quand une zone est sur OFF, à la fin d'une consigne manuelle, elle reste sur OFF.

J'ai testé 2 fois, ça semble bien être ça.

[jjacques68]

Il y a 2 heures, jjacques68 a dit :

PS : pour info, 

 

quand une zone est sur OFF, à la fin d'une consigne manuelle, elle reste sur OFF.

J'ai testé 2 fois, ça semble bien être ça.

ah ben mince alors !

non ! y a un soucis en mode OFF.

La zone est marqué OFF mais la consigne est quand même envoyée... !!??

 

pff punaise, bin je regarderais ça demain...

[jjacques68]

BON ALORS (j'en ai plein le c... de ce climatPanel)

 

S'ils y en a qui prennent le train en route :

je cherche à arrêter une zone de chauffage équipées de têtes Danfoss.

Le soucis étant qu'il faut envoyer une consigne aux têtes pour leur dire de se fermer.

Le minimum qu'accepte la tête est 4 °C, je mets 5 parce que voilà  

Tout en pouvant lui envoyer un ordre manuel si ça me chante.

 

il faut savoir 3 choses importantes :

 

la première : 

 

lors du changement de mode (je parle du "properties.mode" = OFF, HEATING, COOLING, AUTO), le panel envoie SYSTEMATIQUEMENT le "properties.mode" ET le "properties.currentTemperatureHeating" au thermostat associé de la zone.

Je rappelle que "currentTemperatureHeating" est la température défini dans le panel à l'instant T.

malheureusement, l'ordre d'envoi n'est jamais le même !!!

un coup, c'est la température qui est envoyée en premier, un coup c'est le mode !!??

 

la deuxième : 

 

qu'on soit dans n'importe quel mode dans le panel, il envoi SYSTEMATIQUEMENT aux thermostats, le "properties.currentTemperatureHeating" à chaque "setPoint" (les 4) !!

 

la troisième :

 

comme disait @Lazer : à la fin d'une consigne manuelle (donc là on est sur le mode "Schedule/Manual/Vacation", attention c'est pas la même propriété dans l'API), le panel envoi aussi le "properties.currentTemperatureHeating".

Si on était sur OFF, le panel reste sur OFF mais il envoi quand même le currentTemperatureHeating ???

 

 

Voici les 2 méthodes utilisées par le QA thermostat (Child), que j'ai modifié pour tenir compte de ces.. désagréments :

 

class 'HEAT' (QuickAppChild)

function HEAT:__init(device)
    QuickAppChild.__init(self, device) 
    self:trace(string.format("[%s] %s - init" , self.id, self.name))
end

function HEAT:onInit() 
  self.ListeValve = json.decode(self:getVariable("valveID")) 
end

--[[---------------------------------------------------------------------------------
handle action for mode change 
-----------------------------------------------------------------------------------]]
function HEAT:setThermostatMode(mode)
    self:updateProperty("thermostatMode", mode)

    --par rappot à moins explication N°1 :
    --SURCHARGE DE LA TEMPERATURE au cas où le setHeatingThermostatSetpoint tombe APRES le changement de mode    
    if mode == "Off" then 
        setTimeout(function() self:setHeatingThermostatSetpoint(5) end, 50)
    else
    	--pour les autres modes, obligé d'aller récupérer le currentTemperatureHeating dans le panel
        local currentTemp = api.get("/panels/climate/"..self.properties.climateZoneId).properties.currentTemperatureHeating
        setTimeout(function() self:setHeatingThermostatSetpoint(currentTemp) end, 50)
    end
end


--[[---------------------------------------------------------------------------------
handle action for setting set point for heating
-----------------------------------------------------------------------------------]]
function HEAT:setHeatingThermostatSetpoint(value) 

    --par rappot à mon explication N° 2 (à cause des setPoint) et 3 (à la fin d'une consigne manuelle) :
    --surcharge de la température au mini si on est sur "Off"
    value = self.properties.thermostatMode == "Off" and 5 or value

    self:updateProperty("heatingThermostatSetpoint", value)
  
    --envoi de la consigne aux têtes
    fibaro.call(self.ListeValve, "setHeatingThermostatSetpoint", value)
end

 

Voilà, à chaque fois je crois que c'est la bonne... donc je dis plus rien...

J'attends de voir ce que ça donne...

Mais alors le jour où on fait cohabiter une clim.......... 

Pourtant j'ai pas l'impression de vouloir faire compliquer...

[Lazer]

Quand je vois les comportements à priori aberrants, je me dit que le panneau des zones climatiques est peut être buggué, donc attention.

Et puis, il faut aussi distinguer les actions qui sont effectuées automatiquement par la zone (ex : changement d'heure programmée => nouvelle consigne), et les actions effectuées manuellement par l'utilisateur via l'interface Web.
Ce sont 2 choses différentes, l'une peut être bugguée, pas l'autre (ou les 2 lol)

 

As tu regardé dans le Swagger si cet aspect est documenté ? (j'en doute, le swagger n'est pas assez complet à mon gout, mais ça mérite de vérifier)

 

[jjacques68]

J'ai tiré ces conclusions en suivant dans l'API chaque cas possible :

 

 

il y a 5 minutes, Lazer a dit :

je me dit que le panneau des zones climatiques est peut être buggué, donc attention.

oui !! je pense aussi.

si un jour ils corrigent ça, j'ai tout dans l'os, je peux juste refaire...

Et ça pourrait bien arriver.

 

il y a 6 minutes, Lazer a dit :

il faut aussi distinguer les actions qui sont effectuées automatiquement par la zone, et les actions effectuées manuellement par l'utilisateur via l'interface Web.

c'est plutôt suivant l'endroit où tu te trouves, tu n'as pas les mêmes options.

Mais le comportement reste identique (à première vue)

 

il y a 7 minutes, Lazer a dit :

le swagger n'est pas assez complet à mon gout, mais ça mérite de vérifier

le swagger est un outil absolument génial, mais la doc y est nulle de chez nulle.

 

 

 

 

PS : j'ai aussi des incohérences avec le gartenPanel...

[Lazer]

Mouais, ça va changer.... déjà ils ont identifié un bug avec les modules liés dans les zones de climat :

https://forum.fibaro.com/topic/53994-virtual-thermostats-do-not-triggered-after-update/?do=findComment&comment=228966

 

C'est pas encore bien sec tout ça.

[jjacques68]

pour info, mes dernières modifications concernant le pilotage du climatePanel fonctionnent parfaitement bien. 

suite aux prochaines mises à jour...