Anomalies constatées sur mise à jour du 1er décembre

J’ai exactement les mêmes versions que toi :

  • Linux raspparis 5.4.72-v7l+ #1356 SMP Thu Oct 22 13:57:51 BST 2020 armv7l GNU/Linux [10.6]
  • Jeedom 4.1.16
  • Version database 10.3.25-MariaDB-0+deb10u1
  • Apache 13
  • Version PHP 7.3.19-1~deb10u1

Quelle est ta version d’apache ?

J’ai donné un petit coup de « apt update » et « apt full-upgrade » mais il y avait juste un upgrade nodejs mineur. J’ai même rebooté avec un suivi de près de mon syslog. Rien d’anormal.

Même problème après ces manips. Faudrait pouvoir tester hors plugin et même hors jeedom mais sur le système en php ou python et ligne de commande.

Décidément ça ne s’arrange pas, je refaisais un essai en mode debug pour rejeter un oeil sur le log et ça me donne ça :

[2020-12-03 19:26:36][DEBUG] : execute Action : setmode sur: Confort Ruisseau
[2020-12-03 19:26:36][DEBUG] : changeHomeTherm action: away- endtime: - sur: Confort Ruisseau
[2020-12-03 19:26:36][DEBUG] : getClient start
[2020-12-03 19:26:37][DEBUG] : makeRequest error 41: endtime in past at "/api/setthermmode"
[2020-12-03 19:26:37][ERROR] : Erreur exécution de la commande [Maison][Confort Ruisseau][Set-Mode et ou Fin de mode] : error: endtime in past at "/api/setthermmode"

Pour que je comprenne ce qu’il se passe il faudrait que le log en DEBUG raconte plus de choses en fait.

Bonjour les logs sont assez clair.
Le serveur a répondu "endtime in past at…’’
La valeur saisie est dans le passé.
Tu as fait ça depuis la tuile ?

Le plugin naEnergie fonctionne en php et un peu de js. Donc quelques soit la config, il devrait fonctionner correctement. Seule la tuile pourrait poser problème entre V3 et V4 à cause des styles imposé dans le core V4. Il ne faut pas perdre de temps là-dessus.

bien sur !

On va attendre la réponse de @Niceday mais quoi qu’il en soit, on trouvera la solution.

SI non tu n’utilise pas le webhook ? Je n’ai pas vu de traces dans les logs ! Pour rappel il faut avoir un accès externe sur port 80 ou 443 et le cronhourly activé. Mais cela ne va pas corrigé le problème.

Il faudrait pouvoir vérifier dans ton log en mode DEBUG le POST qui est effectivement réalisé à savoir dans le cas précis qui nous occupe :

https://api.netatmo.com/api/setthermmode?home_id=5c484cb1f1c1e00a008b4f58&mode=away.

Cette URL donne satisfaction sur un test unitaire.

N’oublie pas qu’une fois le POST réalisé tu fait un get qui malheureusement retourne systématiquement que je suis en mode « schedule » alors qu’on attend le mode « away ». C’est ce qui se passait sur mes premiers tests quand j’ai acheté le plugin. Quand bien même il faudrait un délai le post devrait finir par porter ses fruits ce qui n’est pas le cas chez moi.

Pour rester positif n’oublions pas que les autres commandes action fonctionnent (sauf peut etre mode forcé qui m’a fait une erreur 500 sur un test en passant). Les réglages de consignes, la marche/arret du thermostat, le retour en schedule, …tout ça marche sans problème…

Je pilote Jeedom avec Slack et Alexa donc les ports sont bien ouverts pour un accès externe avec webhook. C’est quoi ton idée ? Si ça peut aider à diagnostiquer…

Pour le plugin NaEnergie
Quand tu exécuté l’action ‹ away ›
1-Le plugin vérifie la validité des infons
2- il exécute la requête
3- l’api vérifié la validité des infos et qu’il est possible de l’executer.
4- soit tout va bien, l’api répond ‹ ok › soit il y’a un souci et l’api répond avec un message d’erreur.

Si la réponse est ‹ ok › on temporise 3 secondes pour éviter les collisions avec le retour webhook et parce-que les actions ne sont pas prise en compte instantanément par les serveurs Netatmo. Si la réponse n’est pas ‹ ok › le plugin affiche l’erreur.
Dans ton cas les 4 premières étapes sont bonnes l’api répond OK ce qui veut dire qu’elle a accepté la requête du mode away sauf qu’elle ne l’applique pas.
Dans l’immédiat je ne sais pas pourquoi ! Et pour l’instant je n’ai pas de retours similaires.
Donc on verra ce week-end éventuellement on me donnant accès à ton thermostat pour essayer de comprendre le pourquoi.

Bonne nuit.

Je comprends parfaitement ce que tu écris et rien de nouveau sous le soleil. Je reste convaincu de l’intérêt qu’il y aurait à tracer le POST pour vérifier que la « requête » est bien celle attendue. Un ok signifie qu’il a réussi à faire quelque chose mais je serai rassuré de connaître les éléments qui lui ont été soumis. Si j’ai le temps je vais écrire un bout de code php à exécuter en ligne de commande, en dehors de Jeedom : authent + setThermMode pour être certain que mon OS réagit correctement.

Merci de ton implication et bonne nuit également !

Bonjour @limad44,

Pour info je me suis fait hier soir un petit script php (à partir de l’API Netatmo-API-PHP) à exécuter en ligne de commande pour exécuter les requêtes sur mon thermostat. Il fallait que je fasse ce test unitaire sans Jeedom et sans plugin directement appuyé sur mon OS à base de GET et POST réalisé avec curl pour vérifier que la base était saine.

Toutes le fonctions marchent bien. Le changement de mode en particulier se fait sans difficultés.
On va dire que ça c’est fait :wink:

@+

1 « J'aime »

Problème solutionné par MP.

1 « J'aime »

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.