jjacques68

mouai c'est définitivement mort pour le allone pro. Même le plugin sous jeedom précise clairement que ça ne fonctionne pas avec le pro (le pas pro si). encore un abus du therme "pro" qui veut rien dire. Aucune interaction possible non plus avec IFTTT. Via les assistants vocaux si, mais avec leur propre plugin. Bref, maintenant je tourne la page.

pour info, mes dernières modifications concernant le pilotage du climatePanel fonctionnent parfaitement bien. suite aux prochaines mises à jour...

hé hé : réponse du support Orbivo à ma demande de doc :

je sens que je vais l'entendre souvent celle-là... c'est pas bête et y a moyen avec windev. Mais pas trop envie là. J'en fais assez au boulo... Et j'ai quand même un sérieux doute sur la possibilité de lui causer directement. L'expérience de couper le net était plutôt très clair. nan mais ça fait chi... !! moi qui pensais avoir un os à ronger après le coup du climatePanel... Suis déçu.

oui oui je parle bien du Orbivo - modèle Allone Pro !! Mais visiblement le modèle précédent permettait d'être attaqué par UDP, alors je me suis dis celui-là aussi mais non...

Merci !! Je l'ai installé. J'ai plus ou moins le même résultat. Toutes actions sur l'application partent vers internet. Rien vers le device locale. C'est pourri ça ! je m'y attendais pas... en même temps à 29 €

Bon ben c'est mort à mon avis. J'ai un nokia 6, j'ai pu essayer avec tpacketCapture. Je vois des trames partir de du téléphone vers internet quand je manipule le device. Mais rien directement vers lui ou en provenance de lui. Je comprenais pas. J'ai couper la connexion internet de la maison. Et là surprise, plus de réponse du device quand je le manipule. Conclusion, ça passe 100 % par le net ??

sur iphone ??

@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