Lazer

Bienvenue sur le forum

Je suis 100% d'accord avec mes 2 compères au dessus Home Assistant, c'est gratuit (et même moins cher que Jeedom qui fait payer ses plugins et son support), la cible c'est plus ceux qui n'ont pas un gros budget, ou bien qui souhaitent se mettre à la domotique et tester quelques modules dans un coin. Et dans ces 2 cas de figure, Z-Wave n'est pas vraiment adapté. Après c'est sûr, on trouve des gens qui veulent une grosse installation en Z-Wave avec HASS, c'est peut être ton cas, mais surement pas la majorité.... et même surement une très faible minorité.... et pour cela, tu peux ajouter Z-Wave via une clé USB, donc il y en a pour tous les gouts finalement Mais bon... on s'en fout un peu de HA, c'est un contrôleur domotique parmi tant d'autre, ce n'est pas lui qui va orienter le marché d'un coté ou d'un autre. On a l'impression de revivre les discussion d'il y a quelques temps, quand Jeedom était à la mode, à lire les utilisateurs on avait l'impression que c'était l'avenir. Non, c'est juste la solution à la mode à un moment donné. Après, est-ce que Z-Wave va survivre ou pas, il est encore un peu tôt pour le dire. Ce qu'on sait maintenant, c'est qu'il vivra plus longtemps que Zigbee, ce qui est assez amusant quand on repense aux discussions des dernières années où les aficionados de Zigbee présageaient le contraire. Ce qui me désole, c'est que Thread est majoritairement basé sur Zigbee, avec cette foutue fréquence 2.4 GHz encombrée (Wi-Fi et Bluetooth pour ne citer que les 2 plus fréquents).... donc ça va pas mieux marcher que Zigbee. Le coté positif, le protocole Matter qui viendra chapeauter tout ça, ne propose Thread comme n'étant que l'une des solutions pour les modules sans fils. Il est tout à fait ouvert aux autres protocoles comme Z-Wave, mais aussi les protocole propriétaires des différents fabricants membres de l'alliance (IO, etc). Du coup, Z-Wave peut continuer à perdurer techniquement parlant. Mais pour cela, il faut qu'il y ait un marché. D'un coté tu as les installateurs pros qui ne font pas de Z-Wave (plutôt du KNX), et de l'autre le grand public qui va se ruer en masse sur le moins cher (Thread).... il ne reste que les quelques geeks comme nous... pas sûr que ça suffise à justifier la conception et la vente de modules Z-Wave... Bon après, tant que mes modules Z-Wave fonctionnent, je ne me fais pas de souci. C'est tellement fiable qu'on peut les garder 10 ans, et même bien plus... on verra. Aucune raison de les remplacer par du Thread.

Le 500 c'est effectivement du VPN IPSec, mais pour pour le VPN vers les serveurs de Fibaro, mais pour la communication entre plusieurs box HC3/HC3L en mode Gateway (Passerelle) Le 9999 également, pour le même usage. Il s'avère que c'est un port pour des communications WebSocket Source : https://forum.fibaro.com/topic/55619-local-access-can-this-be-used-for-port-forwarding/?do=findComment&comment=236330

Le problème des 2 pages de manuels de Fibaro, c'est qu'elles ne sont pas du tout didactique, donc il faut relire plusieurs fois, tester, bidouiller, et ça force de galérer ça finit par rentrer dans la tête Et aussi, ne pas oublier de chercher sur Google, ce qui nous ramène souvent sur ce forum, ou le forum officiel de Fibaro. Si on regarde le JSON d'un QuickApp (pour rappel : /api/devices/ID), on voit que les labels comme les boutons ont un attribut visible, donc théoriquement on doit pouvoir agir dessus avec les valeurs true/false. Cela dit je n'ai jamais essayé, donc on est en plein dans le cas de figure de ma 1ère ligne : tu testes avec updateView(), et si ça fonctionne, tant mieux Sinon.... tant pis Ou alors il faudra trouver une autre méthode. Il n'y a pas de propriété enable/disable, donc comme le suggère @Fredmas il faut coder sa propre logique en LUA dans le code du bouton... et agir (ou pas) en conséquence. Ce qui est sympa pour l'utilisateur, c'est de mettre un label qui sert juste à afficher une information, par exemple pour dire que l'action demandée est impossible pour telle ou telle raison. En effet, un bouton qui ne réagit pas sans donner de raison, ce n'est guère agréable.

I think it's best to serialize http requests, as @jang suggested. You can use the same name for success() arguments, the LUA compiler will use the last one. But it can be dangerous because it can lead to confusion. A best practice is to use different names.

L'heure courante récupérée avec os.time(), c'est celle du système (gérée par la carte mère avec son propre quartz) En tâche de fond, le démon NTP permet d'aller chercher l'heure à intervalle régulier sur les serveurs de référence sur Internet, et de remettre à le bonne heure l'horloge de la carte mère (qui dérive plus ou moins vite) C'est ainsi que ça fonctionne sur tous les ordinateurs. Les horaires de lever et coucher du soleil sont calculés par Fibaro en fonction de la localisation de la box (coordonnées latitude et longitude configurées dans les paramètres) Quel algorithme de calcul ils utilisent, je n'en sais rien.... Concernant la météo, il y a celle du système (/api/weather) qui est mise à jour à partir de la source configurée dans les paramètres : Dont soit YR Weather par défaut, soit un autre QA importé ou de notre création. Le bout de code que tu as donné, c'est pour mettre à jour les propriétés du module météo (un QA donc visible via /api/devices/ID), pas du système. Pour cela, il faut paramétrer ledit QA comme source de météo comme indiqué dans la capture d'écran juste au-dessus. Donc non, si on veut être précis, ton bout de code ne permet pas de "modifier les sources d'information du contrôleur", mais seulement d'ajouter une nouvelle source.... pour modifier la source, là encore, capture d'écran ci-dessus Bref, la météo, tu peux modifier la source à ta convenance. L'heure système et les horaires de coucher/lever du soleil, tu ne peux pas. Encore heureux. Ou alors tu modifies ton fuseau horaire et ta localisation, mais en réalité tu n'as pas changé les heures, mais juste "déplacé" la box dans l'espace.

En pratique aucune. Si ce n'est que dans #3, ta variable http est globale. Perso j'ai tendance à utiliser la solution #1 avec self.

Non.... !!! Parce que même si net.HTTPClient() est une fonction, ce qu'elle retourne n'est pas une fonction (mais une table), donc elle n'est pas publiée et aucun risque qu'elle soit exécutée depuis l'extérieur du QA. Donc ta variable self.http reste interne au QA. Elle est de type "table", et quand tu veux l'utiliser tu exécutes l'un de ses éléments appelé "request", qui est de type "function" => self.http:request(...)

En fait le principe de base est relativement simple, puisque ça consiste à appeler une fonction en lui donnant un paramètre, ce paramètre est une variable de type "function" (pour rappel en LUA, les fonctions sont des variables au même titre que les autres type : string, table, number, etc) La fonction appelée s'exécute... puis à un moment elle va exécuter la fonction qui lui a été donnée en paramètre (le paramètre que j'ai appelé "callback" dans mon exemple) Une fois que tu as compris ça, il n'y a plus de limite, tu peux enchainer les rappels de fonctions à volonté.

Bienvenue dans le monde merveilleux de l'asynchronisme Il faut utiliser une fonction de rappel (callback) : function QuickApp:onInit() self:debug("onInit") end local function currentData(callback) print("This function is checking regularly current meteo") local http = net.HTTPClient() http:request("http://...", { success = function() --blabla local jsonTableCurrent = json.decode(response.data) callback(true, jsonTableCurrent) end, error = function(msg) --blabla callback(false, msg) end, } end function mainCode(self) self:debug("This function is checking regularly the meteo for prevision") currentData( function(success, data) if success then self:debug(data.name) else self:error("ça s'est pas bien passé :", data) end end ) end Tu constates qu'il y a une première fonction de rappel lors du retour de http:request..... celle-ci en appelant une seconde, la tienne. C'est ultra puissant, mais pas évident à maitriser au début. Maintenant tu peux aller approfondir avec le sujet suivant : Et aussi celui-ci qui va prendre de l'importance à mesure que tu utilises des fonctions réputées pour planter de temps en temps (httprequest et json.decode) : Remarque : définir http à chaque passage de boucle n'est pas judicieux. Il vaut mieux le définir une seule fois à l'initialisation du QA, donc dans onInit, et l'utiliser par la suite. A ce sujet, voir la page 2 de 1er tuto dont j'ai donné le lien ci-dessus, on a abordé cette problématique.

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)