Lazer

Pour compléter, cette méthode push() fait un peu plus que la simple ligne présentée dans l'exemple. Elle affiche des logs, réalise des tests de validité de la variable donnée, des éventuelles transformations (par exemple 1 et 0 deviennent true et false), etc Donc en pratique, j'utilise également cette fonction push() en interne dans le QuickApp. Par exemple, à chaque interrogation régulière (Polling) du périphérique distant, la propriété du module est mise à jour au travers de cette fonction. Il suffit de l'appeler de la manière suivante : self:push(value) Ou bien encore : for _, child in pairs(self.childDevices) do child:push(value) end Mais je m'en sert également pour mettre les modules en état mort si la connexion réseau est perdue : self:push(true, "dead") On fait ce qu'on veut après.... J'ai fait un tuto, oui en question sorte. Disons qu'une longue explication reprenant les bases me semblait nécessaire tant les discussions partaient dans tous les sens, sans vraiment comprendre le pourquoi du comment.

Certes oui, mais la transmission du mot de passe est inévitable. La technique que je donne (qui n'est pas la mienne évidemment), présente les intérêts suivants : - quand le mot de passe est compromis, l'attaquant n'a accès qu'à un nombre très très limité de ressources, puisqu'on applique la politique du "rien" par défaut, et on ajoute spécifiquement les droits nécessaires - le changement du mot de passe est très simple puisqu'un seul appareil (ou humain) est impliqué, sans devoir faire la tournée de X machines pour mettre à jour le-dit mot de passe Si tu veux limiter grandement les risques, c'est là que la HC3 devient intéressante, car tu peux faire du https, donc théoriquement inviolable. Encore faut-il que l'appareil client en face le supporte. Cela semble être le cas de l'IPX800 v4 en cochant la case SSL (je n'ai pas testé) Bon après on parle d'un réseau local personnel, qui n'intéresse aucun attaquant. Et quand bien même tu aurais ta box domotique sur un réseau d'entreprise, cible d'un attaquant, il a autre chose à faire de ta domotique, ce sont les données de ton serveur qui vont l'intéresser. Toujours est-il que la box domotique ne devrait jamais être exposée en direct sur Internet via une redirection de port, http ou https cela ne change rien, si la faille se situe dans le serveur Web (Apache, Nginx, Lighthttpd, etc). Ma box est derrière un reverse proxy filtrant analysant toutes les requêtes avec un firewall applicatif (WAF), lui-même situé en DMZ. C'est déjà mieux. De toute façon vu que Fibaro ne permet plus d'attaquer l'IP des Home Centers en direct depuis les applications mobiles, j'ai envie de dire, problème résolu, il n'y a plus guère d'intérêt à accéder à la box en direct. Bon tout cela est HS, devrait être sur un topic dédié, et de toute façon ça a déjà été dit plusieurs fois sur le forum.

Alors, voici la solution que je propose (je l'utilise dans mes différents QuickApps). Soit un QuickApp (dans le parent ou bien dans les enfants) qui expose la fonction suivante : function QuickApp:push(value, attribute) -- ... self:updateProperty(attribute or "value", value) -- ... end Rappel de sécurité : on commence par créer un utilisateur dédié sur la HC3, avec un mot de passe spécifique, et on lui donne les droits d'accès à ce QuickApp. Dans cet exemple, l'utilisateur s'appellera "IPX800" et le mot de passe "Password" (c'est mal ) On va ensuite configurer l'appareil distant pour qu'il puisse accéder à l'API HTTP afin d'appeler la fonction push() en passant les arguments en paramètres. Note : la suite n'a rien de spécifique aux QuickApps ou à la HC3, c'était déjà comme cela sur la HC2 (et donc la HC-Lite) pour n'importe quel module Z-Wave, Plugin, Module Virtuel, Scène, ... bien sûr ils n'ont pas de fonction push(), mais des fonctions turnOn(), pressButton(), etc. Dans cet exemple on partira du principe que le module porte l'ID 123. Avec une requête de type GET : /api/callAction?deviceID=123&name=push&arg1=1 L'argument prend ici la valeur "1", mais ça pourrait être n'importe quel nombre, chaine de caractère, valeur binaire true/false, etc.... ce qui compte, c'est qu'on sache interpréter cette valeur, et surtout qu'elle corresponde au type de la propriété value du QuickApp. Remarque : ce n'est PAS la méthode recommande par Fibaro, et elle n'est d'ailleurs plus documentée. Elle est conservé pour des raisons historiques, car c'était l'API initialement disponible dans la v3 de la HC2 (et peut être même la v1.... j'en sais rien je n'étais pas né ) Cela dit elle nous arrange bien, car la méthode GET a l'avantage d'être totalement universelle, c'est à dire qu'elle fonctionne aussi bien dans la barre d'adresse de notre navigateur préféré, que depuis les appareils limités comme ceux proposés par GCE Electronics (malgré toutes leurs qualités) En pratique dans l'interface Web de l'IPX800 ça donne ça : on remarque qu'il y a 2 valeurs, selon si on fait un ON ou un OFF, c'est la seule différence entre les 2 requêtes : Avec une requête POST : /api/devices/132/push/1 Avec en données : {"args":[1]} Même remarque que précédemment, l'argument prend ici la valeur "1", mais ça pourrait être n'importe quel nombre, chaine de caractère, valeur binaire true/false, etc.... ce qui compte, c'est qu'on sache interpréter cette valeur, et surtout qu'elle corresponde au type de la propriété value du QuickApp. On peut aussi spécifier plusieurs arguments, séparés par des virgules. Remarque : c'est la méthode recommandée par Fibaro depuis la HC2 v4 et documentée dans le Swagger de la HC3 : /swagger?urls.primaryName=devices Inconvénient, elle est plus difficile à tester depuis un navigateur Web, car il faut utiliser une extension spécifique (Postman) En pratique ça donne ça avec une requête curl (depuis n'importe quelle ligne de commande Shell) : curl --request POST --user 'IPX800:Password' --data '{"args":[1]}' http://192.168.1.1/api/devices/123 PS : tu es vraiment trop impatient, tu ne laisses même pas le temps de rédiger la réponse....

Merci pour le retour Autre information, j'ai vu sur le forum officiel que les tous premiers firmwares de cette tête thermostatique étaient tellement buggués qu'on ne pouvait pas faire la mise à jour si la tête n'était pas elle-même associée à une sonde de température externe (celle-là même qui est optionnelle)

Oui tu as le bug identifié par @971jmd quelques message plus haut (information perdue dans une pluie de message HS qu'il a posté.... .... pourtant j'ai déjà fait un peu de ménage) Bref, met à jour en version 7.11.

Le topic du QuickApp Surveillance Station n'est pas du tout le bon endroit pour en parler, car en l'occurrence on ne Push rien vers ce QA (c'est du polling pur) La fonction push() existe belle et bien, mais pour un usage purement interne au QA (même si elle est exposée donc accessible via l'API, quel intérêt à part foutre la grouille : forcer le statut d'une caméra qui ne correspond plus à son état réel.... ) Bref je sépare ton message pour créer un nouveau topic de discussion général

Euh.... j'espère que personne ne met son mot de passe admin sur les autres appareils que la HC2/HC3 elle-même. TOUJOURS créer des utilisateurs dédiés, avec mot de passe spécifique, et droits restreints aux seuls et uniques modules pouvant être accédés en lecture/écriture. C'est bien simple, chaque appareil devant se connecter sur la box domotique dispose de son propre compte qu'il ne partage avec aucun autre. Exactement comme pour un humain (chacun son compte sur l'application mobile de son smartphone) Cette règle est valable tout le temps, pas que pour la box domotique : sur le NAS Synology/QNAP, Unifi Controller, etc... Pratique de sécurité de base Après pour les sockets, ouais .... ça fait du boulot en plus, pour un truc qui ne fonctionne qu'avec l'IPX800, ça teste un palliatif, comme dit, ça ne vaut pas les vrais Websockets standardisés.... Bref on verra plus tard, déjà faire en sorte que ça fonctionne.

Une seule bonne raison : quand tu partages un QA à la communauté, c'est un peu pénible d'aller expliquer aux gens qu'ils vont devoir aller configurer autant de règle Push sur leur IPX qu'il y a d'entrées/sorties à gérer. Mon QuickApp est compatible avec les 2 : - le pull : interrogation régulière de l'état de toutes les E/S - le push : réception du changement par le biais de l'API et de la fonction push() Ainsi, cela permet de couper la poire en 2 : je configure des Pushs pour toutes les E/S pour lesquelles j'ai besoin d'instantané : les relais, les entrées numériques Et du pull pour le reste (typiquement les capteurs analogiques, les pinces ampèremétriques, etc). Remarque que les E/S citées en Push sont également gérées par le Pull (au cas où on aurait raté un Push, on ne sait jamais) Si on pouvait avoir des WebSockets sur les produits GCE, ça résoudrait tous les problèmes de Push. La solution de @jjacques68 est un intermédiaire, par le biais de la socket TCP laissée ouverte. C'est plus léger et rapide que le protocole HTTP (qui est basé sur TCP lui aussi, mais bien bien lourd)

Oui mais non parce que le QuickApp Surveillance Station a un seul type de child : le type "com.fibaro.binarySwitch". Je n'allais quand même pas utiliser plusieurs classes différentes alors que tous les children sont du même type. @jjacques68 oui la connection via socket TCP en direct c'est plus léger que l'API HTTP. Malheureusement l'implémentation sur l'EcoDevice RT2 est totalement bugguée à la limite de l'inutilisable. Comme mon QuickApp se veut générique GCE Electronics (IPX800 v4, EDRT2, et on peut espérer l'IPX800 v5 si l'API ne change pas), j'ai donc choisi de n'utiliser que l'API HTTP. En fait ce que tu fais, c'est une sorte de WebSockets... il se trouve que la HC3 sait maintenant gérer les WebSockets, mais ce n'est pas le cas des appareils GCE. L'avantage des WebSockets c'est que c'est standardisé, et cela permet de laisser ouvert un canal de communication permanent entre 2 appareils, et la remonté instantanée d'information (changement d'état), sans nécessiter une reconnexion régulière (lourde) avec interrogation des données (le plus souvent pour rien). Les appareils proposant un serveur WebSocket sont encore relativement rares... chez moi j'ai Kodi (la prochaine version de mon QuickApp les exploitera), il y a aussi le logiciel Unifi Controller, mais l'API n'est pas officiellement documentée... bref c'est HS ici. Remarque : quand je parlais de ma fonction push() pour pousser les valeurs depuis un appareil externe, ça n'a évidemment rien à avoir avec le topic présent qui est censé parler des modules enfants. C'est générique à n'importe quel QuickApp, même sans enfant. Bon comme il se trouve que les enfants ont aussi besoin d'être mis à jour, du coup le push() a quand même sa place ici

@jjacques68 Je ne sais pas encore exactement ce que va faire @MAM78, donc je ne m'avance pas, je donnais juste des conseils sur la bonne pratique. Perso pour mon IPX, vu qu'il y a divers types de modules enfants (capteurs, actionneurs..... et que les actionneurs peuvent se subdiviser en différents types (binary, multilevel, etc), j'utilise plusieurs classes afin de coller au plus proche des spécifications Fibaro. La classe dédié à tous les capteurs est la plus basique, elle n'expose aucune fonction liée aux actions (pas de turnOn, etc) Donc basiquement, il y a uniquement le constructeur : function MyInput:__init(device) En pratique, j'ajoute une fonction perso (et c'est valable sur toutes mes classes, que ça soit un capteur, un actionneur, etc), permettant de pousser la valeur depuis un device externe. Typiquement depuis un événement Push sur l'IPX800 ou l'EcoDevice : function MyInput:push(value, attribute) En ce qui concerne la classe dédiée aux actionneurs de type binary, on va trouver les 2 méthodes décrites précédemment, plus les méthodes liées aux actions devant (=obligatoirement) être publiées via l'API : function MyDigitalOutput:__init(device) function MyDigitalOutput:push(value, attribute) function MyDigitalOutput:turnOn() function MyDigitalOutput:turnOff() Bien sûr, un programmeur faignant pourrait se dire que qui peut le plus peut le moins, et qu'il suffit d'utiliser la classe "MyDigitalOutput" de cet exemple pour tous les modules enfants, qu'ils soient de type capteur, actionneur, etc. Au pire, un capteur aura des méthodes turnOn et turnOff qui ne seront pas utilisées. Personnellement, je n'ai pas fait ce choix là, car je trouve cela "sale". Donc je sépare les types de modules dans des classes différentes. @MAM78 OK dans ce cas pour l'API, tu peux utiliser la doc officielle, pour une fois que Fibaro a parfaitement documenté son API, faut en abuser Le Swagger est accessible sur l'adresse IP de ta box /swagger Mais je t'ai déjà répondu dans mon précédent message avec l'API à utiliser. Comme tu peux le voir, c'est une requête de type POST, et l'IPX800 v4 ne permet pas cela (en fait on peut faire du POST, mais sans data c'est totalement inutile, et GCE refuse jusqu'à présent d'ajouter cette possibilité... je pense que le hardware limité de l'IPX800 v4 ne le permet pas) C'est justement la raison pour laquelle j'ai une fonction child:push() dans toutes mes classes enfants, cela me sert à double titre : - pousser la valeur depuis un appareil externe (IPX800, etc) - mettre à jour la valeur depuis le QuickApp lui-même (utilisation d'un code commun) Ma fonction push() fait quelques bricoles (que tu pourras étudier en détail quand je partagerai mon code), mais en synthèse il y a une seule ligne utile : function MyDigitalOutput:push(value, attribute) -- ... self:updateProperty(attribute or "value", value) -- ... end Tu noteras la possibilité de mettre à jour par défaut la "value" du device, mais on peut spécifier n'importe quoi, donc ça peut être batterylevel, power, energy, state, etc, etc

@MAM78 je n'étais pas intervenu la première fois car tu avait résolu ton problème tout seul (sans préciser comment), mais je vois que c'est la seconde fois que tu fait l'erreur. Tu tentes d'effectuer une action " callAction " sur un capteur, c'est tout simplement impossible, faux, inadapté au contexte. Les callAction appellent une action sur un actionneur (binaryswitch, multilevelswitch, etc), et par derrière la box va appeler les fonction éponyme ( turnOn() dans tes 2 exemples). Tu comprends bien qu'un capteur (sensor), n'a pas de fonction turnOn() par définition même. Un sensor ne peut exécuter aucune action en fait. Quand tu écris tes QuickApps, il faut vraiment que tu t'en tiennes au standard défini par Fibaro. Pour cela le meilleur moyen est encore de suivre l'exemple des modules Z-Wave physiques. Donc ne va pas mettre des classes avec des actions aux modules enfants de tes QuickApp, ça sera totalement incohérent. D'ailleurs @jjacques68 l'a compris à la seconde lecture comme en témoigne son 2nd EDIT. Cela étant dit, pour répondre à tes 2 questions, c'est à dire comment modifier la "value" d'un module de type capteur, il faut que tu modifies directement sa propriété "value" (et non appeler une fonction qui n'est pas censée exister.... j'insiste encore une fois) Le self:updateProperty("value", true) donné par @jjacques68 fonctionnera si le code LUA s'exécute dans le contexte du module proprement dit (le fameux self) Autrement, il faut passer par l'API pour modifier n'importe quelle propriété de n'importe quel module, même un Z-Wave (et là tu retrouves le concept des "fake-devices" inventés sur HC2) fibaro.call(ID, "updateProperty", "value", true) Ou bien encore de façon plus générale directement sur l'API http : curl --request PUT --user 'admin:password' --data '{"properties":{"value":true}}' http://192.168.1.1/api/devices/123

L'exclusion avant l'inclusion, oui c'est un classique qui devrait être effectué par précaution sur tous les modules. De mon coté j'ai aussi de plus en plus de mal à inclure un module sur mon HC2.... je pense que le réseau comment a être pas mal chargé, et ça ne doit pas aider, car l'inclusion est un processus assez bavard. En pratique, l'inclusion commence, puis ça tourne en rond pendant pas mal de temps. Dans les cas où l'inclusion ne démarre même pas, en général il faut rebooter la box.

Je vais étudier ça mais c'est pas gagné.... Ce n'est pas un évènement de la box. Ça me fait penser qu'il faut que je documente les fonctions qui sont utilisables en déclenchement instantané avec -1, ce n'est pas le cas de toutes. Je fais le SAV du QuickApp GEA sur HC3, pas de l'utilisation de GEA. Il y a le topic Support GEA pour cela. Je dis cela comme un rappel....

Exactement, le self de chaque device porte tout : le JSON, les fonctions, les variables, etc... Vraiment pratique.

Ah mais super sympa et pratique, je dis pas le contraire, mais ça reste luxueux de devoir payer, fort cher, un thermostat pour n'utiliser que son écran et interface tactile. En même temps, vu que Heatit n'a pas jugé bon d'intégrer un algorithme de régulation digne de ce nom (PID), il n'est guère utilisable pour autre chose que de l'interface homme-machine Désolé d'insister là dessus, surtout que je sais qu'un représentant de la marque nous lis, même ils sont passé à coté de quelque chose de crutial. Leur concurrent Secure (ex Horstmann) le fait depuis 10 ans dans son SRT-321 (avec un design certes très laid) Sinon il y avait le Danfoss Link RS Room Sensor qui était juste parfait pour cet usage, car c'est juste un écran + boutons sans thermostat intégré, typiquement pour piloter leurs propres têtes à distance. Le design était... disons... moyen, mais acceptable (plus que le Secure en tout cas) Mais il n'a pas dû trouver son public, car il a été abandonné. Et surtout vendu beaucoup trop cher pour ce que c'était (99€, soit plus couteux que le présent Z-Temp2)

Oui, il te "suffit" de regarder comment fait Fibaro via l'API. Mais comme l'a un jour conseillé @Krikroff le sage, je te conseille de ne pas te lancer dans des personnalisation poussées de QuickApps, car cela relève du hack, et qu'il faudra tout refaire quand Fibaro proposera enfin une méthode propre pour le faire. Patience, on finira bien par l'avoir un jour la possibilité de faire de beaux QuickApps J'y crois en tout cas. Vaux mieux passer du temps sur le code utile pour l'instant.

Toi tu as des piquets à faire

Oui c'est pratique, suffit d'ouvrir une "alvéole", ça fait plein de place... et en plus les modules chauffent moins. Et aucun risque de passer au travers.

Ah oui en effet. Je pensais aux briques creuses, elles font plutôt dans les 20cm chez moi.

Demain je pense Le colis a quitté le transitaire (mailboxde), c'est dans le camion entre l'Allemagne et la France

Ah au contraire, c'est carrément mieux qu'un mur en placo creux où tu n'as même pas la place d'y loger une boite profonde de 50mm Perso j'ai de la brique et du parpaing chez moi. Un coup de perforateur en mode burin au fond, et hop, tu as un espace de la taille que tu veux Largement de quoi y glisser 1 voire 2 modules (j'ai quelques doubles interrupteurs)

Tu dois avoir une erreur d'interface chaise-clavier, car ça fonctionne très bien chez moi (je me met toujours en anglais et pas en français, car la traduction française fait une double traduction en passant par l'anglais, donc double risque de mauvaise traduction)

Normal, tu ne peux pas associer 2 thermostat entre eux (les têtes sont des thermostats, faut il le rappeler ?) On donne une consigne (en degrés) à un thermostat, et son rôle est de réguler la charge pour atteindre la consigne donnée. En mode ON/OFF. Donc tu comprends bien que le thermostat Heatit ne peut pas contrôler le thermostat Danfoss en mode ONOFF (car le thermostat Danfoss attends une consigne, pas un ordre ON/OFF) Dans ton projet tu veux utiliser le Heatit non pas comme un thermostat, mais juste comme un écran mural bête. C'est luxueux. Donc tu es obligé de passera par la box domotique pour récupérer le consigne du thermostat (en degrés donc) que tu vas transmettre à la tête Danfoss.

Mais c'est des motorisations battantes qu'il faut mettre sur une maison comme ça, pas des volets roulants, ça va trop dénaturer.

OK... ben va pour Nice dans ce cas, mais demande quand même avant à Nice/Fibaro si ces volets sont supportés par la HC3.