jjacques68

@Lazer J'ai regardé ton SDK, en effet, y a les DLL pour du dev sous windows, mais ça s'arrête là... pas d'explications supplémentaires à part comment utiliser les fonctions... ah moins de fouiller dans les fichier en C, mais là.... ôtes moi d'un doute : si je veux sniffer les échanges entre le Orvibo et mon téléphone, je place le PC sniffer, avec un "pont", entre le routeur principal de la maison et l'AP wifi où est connecté le device ? c'est bien ça ? si je me mets ailleurs, je verrais pas les trames !

@Barelle : ça passe avec les tostring() ou les "" Je sais pas ce que j'ai foutu. par contre il faut bien initialiser la variable avec "{}" et non "[]" dans l'onglet du QA. et visiblement les clé sont d'office des string et non des number. Après il est vrai que les variables QA sont un peu spéciales, tout est chaine de caractères... merci !!

J'ai tiré ces conclusions en suivant dans l'API chaque cas possible : 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. 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) 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...

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

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

j'avais essayé avec le tostring(), sans résultats... Mais faut que je refasse des essais...

avec le json.decode() !!

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.

ben !!! mais qu'est ce que j'ai foutu alors ?! dans l'ordre, j'ai créé la variable QA avec juste ça : "{}" ensuite je la récupère avec local MaVar = json.decode(selg:getVariable("MaVarQA")) ensuite j'ajoute une valeur : MaVar[8]="toto" ensuite je mémorise : self:setVariable("MaVarQA", json.encode(MaVar)) et quand je regarde la contenu de la variable j'ai : {"8"="toto"} quand après je relis la variable suivant la même méthode : MaVar[8] il me renvoi nil ???

mouais c'est pas mon cas.... Moi j'aurai aimé avoir comme contenu dans cette variable QA (qu'on s'entende bien, quand je dis variable QA, je parle de variables visibles dans l'onglet "variable" du QA) {[ID1]=toto,[ID2]=lulu} ça m'éviterait d'avoir à parcourir toute la table pour trouver ma valeur. J'appelle ID1 et j'ai directe "toto" Comme on fait normalement avec un tableau indexé ! Mais là je souhaite le ranger dans une variable...

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

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

Hello ! J'aimerais savoir si on peut (et comme le faire) pour stocker un tableau "indexé" dans une variable QA : par exemple : { [clé 1] = "toto" [clé 2] = "lulu" } J'arrive à stocker des tableaux classiques {..., ..., ...} Mais pas ceux-là... Le but étant après récupération avec le json.decode() de pouvoir faire un simple MaTable[MaClé]... merci pour votre aide...

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

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.

tu l'ajoutes par programmation ?

pas simple de créer un QA Thermostat Child (ou normal), on peut pas spécifier le "climateZoneID" lors de sa création. Et ce malgré : initialProperties = { supportedThermostatModes={"Off", "Heat"}, climateZoneId = 10, }, On est obligé de passer par le climate panel pour ajouter le thermostat dans la zone c'est reloud... ça "casse" un peu le côté générique de la chose

merci pour le SDK !! ben dis donc, je vois (physiquement) pas de différence entre le pas pro et le pro...

ben avec le SDK, je pourrais au moins savoir quelles trames font quoi... Mais j'ai pas. sur github, ça existe pour le modèle S20 (prédécesseur du Allone). ça avec ça que j'ai testé, mais rien... aucune réponse. j'espère avec wireshark chopper les trames que mon téléphone envoi vers cette boîte, et le port. Après je pense pouvoir me démerder... oh punaise mais on peut pas faire de l'UDP sur la HC3 !!!

ERRATUM, j'ai dit une bêtise. c'est le Orvibo Allone Pro que j'ai commandé. Le broadlink semble fermé de chez fermé niveau accès. Le Orvibo semble accessible via UDP sur le port 10000. Aucune doc officiel. J'ai contacté le support pour en avoir, mais je pense que je peux toujours rêver. Y a des pseudo script sur github en python, mais ça donne rien. Je sens que je vais me taper du wireshark et sniffer la com...

y'a encore plus jolie, on peut mettre la tête sur Off, on a un joli rond avec marqué off sur la HC3. Bon, la tête ne réagit pas à cette commande. Et garde la consigne précédente. Mais suffit de tricher et de lui envoyer 4° puis off, et le tour est joué

les têtes Danfoss font ça très bien, une fois par semaine elles font des allé/retour avec le press étoupe. Depuis que j'ai ces vannes, j'ai plus jamais eut de collement. Et en été elles sont fermées

c'est exactement ça. Et que pour ça. D'où mon hésitation à le faire, Mais je sens que je vais le faire...

@jang : waouh ! I must study this ... but it seems complex...

oui suis d'accord, la doc, pour bien comprendre : tu la lis dans un sens, puis dans l'autre, puis tu tournes l'écran de 90° et tu recommences. Quand tu as fini, tu sais plus ce que tu cherchais alors tu recommences...