Barelle

Désolé, une mauvaise manipulation sans doute, le zip vient d'être mis à jour.

Merci de ce rappel, toutefois, quand une fonction n'est pas déclarée locale, elle est visible depuis l'intérieur des autres fonctions déclarées avant. Alors que comme le montre mon exemple ce n'est plus vrai dans le cas d'une fonction locale qui ne devient visible que de l'intérieur des fonctions déclarées après. Après vérification, ce comportement se retrouve pour tous les types de variables, ce qui est parfaitement logique.

Une dernière remarque, si l'on déclare une fonction locale, elle n'est visible dans un bloc de niveau inférieur que si elle est déclarée avant. Ainsi : Ce code fonctionne : local function toto(self) self:trace("Je suis Toto"); end function QuickApp:onInit() toto(self); end Quand celui-ci ne fonctionne pas : function QuickApp:onInit() toto(self); end local function toto(self) self:trace("Je suis Toto"); end On obtient l'erreur : [18.03.2021] [22:07:23] [ERROR] [QUICKAPP92]: QuickApp crashed [18.03.2021] [22:07:23] [ERROR] [QUICKAPP92]: main.lua:20: attempt to call a nil value (global 'toto') Il convient alors d'écrire : local toto; function QuickApp:onInit() toto(self); end local function totofct(self) self:trace("Je suis Toto"); end toto = totofct; Pour obtenir le bon fonctionnement de cet indispensable QA.

Un quickApp mineur

Oui, sauf à la déclarer pour qu'elle appartienne à la classe QuickApp : function QuickApp:mainLoop()

Je suis d'accord sur tout sauf sur N'oublions pas le fameux vol d'Ariane 5, je cite wikipedia :

Un rapide exemple, mais non testé... local delay = 60; -- la variable sera visible par l'ensemble du code function QuickApp:onInit() -- On prépare l'environnement d'éxécution : -- - vérification de la cohérence des variables -- - récupération des éléments nécessaires -- - initialisation des childs -- - ... local ok, err = pcall(function() mainLoop(self); end) if not ok then self:error("onInit>>>Error calling mainLoop : ".. err); end end -- QuickApp:onInit function mainLoop(self) -- On passe self en paramètre pour pouvoir utiliser les fonction natives du quickapp comme self:trace, self:debug... -- -- On fait le boulot -- processLeBoulot(self); fibaro.setTimeout(delay * 1000, function() mainLoop(self); end); end -- mainLoop function round(num, numDecimalPlaces) -- On ne passe pas self en paramètre car on n'en a pas besoin return tonumber(string.format("%." .. (numDecimalPlaces or 0) .. "f", num)); end -- round function processLeBoulot(self); self:debug("Silence, je bosse !"); self:trace("pi avec 2 décimales : ".. round(math.pi, 2)); end -- processLeBoulot

Oui on peut passer l'intervalle en paramètre, mais cela est inutile s'il est déclaré local au quickapp, étant visible par l'ensemble du code. Pour la seconde partie de ta réponse il me semble que tu crées de la confusion entre la visibilité des variables et la structure modulaire du code qui me semble être deux notions distinctes : Déclarer QuickApp:fonction(a, b) ou fonction(self, a, b), la seconde écriture demande moins de caractères... Et lors de l'appel self:fonction(a,b) et totalement comparable à fonction(self, a, b). Encore faut avoir le besoin du self dans la fonction. L'utilisation de fichiers pour améliorer la modularité du code est un choix du développeur, pour avoir par le passé travailler sur des fichiers sources de plus d'un million de lignes, si ceuc-ci sont bien structurés, cela ne présente pas de difficultés particulières. Je crois que ce choix de la multitude de petits fichiers (pas de de 1000 lignes par fichier, une fonction ne doit pas dépasser 24 lignes...) est issue du monde Unix à l'époque de machines ne disposant que de mémoire dont la taille était exprimée en ko (dans le même ordre d'idée l'emploi d'accolades pour délimiter les blocs en langage C, en lieu et place des BEGIN et END de l'Algol et de ses dérivés - Pascal, Modula 2... - n'avait pour objectif que l'économie de mémoire pour l'éditeur). Je suis septique quand à la différence de rapidité du copier/coller entre un fichier complet et une partie de fichier, je pense que dans le second cas, on est plus vigilant.

Pour avoir la visibilité sur les fonctions déclarées comme rattachées à la classe QuickApp. QuickApp:fonction(a, b, c) est syntactiquement équivalent à fonction(self, a, b, c). Dans ce dernier cas fonction est locale au quickapp sans appartenir à la classe QuickApp...

@Lazer, juste histoire de polémiquer un peu : Totalement d'accord avec ton propos, aussi, dans ton exemple, il est inutile d'utiliser une variable self.refreshInterval, quand une variable refreshInterval déclarée locale avant la déclaration de la QuickApp:onInit(). Dans le même ordre d'idée pour limiter la portée des variables, à quoi bon déclarer function QuickApp:loop() quand function loop(self) permet le même usage en restreignant, de plus, la visibilité de la fonction loop à du code externe, se qui ne peut que concourir à la robustesse du code ?

Ceci pourrait sans-doute correspondre à ton besoin...

Hello, Ce quickapp correspond à une adaptation du VD UPS pour la HC2 : Il met à jour une variable globale (appelée UpsStatus par défaut) avec les valeurs "power-line" ou "battery" selon que l’onduleur est sur secteur ou sur batterie. Cette variable globale permet le lancement d’une scène (à écrire) pour prendre les mesures appropriées. Installation du QA : Importer le fichier .fqa ; Renseigner l’adresse IP du NAS connecté à l’onduleur : variable UPSip ; Si nécessaire renseigner le numéro de port du serveur UPS (par défaut 3493) ; Éventuellement changer le nom de la variable globale contenu dans la variable globalVarName (surtout indispensable si plusieurs onduleurs) ; Les username et password présents dans le code du bouton sont les valeurs par défaut pour DSM. Ne pas oublier d’activer le serveur réseau UPS sous DSM : "Panneau de configuration", "Matériel et alimentation", onglet "UPS", cocher "Activer la prise en "charge UPS" et "Activer le serveur réseau UPS"), puis ajouter l’adresse IP de la HC3 dans la liste des "Périphériques DiskStation autorisés". Configuration utilisée pour les tests : HC3 version 5.063.30 ; Onduleur : Eaton Ellipse PRO 1200 ; NAS : Synology DS1010+, DSM 5.2-5967 Update 8 ; NAS Synology DS1621+, DSM 6.2.4-25554. Le fichier .zip ci-après comprend le fichiers .fqa et les icônes que j'utilise. Nouvelle version prenant en compte la correction du problème suivant : QA UPS-0.28.zip

J'essaierai plutôt : api.get(/settings/info)[Ma_Variable]

Pas tout à fait 2021, plantage de ma HC2 le 31/12 à 19h20. Une anticipation du couvre-feu ?

Merci, correction effectuée.

"/settings/network" fonctionne bien..

Lua - Size of table returning different: https://stackoverflow.com/questions/54336703/lua-size-of-table-returning-different Je suppose qu'avec une condition comme : if element and element ~= "" then ... Le fonctionnement paraîtrait (je n'ai pas essayé) plus normal…

Une nouvelle version (0.9) intégrant notamment les index a été mise en ligne dans le premier post.

Afficher, dans un seul child les index HC et HP me semble difficile, surtout que dans le cas d'un abonnement Tempo, il faudrait y afficher six index... Par contre, il est possible de prévoir : D'afficher les index directement dans le QA, Eou de prévoir un child par index, avec la possibilité de choisir lesquels créer. Une préférence ?

Quick App HC2 Devices Contexte Vous avez une HC2 (ou HCL) qui ronronne paisiblement et vous venez d’acquérir une HC3. Vous hésitez sur la stratégie de migration : Le big-bang par Fibaro : tous les dispositifs z-wave seront connectés à la HC3 et vous aurez perdu les scènes et les VD ; Commencer par convertir les VD en QA (en fait, il s’agit pour bien faire les choses d’un redesign complet), puis migrer les dispositifs (devices) z-wave soit par exclusion puis inclusion sur la HC3, soit par le big-bang Fibaro, mais en ayant déjà préparé les nouveaux QA et scènes. Ce QA s’adresse donc à ceux qui ont fait ce second choix. Mais les autres aussi peuvent l’essayer… Note : n’en possédant pas, je n’ai pas testé ce QA avec une HCL, mais, en toute logique, cela devrait fonctionner. Fonction Ce QA permet de voir sur la HC3, un ensemble de devices (dispositifs) physiques de la HC2. En effet, développer scènes et QA sur une HC3 sans device et parfois un peu gênant. Paramétrage lors de l’installation Il est nécessaire de créer pour le QA les variables suivantes : HC2IP : l’adresse IP de la HC2. HC2userPass : <codeutilisateur>:<mot de passe> de la HC2, cet utilisateur devra avoir les droits de modifications sur les devices à voir sur la HC2. Note : après une connexion réussie à la HC2, le QA effacera la variable HC2UserPass et créera la variable HC2Authorization (soit HC2userPass en base 64). Optionnellement : La variable refreshPeriod permet de modifier la période (en secondes) d’interrogation de la HC2 (par défaut 60 secondes), ce qui parait suffisant pour un emploi en développement, une période trop courte pourra se traduire par une consommation CPU plus conséquente. Une variable iconId permet d’affecter une icône au QA HC2Devices. Comme vous le savez bien, il y a sur la HC2 un tas de devices que nous considérons sans intérêt (device master, second relais inutilisé, etc.) le QA ne prend pas en compte que les devices physiques (donc pas les VD) qui en plus : Sont enabled. Sont visibles. Ne sont pas des masters. Qui sont d’un type pris en charge (cf. la table HC2Types pour en avoir la liste), seuls certains ont été testés. Qui sont affectés à une pièce. Qui n’ont pas été explicitement exclus par ajout de leur id dans la table HC2IdExcluded en tête de programme. Interface utilisateur Le device de la HC2 en cours. Affiche le device de la HC2 précédant. Ajoute le device de la HC2 en cours sur la HC3 (child). Supprime le device de la HC2 en cours sur la HC3 (child). Affiche le device de la HC2 suivant. Affiche dans la fenêtre de log le device en cours. Affiche dans la fenêtre de log les devices présentes sur la HC3. Affiche dans la fenêtre de log les devices non présentes dur la HC3. Affiche dans la fenêtre de log tous les devices de la HC2 connus du QA. Ajout/suppression sur la HC3 (d’un child reflet d’un device de la HC2) On le sélectionne par son nom et son id à l’aide des boutons (2) et (5), puis par le bouton (3). Pour la suppression, on utilisera le bouton (4). Lors de l’ajout le child sera affecté à une pièce du même nom que celui de la HC2, si elle existe dans la HC3, ou dans une pièce du même nom qui sera créée dans la section de nom "Fibaro HC2". Synchronisations HC2/HC3 et HC3/HC2 Les changements de valeur des principales propriétés (properties) des devices de la HC2 sont reportés sur les childs de la HC3), lors de chaque rafraîchissement.. Les ordres donnés à partir des devices de la HC3 sont transmis à la HC2 (pour les types implémentés). Le retour d'état sera affiché lors du prochain rafraîchissement (60 secondes par défaut). Limites Tous les types de devices n’ont pas été testés. Il n’est pas possible de récupérer par le QA les icônes de la HC2. L’utilisateur n’a pas accès à la modification des variables crées par le QA (en version 5.050.13), mais il peut les supprimer ou les modifier par l’API du swagger. Le manque de robustesse de la HC3 qui permet ainsi de tester de manière approfondie le mode de récupération… Des redémarrages aléatoires du QA, sans cause identifiée, heureusement sans impact sur son fonctionnement. La sagesse de Fibaro qui a su conserver une réserve d'améliorations considérable pour les possibilités de personnalisation de l'interface. Les bugs que vous ne manquerez pas de découvrir. Téléchargement HC2_Devices.fqa

La variable globale EcoDevices contient les dernières valeurs calculées, et la periode en cours, illustration : { "teleinfo1": { "abonnement": "HPHC", "hourTotalIndex": 43177383, "HCIndex": 16806364, "monthTotalIndex": 42984543, "HChourTotalIndex": 16806364, "HPIndex": 26371262, "yearTotalIndex": 42984543, "puissanceApparente": 1020, "lastTotalIndex": 43177626, "HCdayTotalIndex": 16795809, "HCmonthTotalIndex": 16736947, "HPhourTotalIndex": 26371019, "dayTotalIndex": 43163591, "HPdayTotalIndex": 26367782, "HPmonthTotalIndex": 26247596, "periode": "HP..", "HCyearTotalIndex": 16736947, "consoActuelleWh": 13, "HPyearTotalIndex": 26247596 }, "firstUpdate": 1596054883, "lastUpdate": 1600593556, "compteur1": { "consoActuelle": 0, "monthIndex": 631288536, "lastIndex": 631307338, "hourIndex": 631307338, "yearIndex": 631288536, "dayIndex": 631301392 }, "compteur2": { "consoActuelle": 0, "monthIndex": 669708259, "lastIndex": 669740960, "hourIndex": 669740960, "yearIndex": 669708259, "dayIndex": 669735562 }, "teleinfo2": { "abonnement": "BASE", "hourTotalIndex": 0, "monthTotalIndex": 0, "dayTotalIndex": 0, "periode": 0, "yearTotalIndex": 0, "BASEIndex": 0, "puissanceApparente": 0, "consoActuelleWh": 0, "lastTotalIndex": 0 } } Pour l'icône des QA, c'est compliqué, car toujours non prévu par Fibaro. Je l'ai ajoutée pour un capteur de température et ai relevé son numéro.

A ma connaissance il n'existe pas, et il n'existera probablement jamais d'outils permettant la migration d'un VD vers un QA, l'architecture logicielle de l'un étant fondamentalement différente de celle de l'autre. A titre d'illustration, dans le VD que tu montres, il est quasiment certain que le code de chacun des boutons 1, 2, 3, 4, 5 est identique hormis quelques caractères. Lors d'une réécriture des fonctions d'un VD sous forme de QA, tout ce qui est interface utilisateur, mais aussi requêtes vers d'autres systèmes change ; en revanche le traitement des données (logique purement applicative - ou "métier") peut lui être repris.

Toi seul à le pouvoir d'apporter une réponse

Je viens de faire le test, tout s'est bien passé...

As-tu fais l'essai en changeant le 1.2 en 1.1 ? Juste pour voir (ou savoir)...