Lazer

Voilà, tout est dans le titre Je vous souhaite une bonne année 2023, sans aucun projet domotique car ça voudra dire que votre domotique est parfaite et ne nécessite plus d'améliorations bah quoi, on peut rêver

Welcome to the forum

Il doit y avoir pas mal de discussions dans la section QuickApp > Support.

Je rebondis juste là dessus... non ta loop n'est toujours pas dans un settimout, du moins pas la 1ère exécution, et c'est celle-ci qui est critique : function QuickApp:onInit() -- Fait plein de choses self:loop() end A remplacer par : fibaro.setTimeout(0, function() self:loop() end) Là j'ai mis un timeout à 0, mais perso j'ai pris l'habitude de mettre un timeout plus important, entre 1000ms et 5000ms selon mes QuickApps. En effet, au reboot de la box, tous les QA démarrent en même temps, ce timeout variable permet de temporiser un peu et lisser la charge.

Désolé mais je n'ai pas le temps/courage de me lancer dans un nouveau tuto ces temps ci. Mais ce sont des discussions qu'on a déjà largement abordé en 2020/2021 lorsqu'on est plusieurs à s'être lancé dans le développement de QuickApp suite à la sortie de la HC3, le problème c'est que c'est disséminé un peu partout sur le forum. self désigne l'objet courant. C'est une notion qui fait référence à la programmation orienté objet. Même si en réalité, LUA n'est pas un vrai langage orienté objet comme peuvent l'être le C++ ou le Java. Les objets instanciés à partir des classes sont en réalité des variable de type tables au sens LUA. Une table est une variable qui contient n'importe quoi : des fonctions, des string, des boolean, d'autres tables imbriquées, etc. Fibaro utilise ces notions pour les QA. Il faut voir QuickApp comme étant une classe, et quickApp (sans la majuscule) comme étant une instance d'objet dérivée de la classe (même si en réalité, d'un point de vue LUA, c'est une table, on l'a dit au-dessus) self, si utilisé à l'intérieur d'une fonction membre de QuickApp, pointe alors sur l'instance de l'objet quickApp. self n'est pas utilisable en dehors d'une fonction membre de QuickApp, sauf à le passer explicitement en paramètre lors de l'appel d'une autre fonction (cette autre fonction qui peut être membre d'une autre classe, locale, ou globale, peu importe) Quand on a plusieurs Child Devices, chaque enfant est une instance objet de la classe QuickAppChild (elle même dérivée de QuickApp). A l'intérieur de chaque enfant, self pointe sur l'objet courant. Bref, il te faut revoir les bases de la programmation orientée objet (pleins de tutos sur le net) Puis l'implémentation spécifique LUA/Fibaro, pour cela je t'invite à (re)lire l'excellent exposé de Jang sur l'anatomie d'un QuickApp : The anatomy of QuickApps - Part 1 The anatomy of QuickApps – Part 2 The anatomy of QuickApps – Part 3 QuickAppChildren and how to raise them - Part 4

Quelques pistes : - la fonction initChildDevices() doit être la première appelée dans le onInit du QA, donc avant d'appeler les fonctions updateProperty, getVariable, et surtout loop() - idéalement c'est mieux d'appeler la fonction loop() dans un setTimeout, même avec un délai de 0, car ça déclenche un process asynchrone donc après la fin de l'exécution de onInit() - toutes tes fonctions createChildXXX() ne devraient pas être dans le onInit(), il faut les mettre dans une fonction spécifique, exécutée avec un bouton par l'utilisateur

N'hésite pas si tu as une question, pour approfondir la réponse de l'autre topic. EDIT : ah Jang vient de donner des détails complémentaires

Plus sérieusement, le message suivant ne te donne pas la réponse ?

Joyeuses fêtes de fin d'année EDIT : mais ce n'était peut être pas la réponse attendue

Erreur classique. Voir :

En ce qui me concerne, j'ai des notifications à chaque reboot/redémarrage des services Fibaro, et aucun reboot intempestif à signaler. Et pas de message d'avertissement dans le centre de notification. A noter que j'ai mon script de sauvegarde automatique qui s'exécute une fois par semaine, donc les services redémarrent à ce moment là.

Bienvenue sur le forum

Welcome to the forum

Noyeux Joël alors

Tu as 4 tables à modifier : UPDATE domocharts_temperature SET device_id=800 WHERE device_id = 725; UPDATE domocharts_temperature_day SET device_id=800 WHERE device_id = 725; UPDATE domocharts_device SET id=800 WHERE id=725; UPDATE domocharts_device_type SET device_id=800 WHERE device_id=725; Note : les 2 dernières tables ont peut être déjà été mises à jour si tu as cliqué sur le bouton Devices du QuickApp (ou bien si le nouveau module 800 existe depuis hier... car le bouton est activité automatiquement tous les soirs) ça fait très très très très (au moins tout ça) longtemps que je me dit qu'il faut que je prévoie une fonctionnalité dans DomoCharts pour remplacer facilement les ID des modules dans la base de données, mais ce n'est toujours pas fait... du coup je le fais à la main avec les requêtes SQL quand la situation se présente.

Ouais le titre m'a fait marrer Ou alors c'est un lapsus, tu en as marre parce que tu n'as pas compris ce qu'est le mode passerelle chez Fibaro ? Le comportement que tu as observé est tout à fait normal. Une autre box, c'est un autre contrôleur Z-Wave, donc un autre réseau Z-Wave. Rien de nouveau là dedans, c'est comme ça depuis la création du protocole. Les répéteurs n'existent pas en Z-Wave (à ne pas confondre avec le Wi-Fi). Les modules alimentés sur secteur font office de routeur, c'est à dire qu'ils sont capables de relayer les paquets pour les modules les plus éloignées... principe de base du réseau maillé. Si tu veux étendre un réseau, tu ajoutes donc des modules alimentés par secteur. Si tu ne peux pas (distance trop importante), alors c'est là que le second contrôleur Z-Wave est utile : pour créer un autre réseau... par exemple dans une cabane au fond du jardin. Et les box communiquent ensemble par réseau IP (Ethernet, car le Wi-Fi risque de ne pas plus porter que le Z-Wave si la distance est importante) Un autre usage d'une seconde box en mode passerelle est quand on a un réseau trop surchargé (rappel, la limite est de 232 modules, mais on arrive souvent à saturation avant si les modules sont trop "bavards"), donc on peut ainsi créer plusieurs réseaux distincts, indépendants.

Voilà, en PV l'azimuth 0 est au sud (direction du soleil... et tant pis pour les gens qui habitent l'hémisphère sud ) Donc quand on va vers l'est, ce sont des azimuth négatifs, et positif vers l'ouest. Tes résultats me semblent cohérents.

Pour ça tu as le topic du support GEA. Power c'est si ton module a une propriété power.

Cool. Ta production tu l'as déjà, elle est indiquée en vert sur ton graph, donc elle correspond au module que tu as défini comme tel.

Ah marrant le coup de l'unité avec un emoji Par contre attention, dans ce cas les mesures risquent de ne plus prises en compte par DomoCharts, si tu l'utilises.

Super, bien trouvé le coup des emojis dans le log Malheureusement le log n'est pas visible sur l'application mobile, du coup l'intérêt est limité au quotidien. Mais une idée me vient.... ne pourrait-on pas modifier le nom du module, en ajoutant les emojis en question dedans, du coup ça serait visible dans l'app ! Reste à savoir s'il faut recharger l'app pour que le titre se mettre à jour, ou si c'est dynamique... faudrait le tester.

Bienvenue sur le forum Tu peux partager tes créations dans la rubrique adaptée du forum : https://www.domotique-fibaro.fr/forum/120-quick-app-developpeur/

Essaye avec "\n" C'est le saut de ligne, code ASCII 10.

AP System, c'est ce qu'utilisait @flacon030, regarde sur son topic, je ne me souviens plus s'il arrivait à remonter l'information directement depuis les micro-onduleurs.

Je ne connais pas le module PAB01, mais déjà est-il inclus et correctement reconnus par la box ? Si c'est le cas, alors c'est tout bon. Dans les propriétés du module, tu as juste à choisir s'il mesure une consommation ou une production... ce qui n'était surement pas encore disponible lors de la création de ce topic à l'été 2021, car c'est une fonctionnalité que Fibaro a ajouté par la suite : Mais pourquoi utiliser ce module pour comptabiliser ta production solaire ? Ton onduleur ne renvoie pas l'information ? C'est quelle marque, il y a surement une API, ou peut être même déjà un QuickApp qui existe.