Erreur: Can no get netatmo server

Je voudrais continuer à contribuer à améliorer ce plugin netatmo.

J’ai voulu poster une question dans les forums dédiés Aide Programmation

Mais l’accès est dédié uniquement aux développeurs de plugin à part entière ;
Est-il possible d’y accéder en tant que contributeur sur un plugin existant ?

En attendant ma question portait sur la génération des Cmd post-installation du plugin ;

Après l’ajout dans le json (config/devices/) du type d’équipement de la nouvelle Cmd, est-il possible qu’elle soit automatiquement créée sur les équipements du type concerné ?

J’ai essayé la synchro mais ce n’est pas suffisant ; Une autre alternative que l’éventuelle a suppression / re-création ?

Mon idée est d’ajouter le mode Hors-Gel sur NRV/NATherm1/OTM → Il peut être intéressant de désactiver le chauffage dans une pièce habituellement chauffée (option disponible dans l’application) ;
{
« name »: « Mode Hors-Gel »,
« type »: « action »,
« subtype »: « other »,
« isVisible »: 1,
« isHistorized »: 0,
« generic_type » : « THERMOSTAT_SET_MODE »,
« logicalId »: « mode_hg »
}

Bonjour,
Seul solution supprimer et refaire une synchronisation, c’est un défaut globale a jeedom, en faite si je force la réplication du Template de commande je vais écraser tous ce qui est personnalisation de l’utilisateur (visible ou non, historisé, widget…)

J’ai réalisé le comparatif des commandes entre vanne sur thermostat classique / versus otm ; Il y a une différence subtile sur le mode hors gel / mode absent.

Je pense que je vais soumettre une proposition pour améliorer la situation et mieux gérer le cas des installations avec la version modulante du thermostat ; j’ai vu qu’il y avait aussi qq coquille sur certaines actions modes qui ne peuvent pas fonctionner (que ça soit des vannes sur le thermostat classique ou modulant).

Pour la proposition en cours j’ai mis à jour les infos sur la raison du changement dans le refresh :

Bonjour,
Oui j’ai vu ton PR mais ya un truc qui me gene dedans :

Je sais pas si c’est volontaire ou non mais ca va casser la remontée des informations sur les capteurs d’ouvertures.

C’est vrai que je n’avais pas appréhendé dans l’analyse le fait que dans la partie « netatmo_energy » il y avait la gestion de certains aspects pour les appareils security (les capteurs de portes) vu qu’ils partagent le même point de terminaison dans l’API Netatmo (/homestatus)

Cependant la modification proposée porte sur la condition pour construire la liste des maisons depuis /homesdata (construction de la variable tableau $home_ids) qui sera parcourue dans la boucle suivante → foreach ($home_ids as $home_id) et faire les requêtes pour chaque maison (sur le endpoint /homestatus).

Au lieu de se baser sur l’existence de pièces, je propose de se baser sur l’existences de modules. Afin de ne pas/plus requêter des maisons qui ne sont plus actives (sans aucun modules)
Pour moi les équipements de la gamme « sécurité » sont aussi reliés à un bridge/pont/modules qui apparait dans la topologie retournée par l’API /homesdata.

Donc ça ne devrait rien changer à la liste $home_ids parcourue dans la boucle suivante (/homestatus) où seront récupérées les informations (qu’elles concernent la partie energy ou security).

A tester cependant, comme tout changement :wink:

Salut,

Ok j’ai validé par contre j’ai pas de quoi tester malheureusement j’ai rien de netatmo chez moi… Quelqu’un peut tester la beta de demain du plugin et voir si les tag sont correctement remontés ?

1 « J'aime »

Pour le moment je n’ai pas vu d’alerte ! Le changement semble fonctionner.
Pour ma part le nombre de requête a été réduit de plus de 50% !

Je ne sais pas si cela est visible ou quantifiable côté cloud jeedom.

Merci pour la revue de la PR #16

Je n’avais pas totalement fini :wink: je viens de pousser une autre PR (17) car je me suis rendu compte que les réponses de Netatmo pouvait être « status OK » mais avec un contenu d’erreur
Exemple :

 {"status":"ok","time_server":1709568528,"body":{"home":{"id":"XXXXXXXXXXXXXXXXXX"},"errors":[{"code":5,"id":"YYYYYYYY"}]}}

Cela arrive notamment si l’on demande d’appliquer le mode « hg » alors que l’équipement est déjà en mode « hg »

J’ai trouvé ceci dans la documentation dev.netatmo.com

{
status:{}
time_exec:{}
time_server:{}
errors:{
type:"array"
items:{
id:{
type:"string"
description:"device/module id that causes the error"
example:"00:04:74:00:01:00"
}
code:{
type:"integer"
description:"error code
* 1 - Unknown error
* 2 - Internal error
* 3 - Parser error
* 4 - Command unknown node module error
* 5 - Command invalid params
* 6 - Unreachable
"
example:6
}
}
}
}

Bonjour,
A oui j’ai été un peu vite la dessus désolé. Je viens de validé le PR. Merci encore pour ton boulot (et ton courage pour essayer de comprendre l’api netatmo…).

1 « J'aime »

Bonjour Loïc,

J’ai fait qq nouvelles améliorations concernant la partie énergie, et la caméra extérieure NOC.

Pour la caméra NOC : Principalement la gestion de webhook qui étaient reçu mais non exploités (donc maj du json de config du produit NOC).

Pour la partie Energie : J’ai basculé le code du refresh (qui n’est plus spécifiquement liés aux produits de la gamme Energie vers la classe principale du plugin). Cela permet aussi de mettre en cohérence le fait que des infos des produits de la gamme Sécurité (Door Sensor) étaient récupérés dans la partie Energie. Les « EndPoints » interrogés de l’API /homesdata et /homestatus ne sont pas spécifiques à la gamme Energie, mais commun à Energie & Sécurité.

J’ai remarqué que pour la partie Sécurité, il y a appel à un EndPoint qui est déprécié (gethomedata) - Donc à terme il faudra prévoir de traiter la récupération des infos via les 2 EndPoints (/homesdata et /homestatus) comme indiqué dans l’info /notice (« Now use Homesdata to get topology information and Homestatus to get the status of the home ») → Mais n’ayant pas une connaissance des produits Netatmo Sécurité (en dehors de la caméra) je n’ai pas engagé de modification.

Voilà, le tout est sur la PR18 : https://github.com/jeedom/plugin-netatmo/pull/18 que j’ai laissé en mode « Draft »

Pour finir j’ai eut des échanges avec Netatmo (via le canal support dédié aux développeurs/API Netatmo) concernant des différences des réponses entre ce que je testais en direct VS les réponses via le cloud Jeedom - Car la documentation n’est pas totalement exhaustive (sur dev.netatmo.com) malheureusement … /

J’ai questionné le sujet d’accéder au scope « access » (pour Jeedom SAS) qui permettrait d’aller bcp plus loin dans les infos récupérées → J’ai eut une réponse (de Leslie) mais j’aurais souhaité échanger en privé si c’est possible (MP) ?

Bonjour Loïc (et les lecteurs de post),

Je reviens sur le sujet initial du message d’'erreur de ce post je pense avoir diagnostiqué l’origine !

L’erreur se produit à 100% lorsqu’un des modules est en erreur ; Car la réponse (sur /homestatus?home_id=XXXXXXXXXXXXXX) contient dans la partie « body » un conteneur « home » (situation normale) mais aussi un conteneur « errors ».

Illustration avec 2 situations :
A) Situation normale (sans module en erreur)
{"status":"ok","time_server":1712614592,"body":{"home":{"id":"75d5","modules":[{"boiler_control":"opentherm","firmware_revision":25,"id":"70:xx:xx:xx:xx:xx","outdoor_temperature":13,"rf_strength":64,"type":"OTH","wifi_strength":57}],"rooms":[{"anticipating":false,"id":"599","therm_measured_temperature":21,}]}}}

B) Situation avec un module en erreur (module id 90:00:00:00:XX:XX) : La réponse contient bien le status des équipements, mais aussi un conteneur « errors » pour signaler le(s) problème(s) qui peuvent exister sur un/des équipements (avec la nature de l’erreur: Code 2 dans l’exemple ci-dessous - Inaccessible )
{"status":"ok","time_server":1712614592,"body":{"home":{"id":"75d5","modules":[{"boiler_control":"opentherm","firmware_revision":25,"id":"70:xx:xx:xx:xx:xx","outdoor_temperature":13,"rf_strength":64,"type":"OTH","wifi_strength":57}],"rooms":[{"anticipating":false,"id":"599","therm_measured_temperature":21,}]},"errors":[{"code":2,"id":"90:00:00:00:XX:XX"}]}}

Malheureusement je ne maitrise pas node.js ni le client http Axios utilisé par le cloud netatmo/jeedom.

Quand il y a une vrai erreur sur la requête /homestatus il n’y a qu’un conteneur « error » et rien d’autre;
Exemples :

{"error":{"code":1,"message":"Access token is missing"}}
{"error":{"code":2,"message":"Invalid access_token"}}
{"error":{"code":3,"message":"Access token expired"}}
{"error":{"code":21,"message": "Invalid home_id"}}
{"error":{"code":10,"message":"Missing home_id"}}"}

Il faut donc ignorer ou ne pas chercher error/errors sur le conteneur « body » ; sinon c’est là qu’on arrive au fameux :
{result : {state : "nok",error : "Can no post netatmo server : "+JSON.stringify(error?.response?.data)}}

J’espère que les infos sont suffisamment claires, je reste dispo si nécessaire !

Salut,

Désolé je suis completement sous l’eau avec la 4.4, j’ai regardé le code coté cloud et je ne regarde absolument pas le retour de netatmo et renvoi toi tel quel sauf si le code retour n’est pas 200 :

axios(options).then(function (body) {
return _callback({state : ‹ ok ›,result : body.data});
}).catch(function (error) {
return _callback({result : {state : « nok »,error : "Can no post netatmo server : "+JSON.stringify(error?.response?.data)}});
});;

Donc faudrait voir le code retour du serveur netatmo, en plus meme dans ce cas en cas d’erreur je renvoi le retour brute de netatmo (en texte ca je peux changer).

Ok je comprends ; Merci de continuer à suivre le sujet même avec un peu de délais :wink:

Ce soir, j’ai mis le nez dans Javascript & Axios (j’ai eut un peu de mal … c’est clairement pas mon truc le JS ; je préfère le PHP ! )

Le code status est bien 200 dans les 2 cas ; le code est bon et fonctionne avec les 2 JSON (même celui avec le conteneur errors).

J’ai failli abandonner puis j’ai refait des requêtes en direct vers Netatmo (via du curl) … Et là un truc m’a sauté aux yeux → Les délais de réponse !!!

Cela va d’une réponse instantané (<1s) dans le cas où aucun module est en erreur à plusieurs secondes (3 à 10s) quand un module est en erreur (je suppose que l’API essaye de lancer une vérification)

Y’a-t-il un timeout réglé côté instance Axios ? Par défaut il y aurait un timeout à « 0 » (donc pas de timeout) est ce vraiment le cas dans la mise en place côté Jeedom ?

Il est peut être possible d’améliorer le suivi d’un éventuel Timeout avec un code comme celui ci :

.catch(function (error) {
  if (error.code === 'ECONNABORTED') {
    console.log('Request timed out');
  }
else return error?.response?.data;
});

Src : How to handle Axios timeouts?

En complément, voici peut être les 3 erreurs qui seraient intéressantes à vérifier dans les possibles erreurs

| ECONNABORTED | Request timed out due to exceeding timeout specified in axios configuration. |
| ETIMEDOUT | Request timed out due to exceeding default axios timelimit. |
| ERR_NETWORK | Network-related issue.
| ERR_FR_TOO_MANY_REDIRECTS | Request is redirected too many times; exceeds max redirects specified in axios configuration.
| ERR_BAD_RESPONSE | Response cannot be parsed properly or is in an unexpected format.

Src → axios/README.md at 751133eb9ed794c6f6634c52f4fe116e33bf5f09 · axios/axios · GitHub

Bonjour,
Merci pour le retour, je viens de configurer le timeout pour netatmo il y a maintenant un timeout de 30s. Peux tu me dire si c’est mieux ?

var options = {
method: ‹ POST ›,
url: url,
headers: {
‹ Content-Type ›: ‹ application/json; charset=utf-8 ›,
‹ Authorization ›: 'Bearer '+_oauth.accessToken
},
timeout: 30000,
data : datas
}

1 « J'aime »

Merci !
Je vais surveiller plusieurs jours ; normalement j’avais toujours un fond d’erreurs « Can no get netatmo server » tous les jours (car j’ai une caméra qui plante svt).

Pour le moment, j’ai déjà eut une « vraie » erreur : {« state »:« nok »,« error »:« Can no get netatmo server : {"error":{"code":500,"message":"Internal Server Error"}} query : undefined »}

En parallèle, je vais regarder pour traiter le conteneur errors maintenant pour remonter les infos au niveau des devices

Merci hesites pas si besoin mais je pense deja la tu devais avoir plus d’information

Plus aucune erreur undefined depuis 3j ! C’est donc nettement mieux :wink:

Je finis la gestion des retours d’erreur (au moins pour la caméra NOC) et je fais une PR !

1 « J'aime »

Voilà c’est lancé sur la PR19 :wink:

Merci pour les échanges qui ont aboutis pour comprendre le pb du Timeout !

Super merci j’essaye de regarder dans la semaine (désolé pour le délai je suis en vacance et pas mal de travaux à faire).

Merci pour le timeout ça va me permettre de corriger d’autre truc je pensais que axios avait un tumeout infini par défaut et ça semble pas être le cas

1 « J'aime »