Lazer

Désole pas trop dispo aujourd'hui. Bien vu pour l'inversion courant/tension.

Dans la fonction parseStorageData(), tu pourrais ajouter une trace toute bête pour débugguer, et tu nous donnes ce qui s'affiche dans le log : print(data)

if type(self.Voltage_DC) == "number" then self:updateView("Voltage_DC", "text", "Tension batterie: " .. string.format("%.3f",self.Voltage_DC) .. " V")

OK la syntaxe semble bonne, mais la condition or ne l'est pas. Si tu veux être rigoureux et éviter tout plantage, il faut tester chaque élément du tableau imbriqué avant de récupérer la valeur, ou bien de renvoyer 0 : self.Current_DC = type(fronius) == "table" and type(fronius.Body) == "table" and type(fronius.Body.Data) == "table" and type(fronius.Body.Data["0"]) == "table" and type(fronius.Body.Data["0"].Controller) == "table" and fronius.Body.Data["0"].Controller.Current_DC or 0 Je ne suis pas sûr que tu récupérera ta valeur, mais au moins tu éviteras le crash du code LUA.

Oui c'est cela. Et on voit que l'index est bien de type chaine de caractère, "string", donc il faut l'utiliser tel quel avec les guillemets autour du 0, le tout entre crochet.

C'est comme la dernière fois, il faut regarder le JSON brut, sans formatage à l'écran par le plugin, pour être certain du type d'index à utiliser. Soit numérique, auquel cas ça démarre à 1 comme je le disais plus haut, soit c'est textuel, auquel cas il faut mettre les guillemets comme pour toute string qui se respecte.

Non c'est Data[1], car les index commencent toujours à 1 en LUA, contrairement à beaucoup d'autres langage inspirés du C.

J'avais rapidement regardé pour remplacer la station Netatmo à terme, et à priori je partirais probablement sur la marque Ecowitt. Ils ont tout une gamme de vrais modules météo pour l'extérieur, écran intérieur, et surtout, connectivité avec une API locale. En plus c'est en IP, donc universel, pas dépendant d'un protocole domotique particulier Z-Wave/Zigbee, donc théoriquement plus durable avec les solutions domotiques du futur. Sur les box Fibaro, il faudra "juste" écrire le QuickApp qui va bien.

En fait non, car j'ai conservé les fichiers binaires compilés de ma précédente installation. C'est même d'ailleurs le premier truc que j'ai testé en reconnectant l'ESP32 à mon PC, c"est de réinjecter le même firmware tel quel... sans aucun changement, ce qui confirmait bien une panne matérielle et non logicielle du module. Mais à terme il faudra que je me penche sérieusement sur ce problème de nouvelle version d'ESP Home.

Ah oui tu as surement raison, j'avais oublié, mais pour Gmail j'ai probablement activé un truc par token ou quelque chose de similaire, j'avais fait ça il y a bien longtemps, car le Syno ne peut pas passer le double authentification. Bref, comme dit, c'est pénible l'envoi de mails, ça évolue tout le temps, depuis que j'ai mon infra je ne compte plus le nombre de fois où j'ai dû reconfigurer tout ça... sans compter qu'il faut à chaque fois faire la manip sur tous les équipements réseaux de la maison... NAS, caméras, onduleur, etc... Le mieux est de chercher au cas par cas, en fonction de l'équipement et du fournisseur de mail. Mais en tout cas, ça n'a rien à voir avec le script de backup, car il n'envoie pas de mail directement, il passe par le NAS. C'est donc la configuration interne du Synology qu'il faut faire fonctionner.

C'est probablement une trame d'alarme envoyée par erreur par un module, c'est pour ça que je dis qu'il s'agit peut-être d'une fausse détection. Le système de trames d'alarmes, comme dit, date du tout début du Z-Wave, et était très peu fiable. Envoyé en broadcast sur le réseau, sans passer par le maillage, donc seuls les modules à proximité directe pouvaient les recevoir... Effectivement aucun log disponible dans la box, forcément... Dans le doute, tu peux simplement désactiver la réaction aux alarmes de tes modules actionneurs, et même désactiver l'envoi d'alarme pour les modules détecteurs. Comme ça, plus aucune raison pour que le bug ne se reproduise.

Non ce sont les modules qui envoient les trames d'alarme. Typiquement, ce sont les détecteurs : ouverture, mouvement, incendie, inondation, etc... C'est une vieille fonctionnalité datant de la première version du Z-Wave mais qui n'est plus utilisée depuis des années, du coup elle est méconnue, et peut parfois jouer des tours. En plus les 10 minutes correspondent au paramètre 39 du module : Alors bien sûr tu peux le désactiver pour tous les types d'alarme reçus, mais ça serait bien de trouver quel module a pu envoyer une alarme... ça peut être une vraie détection, mais aussi une fausse détection... auquel cas si tu arrives à identifier le module, il faudra regarder dans ses paramètres pour désactiver l'envoi de ladite alarme.

C'est une plaie sans nom l'envoi de mails perso, chaque année à cause de la lutte anti-spam ils renforcent les protections et c'est de plus en plus compliqué... Il faut que tu trouves dans l'aide de Microsoft les paramètres SMTP à utiliser. Perso je passe par Gmail : Adresse électronique du destinataire : mon.email@gmail.com SMTP : smtp.gmail.com Port : 587 Authentification requise Nom d'utilisateur : mon.email@gmail.com Mot de passe : ***** Une connexion sécurisée (SSL/TLS) est nécessaire Adresse email de l'émetteur : mon.email@gmail.com En fait je suis obligé d'utiliser la même adresse comme expéditeur et destinataire, alors qu'avant je pouvais envoyer avec n'importe quelle adresse, ce qui était bien pratique pour filtrer et classer les mails à réception. Bon maintenant j'y arrive aussi, mais il faut filtrer sur le titre et non sur l'expéditeur.

Est-ce qu'il n'aurait pas réagit à une trame d'alarme reçue ?

Bravo. Non effectivement, pas normal ce plantage... faudra étudier les logs de l'ESP32 dès fois que ça puisse aider à comprendre. Mais pas évident.