Je reviens sur le sujet de ce post ; Avec tous les pb netatmo j’avais un peu délaissé le suivi des erreurs et de ce qui fonctionne VS ce qui ne fonctionne pas.
Cependant depuis plus d’un mois j’ai une situation stable dans tout ce qui est état des commandes (le planning, la température de consigne, la température, la puissance).
Je peux changer le planning sans problème
Cependant j’ai systématiquement des erreurs lorsque j’essaye de faire des commandes sur la commande Thermostat pour établir une nouvelle température de consigne.
L’erreur est celle de ce post → Erreur exécution de la commande [AAAA][BBBB][Thermostat] : Erreur lors de la requete à Netatmo : {« state »:« nok »,« error »:« Can no get netatmo server : [object Object] »}
J’ai beau être en debug dans les logs : Rien d’autre. Est-ce une erreur côté Jeedom ? côté Netatmo ?
J’ai cru comprendre que Jeedom avait mis des limitations (réponse de Loïc) : Pourrait-on être dans ce cas ?
Je n’ai pas de scénario qui fait des demandes de rafraichissement, cependant j’ai beaucoup d’équipements Netatmo (4 maisons avec 10 vannes, 2 thermostats, 2 stations Netatmo, etc…) donc cela fait de fait je suppose bcp de requêtes « à la base » : Est-ce que cela pourrait être l’origine de l’erreur ?
Je viens d’essayer de mieux comprendre le fonctionnement du plugin ; Je crois comprendre que tout passe par un dialogue entre la Jeedom box<>cloud jeedom (un « service netatmo »)<>serveurs netatmo (API). Aucune interrogation directe chez netatmo désormais.
L’erreur est donc retournée par le cloud jeedom ; Mais est-ce la limitation de Netatmo ? de Jeedom ?
Peut être « trop de requêtes » (comme évoqué en raison du nombre d’équipements).
Je ne pense pas être dans ces ordres ; par ailleurs contrairement à ce que d’autres ont dans leur log le message d’erreur ne parle pas d’erreur de quotas.
Si c’est une restriction en amont côté Jeedom : Est-il possible de faire évoluer le nombre de requêtes autoriser par Jeedom en fonction du nombre d’équipements pour plus d’équitabilité ? (voir à un modèle « payant premium » si nécessaire pour le financement)
Est-il possible de détailler [object Object] qui se trouve dans le log pour mieux comprendre l’erreur ?
Bonjour
Ce n’est pas un soucis de quota sinon le message serait plus clair. Ça doit plus être que netatmo n’aime pas la requête. Je vais regarder pour vous envoyer un message d’erreur plus clair.
Selon la documentation de Netatmo (Ici)
Voici la syntaxe attendue :
POST /setroomthermpoint Control the heating of a room
This endpoint permits to control the heating of a specific room. A room can be set in 3 differents modes:
« manual » mode in which setpoints can be applied for a specific duration (use endtime)
« max » mode which will put the setpoint at max (30°) for a given duration (default is xx and can be changed by the user in its settings)
« home » mode which basically makes the room following the Home mode.
Comme ça j’ai l’impression que la requête envoyée est correcte et conforme à la documentation de l’API ; Donc je ne comprends pas ce qui est incorrect !!! Soit je loupe qqch dans la documentation et la requête envoyée ; Soit l’API Netatmo est vraiment « naze » ?!?!
Je viens d’essayer avec une autre commande : la commande Thermostat (toujours sur une tête thermostatique). La requête qui sort est :
Je viens d’essayer depuis la page netatmo et la fonction « Try it Out » avec les paramètres home_id & room_id et PAF ! Même erreur ! Donc c’est bien la réponse Netatmo !
Bonjour,
Si c’est un soucis coté netatmo c’est mort il réponds quasiment pas deja quand tu as un soucis avec leur produit alors avec l’api dont ils se foutent completement tu auras jamais de réponse.
Par contre le retour de l’api indiquerait que le module que tu veux piloter ne peut pas recevoir ce type d’ordre tu es sur qu’il peut ? Ils ont plusieurs niveau de device dans leur api (c’est pas très clair d’ailleurs), l’applique tu sur le bon ?
J’ai beau re-re-re-lire, je respecte (comme le plugin d’ailleurs) la logique de fonctionnement indiquée : Une température ou un mode (home/manual/max) appliquée à une pièce équipée d’un produit « NRV »
En tout cas un grand merci d’avoir ajouté dans les logs l’erreur : Je pense que ça aidera grandement d’autres utilisateurs.
Sur un autre sujet, utilisant le thermostat modulant (OTM) au lieu du classique (NAPlug) je me rends compte que l’équipement (qui représente un pièce) n’est pas créé dans le plugin ;
Est-il possible d’essayer d’appliquer la même logique lors de la découverte d’un module « OTM » que lorsqu’il y a la découverte d’une vanne « NRV » ;
En effet quand je regarde le format de réponse « /homestatus » → J’ai l’impression que les données du Thermostat modulant (OTM) ont la même syntaxe que les vannes « NRV » / Donc plus proche de NRV que du Thermostat Classique (NAPlug).
Je pense ; Il faut plutôt copier la conf NRV en OTM (Sauf pour Puissance)
Pour le nouveau thermostat modulant : Netatmo a pris la nouvelle logique créée pour les vannes.
J’ai testé en local ça a fonctionné (ajout du JSON copié depuis NRV, puis 2 modifs dans netatmo_energy.class.php pour faire les mêmes actions que quand le type est NRV).
L’OTM nécessite un codage, une configuration spécifique !, une distinction des équipements quui lui sont associés… en particulier pour les commandes actions.
Franchement pour l’avoir fait , bon courage.
Ca semble passer ; Petit problème d’affichage de l’équipement (détail; je vais essayer de faire la maj sur Github)
Par contre j’ai voulu faire une modification plus substantielle sur le fichier « desktop/php/netatmo.php » pour ajouter dans le bloc « Informations » l’information sur
J’ai fait un ticket chez Netatmo concernant l’API et le problème rencontré. A ma grande surprise j’ai reçu une réponse rapidement (<24h) et qui semble clair !
J’ai testé avec la fonction Try it out de leur site (dev.netatmo.com) → Je confirme la solution
En effet selon le Type de Thermostat Netatmo dans l’installation → L’appel à l’API pour régler la température change !
Si l’installation est un Thermostat classique NATherm1 (Relais NAPlug) → Il faut utiliser le Endpoint « /setroomthermpoint »
{« home_id »:« XXXXXXXXXXXXXXXXXXXXXX »,« room_id »:« YYYYYYY »,« mode »:« home »}
Si l’installation est un Thermostat modulant OTM (Relais OTH) → Il faut utiliser le Endpoint « /setstate »
Pour la commande Consigne :
{« home »: {« id »: « XXXXXXXXXXXXXXXXXXXXXX », « rooms »:[{« id »: « YYYYYYY »,« therm_setpoint_mode »:« manual »,« therm_setpoint_temperature »: 15}]}}
Pour la commande Auto
{« home »: {« id »: « XXXXXXXXXXXXXXXXXXXXXX »,« rooms »:[{« id »: « YYYYYYY »,« therm_setpoint_mode »:« home »}]}}
Je sais que ça fait des modifications substantielles, mais est-ce envisageable d’intégrer cela en bêta ?
Je viens de comprendre comment fonctionnait le bloc informations ; Et les 2 niveaux (1er niveau logicalID / Configuration). Je ferais des propositions si besoin sur Github
Pour l’envoi du fichier de réponse Netatmo : Pas de souci ? Juste sur quelles modalités (pas de MP email sur support Netatmo) ?
