Lazer

Le site de RTE a du avoir quelques difficultés temporaires, ça arrive. De toute façon apres 7h, il y a très peu de chance que la couleur de lendemain ne change, le QA ne fait la vérification jusqu'à 11h que pour être certain que ça n'est pas le cas.

Bienvenue sur le forum

Quand tu dis que tu as réinitialisé le Z-Wave... tu as bien réinitialisé toute la box ? Parce que sinon, la box connait encore les anciens modules, stocké dans la base de données interne de la box.

Effectivement, pour savoir quels sont les options qui interprètent le contenu du texte, il faut chercher l'appel à la fonction "getMessage" dans le code source de GEA. Pour les emails, on constate que le contenu de l'email est bien concerné, mais pas le titre. Il y a un certain nombres d'autres options pour lesquelles c'est le cas. SI tu as besoin pour une option en particulier (QuickApp dans ton cas), alors tu peux surcharger l'option, tu peux simplement la redéfinir dans ton propre fichier de config et la modifier comme tu veux pour y ajouter le getMessage.

Oui il faut contacter leur support, généralement ils proposent la réparation des anciennes box. A voir en fonction du prix demandé... je ne suis pas sûr que ça soit pertinent de s'acharner sur une box qui a plus de 10 ans... il faut peser le pour et le contre face d'une migration vers des évolutions comme la HC3 pour rester chez Fibaro, ou bien les autre solutions du marché.

Oui c'est possible, il faut utiliser #duration# dans le texte de la notification : "Porte garage ouverte depuis #duration#"

Seulement les jours Blancs et Rouge, on a eu 2 jours blancs la semaine dernière et j'ai bien reçu toutes les notifications. Les jours bleus, ce sont les jours normaux, donc pas de notif. (je dois toujours corriger mon QA avec la nouvelle version de l'API EDF.... en attendant il fonctionne avec l'API RTE)

Pas besoin de grande compétence de programmation pour constater qu'il n'y pas d'instruction Quit après l'erreur "impossible d'obtenir la version" contrairement à la majorité des autres erreurs. C'est juste ce que j'ai fait ce matin pour comprendre ce qui s'est passé chez toi. Tu as réussi à trouver et modifier le titre de l'email, je suis sûr que tu aurais aussi réussi à arriver à la même conclusion pour cette erreur Pour le "fi", c'est une des particularités du langage Shell... chaque langage a sa syntaxe qui lui est propre. Là ils ont décidé d'inverser les lettres du "if" pour clore la section, tout comme LUA a décidé d'utiliser un "end", l'indentation (tabulations) en Python, ou encore l'accolade dans beaucoup d'autres langages, voire rien du tout (en C/PHP/etc, si une seule instruction après le if, on peut omettre tout élément délimiteur de section) Bref, rien qu'avec la tabulation de mon script (relativement simple), je pense qu'on comprend facilement que le fi ferme le bloc if/else précédent... oui bon désolé dans l'extrait de 3 lignes de mon message précédent, il manque le début du "if"... il faut aller voir le code source.

Parce que ce n'est pas une erreur bloquante, si tu regardes le code source, tu verras qu'après l'envoi du mail d'erreur, il ne stoppe pas l'exécution du code, il continue à la suite. else Error "Erreur : impossible d'obtenir la version : code de retour HTTP ${CODE}" "${JSON}" fi La seule conséquence, c'est que le nom du fichier de sauvegarde ne comportera pas la version et le type stable/beta, pas vraiment gênant, comme on le constate d'ailleurs dans le 2nd mail que tu as reçu. On pourrait voir cela comme un message d'avertissement plus que d'erreur Reste que je ne sais pas pourquoi cette erreur est survenue (des services pas complètement redémarrés probablement), et pourquoi ta modification du titre d'email n'a pas eu d'effet sur ce mail.

Si bien sûr. La clé USB interne est appairée avec la carte mère, pas leurs numéros de série respectifs, et le logiciel Fibaro vérifie cela au démarrage. Change le stockage interne n'a de sens que si on veut utiliser la carte mère pour un autre usage.... faire tourner un autre logiciel domotique par exemple. Bon après, vu la consommation (14W) de la bête, pas sûr que ça soit pertinent vis à vis d'un mini-PC trouvable pour pas cher en Chine.

Je me suis peut être mal exprimé.... si dans le code de ton QA Enphase, tu n'as pas implémenté une routine qui détecte que le token est expiré pendant son fonctionnement (et demande en conséquence un renouvellement du token), alors il ne sera pas renouvelé, sauf au prochain démarrage du QA lorsque tu appelles à nouveau la fonction getToken(). Extrait de mon propre code : elseif response.status == 401 and not self.retryLogin then tools:warning("Need new token") self.retryLogin = true self.token = nil self:getToken({ et ça se trouve dans la fonction getEnvoyAPI() qui est appelée très régulièrement pour interroger l'Envoy.

Ah OK, je n'ai pas lu ton code, mais tu n'as peut être pas intégré de routine de détection du token expiré, puis demande d'un nouveau ? En redémarrant ton QA, c'est à ce moment là que le token aurait pu être régénéré. La mise à jour de mon QA date de juillet 2023. En mars 2024, il a certainement renouvelé tout seul le token, en tout cas je n'ai eu aucun dysfonctionnement, je ne m'en suis pas rendu compte. Et donc vu la validité de 1 an, il devrait être renouvelé automatiquement en mars 2025. Il faudrait que je me mette une alarme pour surveiller le log ce jour là.

Hum.... comment tu t'es rendu compte du changement de token ? Je viens de regarder les logs de mon QA, tout tourne, et dans l'historique (quelques heures seulement) pas de trace de changement de token. Après peut être que mon token a été généré après le tient et que je vais avoir le même problème dans les jours qui viennent... EDIT : bon bah j'ai la réponse, j'ai décodé le token en base64 et il expire le 03/03/2025... ça me laisse de la marge. N'empêche, ça n'explique pas pourquoi le tiens n'a pas été rafraichis automatiquement par le QA. Mais dis-moi... tu utilises ton QA, pas le miens ?

Bienvenue sur le forum

ça m'inquiète cette histoire, car ça veut dire qu'on ne sait plus compiler les firmwares... Il faut que j'essaye de trouver du temps pour creuser le sujet, mais je ne garantie pas que ça soit tout de suite...

ça c'est génial ça casse tout l'intérêt du module Si c'est juste pour faire une télécommande murale à 4 boutons, c'est pas terrible, surtout que niveau WAF les interrupteurs multiples c'est assez catastrophique je trouve.... souvenir ému de 2 séjours en gite et hôtel de luxe tous domotisés, où tu cherches 10 minutes avant de te coucher comment éteindre toutes les lumières.... sans en rallumer d'autre en même temps ! Pour trouver un intérêt à ce module, il faut un cas de figure où on a besoin de récupérer 4 contacts distincts, mais avec une tension commune (soit le 230V pour le modèle AC, soit la masse pour le modèle DC)... là je ne vois pas. @Sowliny j'ai isolé ton message dans un topic dédié à ce module (enfin, les 2 versions AC et DC du module)

Apparemment c'est la version ESPHome de juin 2024 qui a tout pété : https://github.com/geoffdavis/esphome-mitsubishiheatpump/issues/152 Ils disent que la compilation crashe quand on utilise UART2, ce qui le cas dans notre montage... Il y a des solutions qui sont données, mais je n'ai ni le courage ni le temps de tester tout ça maintenant.... je me demande si en attendant, le mieux n'est pas de trouver un moyen de downgrader à la version précédente de ESPHome.

Dommage... Tu n'as pas un autre PC pour tester ? Je vois que tu es sous MacOS, peut être qu'avec Windows ou Linux le compilateur se comporte différemment ?

[Frandroid] Matter 1.4 dévoilé : la mise à jour qui pourrait tout changer pour votre maison connectée et votre voiture électrique

Effectivement, bonne remarque sur les requêtes qui s'empilent... comme dit, je n'ai plus mon code en tête, mais c'est une idée de vérification et d'optimisation potentielle. J'avais eu ce souci sur un autre QA plus récent (celui des PAC Mitsu avec ESPHome), et j'avais développé tout une gestion de file d'attente des requêtes. C'est une idée à creuser... d'autant plus qu'entre temps, il me semble que mon QA Yamaha Musiccast fait face au même problème dans certaines circonstances...

Je suis à 5 secondes, et non absolument aucune erreur. Comme je le disais sur l'autre topic, temps de réponse inférieur à la seconde, parfois 2s. Firmware D8.2.4264 apparemment, donc comme toi. De toute façon chez Enphase on ne choisi pas (plus), les mises à jour sont poussées à distance depuis leur cloud.

Ah OK... bon bah alors c'est vraiment la faute de mon code. Ce qui est étonnant alors, car les 2 autres QA du forum, qui sont complètement différents, ont le même problème.... ce qui est étonnant aussi, c'est que le problème n'apparait pas chez moi. A devenir fou....

Hum... tu veux dire que sur HC2, tu arrives à interroger l'Envoy avec un intervalle très court, tandis que ça ne fonctionne pas sur HC3 ? Dans ce cas, alors il doit y avoir un souci avec le code LUA.... j'ai pas lu ton code (déjà met la coloration syntaxique, ça sera plus avenant), et ça fait maintenant des années que j'ai codé mon QuickApp donc je n'ai plus tout ça en tête... il faudrait que je me replonge dedans pour voir de quel façon l'optimiser... un jour peut être... dans quelques mois.... sachant que je n'ai pas le problème chez moi, donc difficile à reproduire. Sinon tu peux prendre le code de mon QuickApp et faire tes tests à partir de ça, l'avantage c'est que la gestion des child devices est déjà en place.

Ah c'est dommage ça, tu aurais donc le même problème que @TitiXsi dont on a parlé également sur les topics des 2 autres QuickApps dédiés à cette passerelle Envoy... Franchement je ne sais pas quoi en penser, il y a la piste de la connexion réseau Ethernet versus Wi-Fi, mais aussi la piste de la présence, ou non, des 2 pinces de mesure de courant.... à moins que ça ne soit encore autre chose ?

Je fais pareil Mais je n'avais jamais pensé à la seconde raison...