SebDel

Bonjour Lazer, Merci pour le développement de ton explication, tout devient cohérent. Venant en partie de la HC2 et du code que l'on utilisait à l'époque, c'est vrai que les interactions était souvent entre le device virtuel et un module physique. D'où l'habitude du getValue et setValue que l'on retrouvait un peu partout. Dans la logique des QA aujourd'hui surtout avec les capacités d'interaction avec les childs cela devient presque naturel d'utiliser les propriétés sur le fond, un peu d'ailleurs comme les variables persistantes que nous n'avions pas directement sur la HC2. En tout cas la structure des QA permettent de restructurer l'ensemble des concepts sur des schémas plus cohérents et j'espère pérenne... A+ Séb

Bonjour Henri, Je pense que ca fait un bout de temps que setvalue ne doit plus être utilisé, mais en y regardant de plus prêt, c'est peut être dans l'instance du child, celui que l'on dérive dans les QA qui ne doit plus avoir de setValue systématique. Cela a du être remplacé par l'updateproperty avec "value" en dernier paramètre. Ce qui permet aussi de récupérer les autres properties de la même manière. A+ Séb

Bonjour Lazer, A vrai dire j'avais 2 boxes actives à la maison, HC2 et HC3 et de mémoire je faisais le taffe sur la HC3 et je rebalancer en live sur la HC2 avec des requêtes pour mettre à jour les valeurs sur HC2, mais comme j'utilisais les données brutes, je ne me suis pas rendu compte du problème. En revanche depuis la semaine dernière, ma HC2 a crashé et j'ai du faire un recovery en 3.584 (avant 3.60) et du coup je suis bloqué avec les mise à jour (on me propose plus que la 4.07). DOnc j'ai basculé ce qui me resté de device sur la HC3 et j'ai du utilisé les valeurs en local de la HC3 qui n'était plus à jour. Tout ca pour dire que effectivement, cela doit faire un bout de temps que cela ne marche plus, mais en réalité, dans le boulot que vous avez fait qui est superbe, le setValue appelle une méthode de la class du child du QA et ce dernier utilise bien updateproperty. Donc le dysfonctionnement ne doit pas venir directement de l'appel de méthode mais plutôt que le child, depuis une mise à jour de la box 5.XXX, n'implémente plus la fonction setvalue pour ce child et donc la méthode de la class override n'est même plus appelé. J'ai recopié le code qu'il y avait dans la class du child directement dans la reponse au niveau du QA et ca remarche. Effectivement aussi, pour l'histoire du token, j'ai du changer le comportement afin que je ne sois pas obligé toutes les 20 minutes, d'aller regénérée les id et token dans l'API de netatmo. (Le passage au management Legrand n'a pas arranger les choses depuis En tout cas merci pour ton retour. Amicalement Séb

Bonjour à tous, J'utilise la version la version 2.6 de netatmo weather (Gsmart et Lazer) station depuis quelques temps et bizarrement, lors des lectures des réponses de l'API qui remontent bien, les childs ne se mettent pas à jour malgré le setvalue qui va bien sur les bons ID. Est ce que c'est un bogue générique, ou cela est du à un changement récent de la manière de mettre à jour les childs ? Quand je récupére la value sur le child, il n'est pas mise à jour du tout. Par exemple un nouveau child est indiqué 0 et on n'arrive plus à pousser la value avec setvalue. Merci de votre retour si vous avez remarqué des bizarrerie du genre, même dans d'autre QA. SOLUTION ET RECTIFICATION : Je viens de trouver en fait le problème Les setvalue ne marchaient plus child:setValue("dead", not module.reachable) child:setValue(self.NetatmoTypesToHC3[data_type].value, value) child:setValue("batteryLevel", module.battery_percent) J'ai remplacer par : child:updateProperty("dead", not module.reachable) child:updateProperty(self.NetatmoTypesToHC3[data_type].value, value) child:updateProperty("batteryLevel", tonumber(module.battery_percent)) Et cela refonctionne comme avant. Si cela peut servir à tous ceux à qui le problème pourrait arriver. Bon après je ne suis peut être pas non plus à jour avec mon QA... Amicalement Seb

Bonjour, Je reviens sur le sujet car depuis la mise à jour 5.170.16 je vois bien tous mes qapps mais quand je clique dessus dans yubbi il me fait une erreur 404 not found sur l'url mobile/device/ C'est vrai pour tous les QA y compris celui du wheather d'origine... Une pastille ou il faut attendre un fix ? Merci à tous Séb

Bonjour. Je reviens pour faire part de mon retour d'expérience. Suite aux différentes erreurs type invalid_grant ou wrong status 1 du QA Netatmo, j'ai décidé de recréer une appli Netatmo complète, de supprimer l'ancienne et de reprendre le process client_id client_secret et les access_token et refresh token qui vont avec. Depuis les requêtes ont l'air de tenir, au moins déjà 24h... J'ai l'impression que le serveur Netatmo, avec mon ancienne appli avait du mal au niveau des autorisations et un simple reset du client ne suffisait pas. Après, mais c'est une supposition, là où avant il était possible d'attendre un certain temps avec le délai d'un access_token genre 15 minutes, maintenant le serveur ne tolère plus beaucoup de temps entre les requêtes. Pour l'instant je tourne au max toutes les 10 minutes et je récupère bien à chaque fois le refresh_token suivant sans erreur invalid_grant. J'espère que ça tiendra un bout de temps car beaucoup de process sur la HC3 dépendent des infos que l'API retourne (température, humidité et Co2 dans 4 pièces). En tout cas merci pour la lecture et j'espère que cette expérience fera gagner du temps pour ceux à qui le problème surviendra. A+ Séb

Merci Lazer, Je viens de parcourir le sujet et effectivement il y a l'air d'avoir des comportements étranges avec l'API. Depuis mon changement "reset" du client_id et client_secret, le QA à l'air de tenir le coup. Après pour l'expiration du token il est noté 18000, en secondes, cela fait 5 jours. Mais comme j'interroge toutes les 10 minutes, normalement il ne devrait pas y avoir d'expiration et la gestion du nouveau token est normalement prévu dans le process. Donc j'imagine que l'erreur "invalid grant" est du à autre chose... Possible qu'un certain nombre d'échec de leur API grille le client ID et qu'ensuite les tentatives de connexion sont blacklisté. Quand je suis revenu dans l'interface de Netamo dev, j'avais mon app qui est noté "Bad application" et désactivé... Un reset du client a peut être remis les choses en ordre. Par contre je n'ai aucune idée de ce qu'il c'est passé sachant que cela fait bien 3 ans que cela tournait sans soucis, en ayant fait la mise à jour du plugins avec la nouvelle authentification... Affaire à suivre... A+ Séb

Bonjour à tous, Depuis très peu de temps, après des années de bons et loyaux service, le QA Netatmo de GSMART (version 2.6), une fois les tokens régénérés dans l'API Netamo tiennent que quelques heures... Au bout d'un certain nombre de loop, je dirai une trentaine, l'API répond erreur 400 "invalid_grant". A priori cela se produit lors de l'appel de la fonction API REFRESH_TOKEN qui au lieu de recevoir les nouveaux tokens renvoi l'erreur. Je vais essayé comme un autre utilisateur de faire un reset du client_id dans l'API Netatmo pour voir si cela corrige la situation. Dans ce cas ça aura été plutôt un bogue chez Netatmo... Je vous tiens au courant. Séb

Bonjour à tous, Utilisant maintenant le module HEM3 (triphasé) sur ma HC3, il y a quelques temps (1 mois ou plus), mes modules distants de la box ont commencé sérieusement tous à posé problème. Depuis la mise à jour de la HC3 avec le nouveau diagnostique permettant l'analyse du traffic zwave, je me suis aperçu que la HEM3 était devenu très bavarde et qu'elle monopolisait une grosse partie des connexions. En fait je pense qu'elle n'avait même pas le temps de terminé qu'elle remettait la sauce au niveau transmission. Pour un usage toutes les 2 secondes, typiquement ca doit bien être l'origine du problème à savoir une saturation du réseau zwave avec les blocages qui en découlent. De mon coté j'ai fait, dans un script HC3, un petit process qui gère les paramètres de la HEM3 dynamique afin de faire un pooling variable en fonction des besoins. Genre toutes les 10 minutes quand pas necessaire d'avoir trop de précision et toutes les 15s quand j'ai besoin de consos plus fines. Evidemment je reste le moins longtemps avec un pooling court pour laisser le réseau reprendre ses esprit. Pourquoi est ce arrivé récemment, j'ai un doute sur une mise à jour récente qui a justement joué sur la dynamique du réseau. Ce que j'ai pu constaté aussi est que cela concerne les modules éloignés et potentiellement ceux qui pouvaient être relayés par d'autres. Il est dommage de ne pas avoir une map synthétique des échanges à l'instant T pour analyser et affiner les paramètres de communications. En tous cas je suis passé de 4600 requêtes par heure à 86... C'est pas pareil. Bon courage pour vos investigations

Bonjour, De mémoire, certains modules remontent si on les "dé-cache", j'ai souvenir que par défaut beaucoup sont en mode cachés voir disabled. Après ce module étant très versatile sur la HC2, il vaut mieux s'occuper de l'interroger plutôt que de le laisser décider des rapports à envoyer. A l'époque, j'avais juste un rapport qui remontait la puissance totale des 3 pinces et ensuite une routine qui interrogeait tous les paramètres qui m'intéressaient. Cela me permettait d'avoir pas trop d'infos circulant sur le réseau. Ma pince se trouvant proche du compteur donc loin de la box la connexion était pas top. Donc pour répondre à la question, oui les infos sont dispos sur la HC2 mais après une petite config de paramètres qui vont bien selon ton usage.

Bonjour, Ca c'est bien calmé, j'ai viré tous les accès à la box sauf le mien... Changé le mot de passe et l'identifiant pour plus de sécurité Le support Fibaro a été super réactif. Je passe petit à petit sur la HC3 mais encore beaucoup de boulot. Bonne soirée Séb

Bonjour Nico, Pour les raisons, principalement beaucoup de taf pour la migration et certaines incompatibilité avec des modules que j'ai fabriqué (arduino et RazB...). Après pour la version "moderne" j'ai une HC3 dans laquelle je migre mes modules petits à petits... Je ne voulais pas faire le boulot doublement. En fait ca m'est arrivé 3 fois avant hier. Une fois vers 7h du mat, une à 15H et une autre à 2h du mat le lendemain. A chaque fois il fait une sauvegarde notée 3.60->4.07 puis bosse pendant 1h, se termine par une erreur type 170 et restore tout seul en 3.60. Après le support m'a répondu aussi qu'il n'y avait pas de procédure auto et qu'il fallait que je repasse en recovery usine puis remettre ma dernière sauvegarde. Ca ne s'est pas reproduit depuis. Par précaution j'ai changer tous mes mots de passe et identifiants de mes utilisateurs courant. Je surveille pour voir si ça se reproduit encore !

Bonjour à tous, Depuis ce matin, ma HC2 qui est toujours, pour des raisons de compatibilité, est resté en 3.60, essaye de faire toute seule sa mise à jour en 4.07... Résultats des courses, j'ai plein de sauvegarde qui sont crées à chaque fois qu'une tentative est lancée, pendant 1h mon système devient indisponible pour finir en cacahuète et un redémarrage restore de la sauvegarde... J'ai l'impression qu'il y a une procédure distante qui est lancée par Fibaro pour contraindre les boxes à s'updater. Avez vous une solution pour éviter ces problèmes rapidement car toute ma maison se retrouve planté et toute la famille aussi... Ca devient l'enfer en fait. J'ai envoyé un message à Fibaro mais j'ai des doutes sur leur réactivité... Merci pour votre aide. Séb

Bonjour, Oui par 2 fois... Je pense qu'il doit y avoir sur le marché plusieurs versions de ce HEM. Le mien est référencé 1.5 et 3.43 au niveau de zWave. Actuellement je suis toujours obligé de faire une interrogation forcée. Sur l'appli je n'ai strictement rien de visible. @LazerBonjour, je m'occupe de mettre à jour mon profil.

Bonjour, Je viens de basculer un HEM Gen5 (version triphasé) de la HC2 vers la HC3. Je précise que sur la HC2, le module fonctionnait parfaitement. A priori le device apparaît bien sur l'interface serveur web mais pas dans l'appli mobile... Pas grave, j'ai fait un QA pour remonter tout ça. Je que je constate : - Une fois configurer, aucunes informations remontent en automatique... Même en réveillant manuellement le module. - Quand on utilise le bouton "interroger cet appareil" les infos remontent. - Je me retrouve avec une tonne d'enfants et de sous enfants dont les informations ne sont pas pertinentes (Volt, Ampère, Watt Kw/h) et rien n'est en fait au bon endroit. - Quelque soit le paramétrage (101,102,103) ce sont toujours les mêmes infos qui sont dispatchés. - Impossible de régler le paramètre 111, il remet un nombre négatif aberrant - Quand j'interroge l'appareil de façon régulière, le simple fait de redémarrer la box efface tous les historiques et remet le module en silencieux... Avez vous réussi à faire fonctionner ce module sur la HC3 ? Par voie de conséquence, je me suis intéressé à un autre produit (EcoJoko) mais malheureusement la sonde est composé d'un seul capteur et il marche très mal en triphasé du coup. De plus aucune API pour l'instant donc inintéressant au regard de nos applications sur la HC3. Donc je ne désespère pas refaire fonctionner le HEM sur la HC3 Merci à tous de vos soutiens. Séb

Bonjour Lazer, Je te remercie pour ta réponse, j'ai cherché toute la nuit... et en te faisant un QA de test avec la fonction getValue, je viens de tester et cela marche... Je pense que la différence par rapport à cette nuit, c'est que j'ai choisi le type "DeviceControl" dans le QA. Est ce que tu penses que cela peut avoir une importance quand on crée un Device type Du coup je viens de finir mon premier QA... Je suis content, ca marche super bien Merci à toi Séb

Bonjour à tous, Je viens de commencer à plonger dans l'univers des QA et je suis confronté à un problème "basique", je pense, mais que je n'ai pas réussi à résoudre avec les infos du net. Pour ce premier QA, qui devra actionner un variateur (qui sera dédié à une VMC 0-10V), j'ai besoin de récupérer un premier % d'humidité (QA Netamo child), un second, child d'un device implant avec la sonde, un troisième température (QA Netamo child) et enfin un quatrième température de la sonde de l'implant. Après un petit calcul simple et des conditions horaires je calcul une valeur % du variateur. J'ai commencé le QA mais je reste bloqué sur le getValue pour récupérer la valeur d'un autre QA. il me retourne un nil. Donc j'en déduis que ce n'est pas si simple et je n'ai pas trouvé comment récupérer dans mon QA la valeur ou les propriétés du Child du QA de netatmo et celui d'un device physique nom plus (l'implant). Je pense qu'une fois débloqué c'est 2 points de base, j'aurais le problème de comment envoyé la valeur au variateur... J'ai par ailleurs compris que l'expérience acquise dans les VD restera sur la HC... Merci d'avance. Séb

Pile poil... Bon pour l'instant avec mon module, ca va pas être violent, mais pour mon projet fini ca sera impeccable Merci

Bonjour Lazer, Merci pour ta réponse rassurante Je dois bientôt ajouter de nombreux modules qui viendront effectivement mailler un peu plus le réseau. D'après ce que j'ai compris aussi, les nouveaux modules zwave+ alimentés secteur vont aussi aider un peu sur la portée des anciens modules par relayage plus efficace. J'ai toujours espéré avoir un jour la possibilité de visualiser un jour tout le mappage réseau sur une carte dynamique mais pas encore trouvé... Merci à toi.

Bonjour à tous, Nouvellement propriétaire d'une HC3, je suis en train de prévoir la migration des modules de la HC2 qui tourne depuis quelques années. Pour l'instant, dans les modules physiques, il n'y a qu'un seul Wall Plug sur ma HC3. Je précise aussi que celui ci se trouve dans l'environnement proche de la box, quelques mètres... De temps en temps, pour une raison que j'ignore, la box marque le module comme déconnecté et, évidemment, il n'y a plus de communication avec la box, ni en direct, ni via GEA. Il faut que je fasse une reconnexion en cliquant sur le module via l'interface pour que ce dernier se retrouve à nouveau visible. Y'a t il une procédure particulière pour rafraichir périodiquement les modules physiques ou est ce un problème connu avec ce type de module (Fibaro Wall Plug). Merci d'avance pour vos retours. Séb

En fait je viens de m'apercevoir que ma règle fonctionnait, la différence avec avant c'est que la condition initiale était que le Sensor < 6.9 et le test secondaire que la prise était On. Quand j'allumais la prise à vide donc 0w de conso, la règle captait bien le changement de statut et 5 minutes après coupait. La avec la nouvelle version j'ai l'impression que le test Sensor et Value s'évalue en même temps et, du coup, il faut que le Sensor >6.9 ET Value =1 pour que la règle fonctionne. Dans les faits : Avant : J'allumer la prise sans consommer, elle se coupait à 5 minutes. Aujourd'hui : J'allume la prise sans consommer, elle ne s'arrête plus. Je consomme un peu (>6.9) ca marche. Est il possible que la logique de la règle (inclusif, exclusif, et, ou) soit responsable de la différence. Ensuite je peux toujours inverser le test D'abord Value puis Sensor mais, instinctivement, je pense que ca fera pareil. Pour revenir au principe d'avant je devrait peut être faire une deuxième règle qui coupe la prise quand elle est <6.9 et value 1 au bout de 4 minutes... J'ai encore plein d'autres règles à traduire et je pense que ce n'est pas mon dernier post à ce sujet... PS: Je viens d'installer le QA de Netatmo et j'ai un tour dans tes sources, je voulais te féliciter pour ton travail. Tous mes modules sont remontés immédiatement (Base + Extérieur + 3 additionnels). C'est beau ! J'ai aussi découvert avec plaisir que la nouvelle interface utilisée Angular 10, ce qui est gage d'une certaine pérennité. Merci encore.

Bonjour à tous, Je suis en train de porté mes devices HC2 vers une HC3. Bien entendu j'utilise GEA à outrance mais je suis resté avec ma HC2 en 3.60. Du coup le passage de mes règles en HC3 n'est pas si facile. Pour exemple : GEA.add({"Sensor-", id["PRISE_CELLIER"], 6.9}, 5*60, "", {{"turnOff", id["PRISE_CELLIER"]}, {"If", {{"Value+", id["PRISE_CELLIER"], 0}}}}) deviens GEA.add({{"Sensor-", id["PRISE_CELLIER"], 6.9},id["PRISE_CELLIER"]}, 5*60, "", {{"turnOff", id["PRISE_CELLIER"]}}) Je ne sais pas si je suis bon dans ma traduction compte tenu du fait que la prise s'arrête bien une fois et ensuite plus rien. La prise en question est un wallplug de 2014 donc première version. Avant la prise s'éteignait bien au bout de 5 minutes de non consomamtion autant de fois que nécessaire. C'est ma machine à café qui est dessus, donc une bonne vingtaine de fois par jours... Merci à tous

En effet, je suis d'accord pour l'utilisation en local. En ce qui me concerne, c'est surtout au regard des appels extérieurs de l'API que je forme à partir d'outils comme "Tasker" ou des PCs voir de mes voitures. Jusqu'à aujourd'hui j'ai du bidouiller une passerelle externe->serveur interne avec une authentification douteuse sur l'http de la box. J'avais imaginé qu'avec la nouvelle HC3, cela aurait pu être de l'histoire ancienne. Dans les faits je suis obligé de passer par un serveur tiers en SSL qui oeuvre effectivement en http en interne. Tant pis je continuerai comme cela. De toutes les façons, je ne voyais pas trop comment la box pouvait avoir un certificat valide pour le quidam sans passer par l'ID Fibaro que je ne souhaite toujours utiliser car de base pas secure. Bonne soirée Séb

Bonjour Lazer, Je vais donc essayé de mettre mon vrai email en API. A priori le certificat autosigné SSL n'est pas trop accepté dans le magasin des certificats de confiance... Je vais vois comment faire pour résoudre ce problème qui perdure depuis quelques décennies Un très bon Weekend. Séb

Bonjour à tous, Je découvre aujourd'hui pour la première fois l'interface de la HC3 et, bien entendu, la première chose que je viens de faire et de changer le mot de passe local et inscrire mon email. A ce sujet, pour l'email, la limitation du champ est très courte (30 caractères) et donc mon email ne passe pas... Y'a t il déjà une modification prévu ou allons tous devoir avoir une adresse du type "sh.ort@a.aa" ? Bonne journée