jjacques68

suis allé voir dans leur doc : biensûr dans la section scènes, y a rien dans les QA.

??? !! jusqu'à maintenant j'utilisais que l'ID du user !!

ben ça fait des mois et des mois que le sujet état clot. Il faut renseigner l'ID du user et non celui de device. En plus je viens de tester, si je mets l'ID du device, les push sont ok mais pas les mail, depuis un QA. Nan mais c'est ridicule, ça marche depuis une scène !? Maintenant je ne serais dire si c'est depuis la dernière mise à jour de la HC3 ou la dernière mise à jour de l'application mobile. Donc en attendant, il faut : - pour les push utiliser l'ID du device - pour les mail utiliser l'ID du user alléééé, on modifie les scripts...

alors ça ?? fibaro.alert("push", {2}, "essai") dans une scène c'est ok, mais pas dans QA !!! C'est nouveau, ça vient de sortir, c'est une promos ? EDIT : et j'ai supprimé l'application du téléphone, supprimé le device IOS dans mon user et tout refait... change rien EDIT 2 : en mettant l'ID du telephone et non l'ID du suer ça marche, mais on revient en arrière là ! on tourne en rond...

ah ?? ben alors ??

@flacon030, des news ?

oui je confirme, les notifications push ne passent plus. Les mail si.

C'est quoi le coup de l'IP locale, moi elle apparaît dans les preference, mais vu la le peu de réactivité, ça passe par le cloud, obligé !! PS : plus de notifications chez moi... Envoyé de mon iPhone en utilisant Tapatalk Pro

et puis c'est pas comme sur l'appli sur HC2, là on passe systématiquement par le cloud, même si on est wifi locale... je me trompe pas si ?

perso, moi non plus je suis pas fan de cette appli... Et elle rame je trouve.

Es-tu sur de la configuration du body justement dans IFTTT, tu as des captures plus haut dans le topic pour comparer... Envoyé de mon iPhone en utilisant Tapatalk Pro

hmm... ton user utilisé dans IFTTT a bien les droits sur le QA ? Dans IFTTT, tu vois une erreur si tu vas dans la vue de l'activité ?

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