SebDel

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.