Lazer

De ma compréhension, le setValue n'est pas implémenté de base, c'est à nous de l'implémenter dans le code LUA de nos QuickApps.... pour ceux de type actionneurs. Car c'est la méthode qui est appelée par l'interface Web, l'application mobile, pour toute action lorsque l'on clique sur un module pour changer son état (allumé, éteint, dimmer, ouvert, fermé, etc). Le setValue est donc nécessaire pour que le QuickApp réagisse normalement dans l'interface et se comporte comme n'importe quel autre module Z-Wave. Les capteurs, eux, n'ont aucunement besoin de setValue. Et pour changer la propriété d'un module (QuickApp ou Physique), on utilise updateProperty ou setProperty... il y a eu une discussion récemment sur le sujet GEA, voir mon message et le suivant de @jang qui apporte des précisions complémentaires : En résumé, pour un QuickApp, qu'il soit enfant ou parent, ça ne change rien au principe : actionneur : implémenter setValue qui va à son tour appeler updateProperty capteur : appeler directement updateProperty Conséquence, dans le QuickApp Netatmo, qui par principe n'a que des modules enfants de type capteur, on n'a pas besoin d'implémenter setValue.

Non effectivement, il me semblait même que cette version du QuickApp ne fonctionnait plus depuis un petit moment... mais pour d'autres raisons (token...) Tu ne le précises pas, mais tu as peut être fait une mise à jour du firmware de ta box qui modifierait le comportement des QuickApps ? Par exemple la dernière beta...

Oui effectivement. Bon après Network Monitor n'a pas été conçu pour signaler l'allumage ou l'extinction d'un appareil, mais si tu as réussi à t'en sortir ainsi, alors c'est top.

Je pense que tu peux le faire avec 1 seule ligne de config dans Network Monitor (qui va incrémenter la VG et la remettre à 0). Et dans GEA, avec 2 règles, dont la première se déclenche dès que la VG est supérieure à 0, et l'autre lorsque la VG est égale à 0.

Ah oui HC2... bon du coup pas sûr pour les valeurs numériques.... ça fait bien longtemps, mais sur la HC2, Fibaro n'avait jamais bien typé les valeurs des modules, de mémoire tout était dans des chaines de caractères justement, et Steven avait adapté GEA pour faire des comparaisons numériques. Bref, ça devrait marcher tel que tu l'as écris... si ça ne fonctionne pas, alors je ne sais pas pourquoi... et impossible de t'aider... désolé.

Tu peux tout à fait gérer des nombres négatifs avec GEA, mais attention, car là tu as mis tes nombres dans une chaine de caractères (=string, entre guillemets), alors qu'il faut utiliser directement des valeurs numériques (qui peuvent être positives ou négatives) Sinon, pourquoi utiliser des variables globales ? Ton QuickApp Fronius ne stocke pas ses valeurs dans des modules enfants ? Auquel cas tu pourrais utiliser leurs valeurs comme n'importe quel autre module, avec "Value", "Power", etc.

C'est difficile à tester ça, car à ma connaissance tous les smartphones récents ont une batterie intégrée qui n'est pas remplaçable (sauf à démonter/dessouder/décoller le bouzin...) Sur les vieux smartphones on pouvait (j'ai eu des HTC comme ça), mais ça n'a pas duré... Mais même si on pouvait retirer la batterie, je doute que ça fonctionne, je veux dire que le smartphone va refuser de démarrer car je suppose que l'électronique interne va prendre l'alimentation continue depuis la batterie, pas depuis le chargeur. Il faudrait prendre le problème complètement différemment, à savoir ne pas utiliser de smartphone, et à la place utiliser un routeur 4G/5G qui propose une API permettant d'envoyer des SMS. A une époque j'avais envisagé ça avec mon vieux routeur Huawei, mais j'avais laissé tomber car l'API ne permettait que d'envoyer des SMS, pas d'en recevoir, car à ce moment là j'avais besoin de la communication bidirectionnelle (avec Tasker... vieux tuto sur le forum). Maintenant que je n'utilise plus que JPI pour envoyer des SMS uniquement, ça pourrait le faire. En bonus, on branche le routeur sur un onduleur (tout comme la box domotique et les équipements réseaux) et on a la sécurité anti-coupure de courant.

Pas sûr de comprendre ta remarque. Toi tu es sur une box existante, donc tu conserves ton moteur Z-Wave. Le moteur Z-Wave v3 se met par défaut sur les nouvelles installations, comme indiqué dans le changelog. FTI doit vouloir dire First Time Initialization ou un truc dans le genre, c'est l'assistant de configuration initial.

Pour déterminer la version du moteur Z-Wave utilisé sur la box, voir ce message :

Pas sûr de comprendre pourquoi tu parles de voiture électrique, si ce n'est relancer un vieux débat Je ne sais pas en Belgique, mais en France, aux dernières nouvelles c'est moins de 20% des voitures neuves, ce qui implique que plus de 80% des voitures neuves sont thermiques, donc en fait, faudrait plus s'inquiéter du sujet pour des voitures thermiques alors Car la plupart (toutes ?) les voitures neuves sont connectées, et comme dit, une voiture c'est fait pour rouler, donc ma remarque sur la connectivité dépendante du réseau 5G est toujours d'actualité. Après... dans un cadre domotique... outre les statistiques de kilométrage, consommation, etc (tout ça remonte dans Domocharts).... moi ce qui m'intéresse avec la connectivité, c'est d'automatiser la charge de la voiture... donc là où c'est lié à l'électrique, mais ça reste un cas d'usage bien particulier.

Mise à jour passée sans souci sur ma box de test. Interface toujours aussi illisible....

Est-ce que tu veux bien me citer une seule voiture sur le marché qui propose une API locale, car je pourrais bien être tenté de l'acheter (même si je n'achèterai peut-être jamais de voiture de ma vie...) A ma connaissance, toutes les voitures (enfin... celle qui le sont...) ont une SIM et sont donc connectées en 3G/4G/5G... donc ça passe nécessairement par le cloud propriétaire du constructeur, dont l'API est toujours plus ou moins fermée, plus ou moins non documentée, et plus ou moins changeante sans prévenir. Ce n'est pas innocent, car ça permet avant tout au constructeur d’acquérir de la donnée sur son propre parc en circulation. Et quand bien même il y aurait une API locale, dont on peut supposer qu'elle serait accessible en Wi-Fi, cela la rendrait donc disponible uniquement lorsque la voiture est garée à la maison... ce qui limite un peu l'intérêt de la remontée d’information dans le système domotique.

Oui car ça élimine un intermédiaire, mais il y a un gros souci avec l'API Renault, c'est le même que pour l'API PSA/Stellantis : partiellement documentée, change tous les 4 matins, peut s'arrêter de fonctionner du jour au lendemain, etc...

Merci pour le partage. Depuis 1 mois environ j'ai un QuickApp de mon coté qui utilise directement l'API Renault. Il faut que je le partage aussi.

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.