Lazer

C'est ça. Enfin dans la limite du courant supporté par le relai quand même. Mais pour tout ce qui est éclairage LED par exemple, ça sera ok.

ça a déjà été discuté avec @jjacques68 et une astuce donnée par @jang pour importer / mettre à jour automatiquement un fichier dans les QA. Mais perso je ne suis pas fan du tout, car ça empêche de partager facilement ses QA sur le forum (à cause des dépendances, le QA n'est plus autonome). Et une mise à jour du fichier pourrait très bien casser la compatibilité avec tous les QA existants. En effet, une évolution d'une fonction de la librairie pourrait par exemple prendre des arguments différents ou retourner des valeurs différentes et faire planter un QA qui utilisait une précédente version. Après si vous êtes rigoureux, dans le principe la solution est bonne. @jjacques68 avait fait un tuto :

Sur le forum officiel (indisponible là tout de suite...) dans la section dédiée à cette version du firmware. En ce moment, ils sont à l'écoute. EDIT : voilà le forum est de retour : https://forum.fibaro.com/forum/1279-update-5080/

Ouais je peux pas résister à la dernière nouveauté Et puis si la gestion des relais est réellement améliorée, avec protection contre les courants de démarrage et mesure de consommation, ça me permettra de retirer quelques contacteurs de puissance et pinces ampèremétriques, donc simplifier mon installation et faire de la place dans le tableau

J'ai précommandé l'IPX800 V5 avec son alimentation, plus qu'à attendre mi-octobre pour jouer avec....

C'est pareil. Le second argument est facultatif. Si tu ne le mets pas, il prend l'heure courante. Dans ton cas, en second argument, tu as mis l'heure courante (obtenue via os.time()) donc forcément il affiche la même heure. Mais si en second argument tu avais mis n'importe quel autre heure (stockée dans une variable, résultat d'un calcul savant, etc), alors il t'aurait formaté cette heure là.

202 c'est aussi un code indiquant que l'action s'est bien passée. Probablement une erreur dans la doc du Swagger. Pour le code, il faut utiliser la balise : Et tu auras bien accès à tous les langage LUA, PHP, etc : echo "Hello World";

Pour l'utiliser c'est facile, il suffit de copier/coller le contenu dans un fichier tools d'un QuickApp (ou bien directement dans le fichier main, mais c'est moins propre... on a maintenant la possibilité d'avoir plusieurs fichiers dans les QA, autant s'en servir) Ainsi toutes les fonctions de tools seront accessibles n'importe où dans ton code LUA (depuis le fichier main ou n'importe quel autre fichier)... car tools est une variable de type table avec une portée globale. Ensuite dans ton code LUA tu peux afficher un texte en couleur de cette façon : tools:debug("Texte coloré en vert") Ou bien : tools:error("Texte coloré en rouge") Mieux encore : tools:print("blue", "Texte de niveau DEBUG coloré en bleu") Avec tools:print() tu peux utiliser n'importe quelle couleur prédéfinie en HTML (chercher la liste sur Google) Je m'en sert beaucoup dans mes QA quand j'ai beaucoup d'informations à afficher, les couleurs permettent de distinguer facilement les messages avec nos yeux d'humains sur un écran rempli de texte. Une fonction bien pratique aussi pour déboguer et afficher sous forme d'arborescence le contenu d'une table : local ma_table = {"blah", "pouf", truc = {"machine", "chose", bidule = {1,2}}} tools:deepPrint(ma_table) Après tu peux parcourir la liste des fonctions dans tools, il y en a de différentes sortes : manipulation des labels, sliders, variables QA et globales, urlencode & base64, split, etc... et même gestion des modules enfants et de leurs interfaces.

Je ne suis pas certain, mais je pense que la syntaxe de ton tableau $data en PHP n'est pas bonne, particulièrement la ligne args, il doit manquer des crochets ou accolades : $data = array( "args:{}, {}", "delay: 0" );

5060 et 5061 c'est pour Asterisk, le serveur SIP intégré dans la HC3 (comme sur la HC2) Le 9999 je ne sais pas

Bienvenue sur le forum

Je ne l'ai jamais fait, mais pour les scènes il me semble que c'est normal qu'elles ne soient pas migrées (comme les modules virtuels), car seuls les modules physiques Z-Wave sont migrés. Pour tes modules en statut "non configuré", il faut que tu lances une reconfiguration de chacun des modules en défaut... un peu pénible. Aucune idée concernant la voyant rouge.

Tu n'as pas besoin de comprendre comment ça fonctionne pour utiliser tools, tout l'intérêt d'une librairie comme ça c'est justement de se simplifier la vie : réutiliser des bouts de codes fonctionnels. Après, c'est sûr, pour apprendre, progresser, s'occuper l'esprit, c'est mieux d'étudier en détail le fonctionnement. Mais bon... ce n'est pas du code très évolué.... très loin de ce que peut produire @jang dans ses librairies partagées sur le forum Fibaro officiel.

Oui comme je le disais, tools est intégré dans tous mes QuickApps Tu trouveras le fichier dans le tuto sur GEA par exemple : Je n'ai jamais fait de tuto spécifique pour mes tools, cela dit la plupart des fonctions ont un en-tête avec la syntaxe pour l'utiliser.

print() c'est la fonction normale en LUA pour afficher un message à l'écran. Dans un QA, Fibaro l'intercepte et réalise la même chose que self:debug(), donc elle affiche un message de niveau "DEBUG" dans la console. Les 3 autres niveaux TRACE WARNING et ERROR permettent de classer les messages par ordre d'importance, de criticité, de l'attention que devrait leur porter l'administrateur (donc toi) DEBUG : message informatif, sans importance autre que d'informer d'une action, afficher un message permettant de débugguer, etc TRACE : message un peu plus important qui peut potentiellement donner une information utile : par exemple je l'utilise quand je notifie le changement d'état d'un QA (modification de la propriété "value", etc) WARNING : avertissement, il se passe quelque chose d'important ERROR : attention, là c'est plus grave, quelque chose n'a pas fonctionné. Exemple : la connexion réseau vers un appareil externe a échoué Tu remarqueras que les crashs de ton code LUA son affichés avec un niveau ERROR. La console de log permet de filtrer les messages, donc on peut visualiser d'un coup d'oeil toutes les erreurs et agir en conséquence. C'est vraiment pratique, et une grosse évolution par rapport à la HC2. Personnellement, je n'utilise jamais print(), sauf pour tester un bout de code à la va-vite. Je n'utilise même plus les self:debug() ... trace, warning, error() car j'ai ma propre librairie tools qui s'utilise de la même façon, mais présente entre autres avantages de colorer les messages (avec des balises HTML), pour une visualisation entre plus claire dans la console de log. La syntaxe est la même : tools:debug(), etc, donc ça ne modifie pas vraiment mon code LUA (et j'ai paramétré la coloration syntaxique dans mon éditeur Notepad++ pour que ça soit encore plus lisible pour moi) Autre avantage de tools, c'est quelle est utilisable partout dans mes codes LUA, même dans les fonctions qui ne sont pas membres de QuickApp (et qui ne connaissent donc pas self) Tous mes QuickApps utilisent ce principe (sauf les tous premiers partagés il y a plus d'un an)

Bienvenue sur le forum

OK je vois. J'ai un système similaire, mais tout en local, avec une base de données sur le NAS, etc. Je pense que pour toi le plus simple, et de loin, c'est de conserver ton mode de fonctionnement actuel. Si tu rends ton HC3 accessible depuis l'extérieur, il faut bien évidemment utiliser un compte dédié à ton script Google avec un accès limité aux seuls modules nécessaires. Penses aussi à bien renforcer le mot de passe des autres comptes, et particulièrement du compte admin principal. Évite d'utiliser les classiques ports 80 ou 443, mais plutôt un port aléatoire assez haut. Cacher n'a jamais été une bonne solution pour renforcer la sécurité, mais ça évitera au moins 99% des scans automatiques. Idéalement il faudrait protéger la HC3 derrière un Reverse Proxy isolé en DMZ, mais il faut pour cela un nom de domaine, une machine pour faire tourner le Reverse Proxy, quelques compétences et un peu de temps.

Il est super simple de récupérer une propriété d'un module en passant par /api/devices/ID, mais comme tu le dis, il faut rendre accessible ta box depuis Internet si tu veux y accéder depuis un script hébergé à l'extérieur. Je suppose qu'il doit être possible de faire le travail en LUA dans un QuickApp en local sur la box, mais je ne sais pas ce que fait ton script, en fait je n'ai jamais programmé sur Google Drive.

Bienvenue sur le forum

Very interesting, I didn't knew about interned string. Thank you for the lesson Bon bah du coup vous pouvez continuer à utiliser des string, c'est plus lisible

Punaise le méga-boulet. Désolé pour ce bug.... qui ne touchait, pour être précis, que les VariableCache de type "string". Les boolean et number n'étaient pas affectés. Voici donc GEA version 7.35 : Corrige le bug des VariableCache de type string. GEA v7.35.lua Remarque en passant, et puisque ça parle pas mal de performances du code LUA ces derniers temps sur le forum. En informatique, manipuler un boolean (true/false), c'est comme manipuler un nombre entier, le test (comparaison de 2 valeurs) est effectué hyper rapidement en un seul cycle de CPU. A l'inverse, manipuler une chaine de caractère, nécessite de faire appel à une fonction (donc déjà plusieurs cycles de CPU) qui va faire une boucle pour comparer octet par octet tous les caractères. Du coup, c'est genre 1000x plus long que la manipulation du booléen. Bon, sur les milliers d'opérations (entrainant des millions de cycles CPU) que fait GEA, ce n'est pas la comparaison qu'une chaine de caractère dans une règle avec VariableCache qui va changer grand chose à la durée d'exécution, mais bon.... je suis formaté informaticien alors moi j'utilise des booléens quand c'est possible. Cela étant dit, pour un humain, il est plus lisible de lire une chaine de caractère contenant "OUI" ou "NON" que de voir un booléen indiquant true/false. Fait comme c'est mieux pour toi. Tout le monde n'a pas la chance d'être geek ascendant nerd Voilà, c'est tout EDIT : ce n'est pas vrai en LUA, voir plus bas

C'est toujours la plaie les modules Qubino Fil Pilote, leur firmware est buggé, Qubino refuse catégoriquement de fournir un correctif (j'ai presque réussi, puis en fait non, ça a été bloqué quand le chef est revenu de vacances), et du coup pour l'inclusion sur les box Fibaro, c'est la loterie, un coup ça passe, un coup ça ne passe pas. Évidemment Fibaro refuse d'appliquer un patch spécial, car ils disent que le bug est dans le module Qubino... et comme Qubino ne veut pas le corriger.... bref.... le serpent se mort la queue, j'ai peur qu'on n'aie jamais de solution. Regarde là, on en parle en long en large et en travers.... il est possible de les inclure en suivant une procédure bien spécifique, mais ils restent en non configurés, c'est bien pénible :

2 modules, c'est quand même bizarre.... peut être une mauvaise série ? Je ne sais pas combien de modules Fibaro j'ai, plusieurs dizaines, je n'ai jamais eu de panne complète. Et ça semble très rare vu les retours ici-même. En fait, les "non-retours" du coup. Les pannes que j'ai eu, c'est des relais qui colle (ça on sait pourquoi, à cause d'une charge inductive), ou bien un triac grillé sur un dimmer (à cause d'un court-circuit). Dans tous ces cas là, la puce Z-Wave continuait de fonctionner, donc le module communiquait bien sur le réseau.

Normalement quand ton module a l'interface battery, tu devrais voir apparaitre la bonne case à cocher dans les onglets du QuickApp : Sinon pour envoyer une notification, c'est indiqué dans la doc des scènes : https://manuals.fibaro.com/home-center-3-lua-scenes/ Perso je passe directement par l'API /notificationCenter, extrait de code LUA : local payload = { type = "GenericDeviceNotification", priority = "warning", data = { deviceId = quickApp.id, title = "Titre", text = "Message", } } local response, status = api.post("/notificationCenter", payload) if type(status) == "number" and status == 200 and type(response) == "table" then self:debug("OK") else self:error("Erreur :", json.encode(response)) end Voir la doc dans le Swagger.

ça c'est normal, plus on apprend, plus on se rend compte du chemin qui reste à parcourir pour maitriser le sujet Pas valable que pour le LUA bien sûr...