Lazer

Ah bah voilà..... j'ai tenté maintenant de me connecter à mon compte sur Enlighten : https://enlighten.enphaseenergy.com Il me dit que mon compte/mot de passe n'existe plus ! Du coup je fais la procédure de réinitialisation du mot de passe, c'est OK, et ensuite je tente de me reconnecter, et message d'erreur qui tue : Too many active sessions.. Donc... j'ai désactivé le QuickApp, on va attendre quelques heures ou jusqu'à demain....

Test EDIT : @jojo C'est OK tu devrais pouvoir répondre maintenant

Au décodeur JWT, mon Token expirait cette nuit vers 3h du matin, donc c'est cohérent.... le truc pas normal c'est que l'authentification du QA échoue pour générer un nouveau token (code HTTP 401) Si je me connecte avec le même compte manuellement sur l'URL, en suivant les indications de la doc Enphase "Accessing IQ Gateway local APIs and local UI using token" datée de Juin 2025, l'authentification est OK, cependant impossible de générer le nouveau Token car la liste "Select System" reste désespérément vide (testé avec Firefox et Chrome). Je me souviens avoir eu ce problème dans le passé, je ne me souviens plus comment je l'avais résolu....

Test EDIT : ça fonctionne.... @jojo il faudra me dire quel message STP pour que je puisse reproduire le bug

Ce qui est intéressant, c'est que le Modbus reste bien actif, puisque le Victron Cerbo GX arrive bien à remonter la production en temps réel. Je me demande si je ne vais pas utiliser Modbus pour mon QA, au moins ça sera 100% local, indépendant du cloud et d'un token à renouvelle tout les X temps...

Bon bah.... moi aussi problème depuis ce matin avec la passerelle Envoy Sur mon QuickApp, message d'erreur : Impossible d'obtenir le token : Code de statut HTTP = 401 Et évidemment la récupération du nouveau token qui échoue, ça tourne en boucle. Il va falloir que j'investigue...

Test de code : print("Hello World") EDIT : voilà c'est OK maintenant pour insérer du code, désolé pour la gêne occasionnée. Pour l'explication, c'est le WAF (Web Application Firewall) installé sur mon serveur en frontal devant le serveur Web qui a une politique de sécurité très agressive de base. Je dois donc le configurer au fur et à mesure pour que les différentes fonctionnalités du forum puisse passer sans souci. EDIT 2 : avec un emoji pour voir si ça passe 😃

@jojo Attention, tu as encore tes chats noirs chez toi

Comme dit sur l'autre topic, suite à la migration du forum il faut que tu partages toutes les infos utiles si tu veux que je puisse dépanner : code erreur, screenshot, URL, et aussi la date et heure précise pour m'aider à trouver dans les fichiers journaux.

J'ai changé les paramètres d'envoi des emails, via le serveur relai SMTP d'OVH, donc espérons que ça soit mieux. En revanche, comme je l'évoquais il y a quelques jours, il faudra que je prenne un abonnement spécifique pour l'envoi des emails, c'est moins cher que l'hébergement, mais ça reste indispensable... car impossible d'envoyer les emails directement depuis chez moi, mon IP publique n'est pas réputée fiable et serait bloquée par la quasi-totalité des filtres anti-spams.

Le forum est migré sur mon serveur et devrait de nouveau être accessible publiquement, j'espère que tout se passera bien. N'hésitez pas à me remonter tout dysfonctionnement : lenteur, comportement anomal, plantage, erreur, etc. Avec capture d'écran, et URL si possible pour aider le diagnostique, merci

Joyeux anniversaire @mprinfo

Dans 3 semaines (je vais encore changer de boite, d'une certaine façon je serai donc au chômage jusqu'au 31 août)

Un serveur oui, car il est construit pour (flux d'air de ventilation, installation dans un local climatisé, etc) Encore que... rien n'oblige à l'utiliser à 100% de ses capacités CPU, en pratique c'est une question de rentabilité financière de l'investissement. Mais là, on parle d'une box domotique, pas d'un serveur. Déjà, ce n'est pas normal que le CPU de la box de Jojo se soit mis à tourner autant, et ensuite, la conséquence directe, c'est un ralentissement général (interface web, exécution des scénarios, etc). Donc un service dégradé, et ça n'est pas acceptable. Remarque : c'est pareil pour un serveur, s'il est tout le temps à 100%, le service rendu aux utilisateurs sera dégradé, leur productivité va baisser, les gens vont râler, etc. A l'inverse, pour un serveur de calcul qui ne fait rien d'autre que calculer (exemple : miner du bitcoin), on cherche à utiliser 100% des ressources, il n'y a pas interaction utilisateur.

Non mais c'est bien ce que je dis, la température de la box, ce n'est PAS le problème. C'est juste un symptôme... comme l'est la fièvre quand on a la grippe. Il reste toujours la question de savoir pourquoi le CPU s'est affolé à l'ancien emplacement... mystère, et Fibaro ne t'a pas aidé. Non, je me tue à te répéter que c'est tout l'inverse : C'est l'utilisation élevé du CPU qui a entrainé la hausse de température interne.

Ah tiens je me souviens de cette vieille discussion De mon coté j'ai toujours été en Ethernet pour les appareils fixes, dont la passerelle Envoy. Le Wi-Fi, ce n'est que pour les appareils mobiles, ou bien certains objects connectés fixes mais sans port Ethernet... (typiquement le genre d'appareil jetable qui dépend d'un cloud... donc j'évite autant que possible) Pour revenir à l'Envoy, je me souviens aussi de cette vieille discussion, dans mon QA je ne retente l'authentification que si le token précédent a expiré. Sinon (c'est à dire 99,9999% du temps), je ne passe pas par l'authentification, c'est directement l'interrogation des données, puisqu'on est déjà authentifié.

En tout cas je trouve leur explication assez rationnelle.

Je n'ai pas compris, c'est quel problème qui est réglé ? La température, ou l'utilisation CPU ? Par que la première est directement la conséquence de la seconde, toute chose étant égale par ailleurs (température de la pièce... Mais là tu dis que justement elle est dans une pièce plus chaude) Donc on peut penser que l'utilisation CPU a miraculeusement baissé.... problème de routage Z-Wave là où elle était placé peut-être ? Qui aurait entrainé une suractivité CPU... Je crois que l'API ne remonte pas la température interne de la box.

Je m'apprête à migrer le forum sur mon serveur ce week-end... normalement tout est prêt. Espérons que ça se passe bien J'en ai profité pour détecter et corriger un bug qui devait être présent depuis un petit moment : les nouveaux utilisateurs ne pouvaient plus s'inscrire à cause de la vérification CAPTCHA obsolète

La version longue de mon message précédent : si une marque historique, occidentale, et qui a une réputation de qualité, n'est plus capable d'assurer la qualité pour laquelle est s'est fait connaitre, il est normal que les clients aillent acheter des produits chinois en remplacement, car d'une part c'est moins cher, et d'autre part la qualité est en hausse, souvent meilleur que l'original même ! Tu remarqueras que je n'ai pas dit le mot "onduleur" dans la phrase précédente, car ça peut s'appliquer quasiment à tous les produits de nos jours : téléphones, aspirateurs, .... voitures.... Après, en tant qu'utilisateur, on se moque pas mal de savoir si c'est le technicien local qui est incompétent ou le groupe dans son ensemble, puisque c'est bien bien nous, le client final, qui est lésé en fin de compte. Heureusement, de mon coté, pour l'instant je n'ai pas de souci avec mon installation Enphase, j'avais même réussi à faire activer le protocole Modbus en contactant le support quand ils avaient ajouté cette fonctionnalité après une mise à jour du firmware. Ils l'avaient activé à distance au bout de quelques jours alors que c'était tout nouveau, franchement pour le coup j'étais super content. Pour rappel, le Modbus me permet d'intégrer nativement l'installation Enphase dans mon installation Victron, qui supervise tout sur un tableau de bord centralisé. C'est mon installation APSystems qui laisse à désirer... entre le panne d'un onduleur (heureusement SAV au top, hyper réactif), et la récente mise à jour forcée de la passerelle qui supprime le contrôle local... cette manie qu'on tous les fabricants d'enfermer les clients dans leurs clouds, c'est toujours aussi détestable.

Et après on (fait semblant de) s'étonner que les clients achètent du matos chinois à la place...

Tu peux voir les types disponibles via l'API sur l'adresse IP de la box : /api/quickApp/availableTypes /api/devices/hierarchy Il y a aussi le travail de @tinman pour ajouter des interfaces aux QuickApps sur le forum officiel : https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/page/8/#comment-202936 Ainsi que son travail d'identification des types et propriétés des QA : https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/page/58/#comment-227370 Attention ça commence à dater pas mal, l'inventaire a un peu évolué depuis.

Parce que le LUA d'un QA ne mesure que sa propre consommation CPU (= celle du process Linux), pas celle induite sur les autres process Linux. Par exemple si tu as un QA, donc ici GEA, qui sollicite énormément le système (par exemple : interroger la valeur de tout un tas de propriétés de tout plein de modules différents, ou pire encore, qui modifie leur statut), alors la majorité de la charge CPU n'est pas dans GEA, mais dans les autres process du système. Donc... tu dois avoir une (ou plusieurs) règle qui sollicite trop le système.

Si le CPU tourne à fond non-stop comme l'indique DomoCharts, alors il chauffe beaucoup... pas étonnant dans ces conditions que la box surchauffe et t'affiche ce message d'avertissement. Sans piste réelle de l'origine du problème, je te propose le protocole suivant : - reboot - désactivation des QA et Scène 1 par 1 jusqu'à identifier le fautif - désactivation des modules Z-Wave 1 par 1... car ça pourrait aussi venir d'un réseau Z-Wave pollué par un module qui floode le réseau, et donc oblige la box à traiter ces informations Bref, tu as du boulot

Excellent L'IA apprend bien sa leçon Non c'est de base je crois Le truc c'est que ça disparait dans les logs si tu as beaucoup de logs justement...