Barelle

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)...

Si tel est le cas, la créativité du développeur stagiaire de Fibaro mérite toute mon admiration

Début de réalisation en 5.040.37, actuelle 5.040.37, la dernière... Je vois mal l'intérêt de cette info