MAM78 Posté(e) le 14 décembre 2020 Signaler Posté(e) le 14 décembre 2020 Sur un binarySensor n'est-il pas possible de définir des notifications ?
Lazer Posté(e) le 14 décembre 2020 Signaler Posté(e) le 14 décembre 2020 Apparemment pas. Je ne sais même pas si c'était déjà le HC2, car je n'ai jamais utilisé ces notifications intégrées (uniquement sur les détecteurs de fumée) Pour la sonnette (et tous les autres scénarios), j'utilise GEA en pratique. Sinon faut remonter l'info à Fibaro pour qu'ils ajoutent cette possibilité, ça ne doit pas être bien difficile.
Dragoniacs Posté(e) le 14 décembre 2020 Signaler Posté(e) le 14 décembre 2020 Profite en pour leur demander la possibilité de changer les icônes aussi...Envoyé de mon RMX1993 en utilisant Tapatalk
MAM78 Posté(e) le 14 décembre 2020 Signaler Posté(e) le 14 décembre 2020 (modifié) Pour les icônes c'est déjà possible. Voir mon image ci-dessus Modifié le 14 décembre 2020 par MAM78
Dragoniacs Posté(e) le 14 décembre 2020 Signaler Posté(e) le 14 décembre 2020 Moi je n'y arrive pas sur les sensorsEnvoyé de mon RMX1993 en utilisant Tapatalk
MAM78 Posté(e) le 14 décembre 2020 Signaler Posté(e) le 14 décembre 2020 (modifié) Quelle est la commande HTTP pour simuler un passage à ON sur BinarySensor ? J'ai essayé celle-ci qui ne semble pas fonctionner : /api/callAction?deviceID=242&name=turnOn Erratum : C'est bon, ça marche Modifié le 14 décembre 2020 par MAM78
MAM78 Posté(e) le 15 décembre 2020 Signaler Posté(e) le 15 décembre 2020 Comment est-ce que l'on peut récupérer le deviceID du Child dans les fonctions de la partie class 'MyChild' la commande fibaro:getSelfId() que nous utilisions sur la HC2 ne semble plus fonctionner comme ça dans un QuickApp ?
jjacques68 Posté(e) le 15 décembre 2020 Signaler Posté(e) le 15 décembre 2020 (modifié) dans la class donc dans les child, il me semble avec un simple self.id self.name self.type Modifié le 15 décembre 2020 par jjacques68
Lazer Posté(e) le 15 décembre 2020 Signaler Posté(e) le 15 décembre 2020 Exactement, le self de chaque device porte tout : le JSON, les fonctions, les variables, etc... Vraiment pratique.
MAM78 Posté(e) le 15 décembre 2020 Signaler Posté(e) le 15 décembre 2020 Nickel, ça marche. je vais bientôt pouvoir sortir mon premier QuickApp pour le Doorbird
MAM78 Posté(e) le 15 décembre 2020 Signaler Posté(e) le 15 décembre 2020 (modifié) En attendant voici un premier aperçu du QuickApp Doorbird Manager : Liste des premières fonctions assurées : Détecteur de l'utilisation de Sonnette Détecteur de mouvement Détecteurs de l'utilisation d'un badge RFI Actionneurs d'ouverture de relais Actionneur pour activer la lumière infrarouge Modifié le 15 décembre 2020 par MAM78 2
MAM78 Posté(e) le 15 décembre 2020 Signaler Posté(e) le 15 décembre 2020 (modifié) Pourriez-vous m'indiquer quelle est la commande http pour activer un Child device de type : com.fibaro.motionSensor : Est-ce avec cette commande ou un autre ? http://xxx.xxx.xxx.xxx/api/callAction?deviceID=250&name=turnOn Modifié le 15 décembre 2020 par MAM78
jjacques68 Posté(e) le 16 décembre 2020 Signaler Posté(e) le 16 décembre 2020 (modifié) ben oui, tu appelles la méthode "turnOn" de ton Child ! tu as donc une fonction turnOn dans la class du Child ! Il y a quoi dans cette fonction ? ou j'ai pas compris la question... EDIT : Je pense que j'avais pas compris. Du coup je penche vers un soucis de droits d'accès. La commande semble être OK... (ou alors c'est pas la commande turnOn ??) L'équipement qui commande ton Child doit avoir le droit d'accès sur la HC3... RE EDIT : En fait je pense pas que le turnOn fonctionne ... Il apparaît pas dans les actions d'un MotionSensor dans l'API. Si j'étais à ta place, je créerai la méthode trunOn dans la class avec un self:updateProperty("value", true) désolé j'ai pas de quoi tester sous la main... Modifié le 16 décembre 2020 par jjacques68
Lazer Posté(e) le 16 décembre 2020 Signaler Posté(e) le 16 décembre 2020 @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 1
jjacques68 Posté(e) le 16 décembre 2020 Signaler Posté(e) le 16 décembre 2020 Il y a 3 heures, Lazer a dit : Donc ne va pas mettre des classes avec des actions aux modules enfants de tes QuickApp, ça sera totalement incohérent. là tu parles bien du cas spécifique de @MAM78 ? parce que pour des child "actif", typiquement les child affectés aux sorties d'un IPX par exemple, sont de type "bianrySwitch", donc possèdent bien 2 méthodes "action" ! J'ai un doute, à quoi ressemblerait la requête sans utiliser curl ?
MAM78 Posté(e) le 16 décembre 2020 Signaler Posté(e) le 16 décembre 2020 Il y a 3 heures, Lazer a dit : Donc ne va pas mettre des classes avec des actions aux modules enfants de tes QuickApp, ça sera totalement incohérent. Je comprend bien même si ça fonction. J'ai testé. Mais ma question est sur le type de requête HTTP qui doivent être lancée pour agir sur l'état du Motion Sensor. Ma requête doit forcément être du type http://loging:pw@xxx.xxx.xxx.xxx/api/ .... Puisque c'est mon équipement Doorbird qui va envoyer la requête qui doit être de type HTTP, (idem que pour un IPX800) afin de signifier le changent état "violé" ou "breached"
Lazer Posté(e) le 16 décembre 2020 Signaler Posté(e) le 16 décembre 2020 @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
jjacques68 Posté(e) le 16 décembre 2020 Signaler Posté(e) le 16 décembre 2020 @Lazer, merci pour ces explications plus qu'intéressantes ! Avec ce que tu dis, je pense avoir pas trop mal fait mon QA IPX , du moins la partie Child... Quoique je me rends compte que j'ai pas de child pour le seul compteur que j'utilise... j'envoi la valeur directement dans un autre QA dédié (gestion de l'eau). Après je l'ai réalisé d'une manière, j'ai l'impression, peu commune... mais qui fonctionne à merveille. Le parent discute à 100% en TCP avec l'IPX. L'IPX ne met pas à jour les Child directement par requete push, c'est le parent qui fait ce boulo selon ce qu'il reçoit sur la socket. Et biensur j'utilise les Child partout dans les scènes et autres... désolé @MAM78, je ferme la parenthèse.
MAM78 Posté(e) le 16 décembre 2020 Signaler Posté(e) le 16 décembre 2020 Merci pour tes conseils biens avisés. Il y a 1 heure, Lazer a dit : 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. C''est pourtant ce que tu as fait dans ton Quick App Surveillance Station Synology (une seule classe) , dont je me suis grandement inspiré pour développer (c'est une grande source d'apprentissage pour moi) mon Quick App Dorbird Manager. Sauf, si tu as une autre version de ce QA que je n'aurais pas vue. Je vais reprendre ta suggestion de séparer les classes et en faire une spécifique : function MyInput:push(value, attribute)
MAM78 Posté(e) le 16 décembre 2020 Signaler Posté(e) le 16 décembre 2020 il y a 5 minutes, jjacques68 a dit : L'IPX ne met pas à jour les Child directement par requete push, c'est le parent qui fait ce boulo selon ce qu'il reçoit sur la socket Ca m'intéresse de voir ton code sur le fonctionnement avec la socket. Pourquoi avoir privilégier la socket à l'utilisation des push de l'IPX ?
Lazer Posté(e) le 16 décembre 2020 Signaler Posté(e) le 16 décembre 2020 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
Lazer Posté(e) le 16 décembre 2020 Signaler Posté(e) le 16 décembre 2020 (modifié) il y a 14 minutes, MAM78 a dit : Pourquoi avoir privilégier la socket à l'utilisation des push de l'IPX ? 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) Modifié le 16 décembre 2020 par Lazer
MAM78 Posté(e) le 16 décembre 2020 Signaler Posté(e) le 16 décembre 2020 (modifié) Ok, je découvre le mode de dialogue via et la socket qui me semble intéressant, d'autant que je suppose qu'il n'est plus nécessaire mettre en claire les mots de passe dans les requêtes push de l'IPX. puisqu'il n'y a plus besoin des Push Si effectivement c'est buggué sur l'EcoDevice RT2, je comprend ta solution. Néanmoins ne serait-il pas possible de l'implémenter pour les modules GCE qui sont compatibles et fiables via les sockets ? Mais c'est probablement encore un boulot en plus Modifié le 16 décembre 2020 par MAM78
jjacques68 Posté(e) le 16 décembre 2020 Signaler Posté(e) le 16 décembre 2020 il y a 20 minutes, MAM78 a dit : Pourquoi avoir privilégier la socket à l'utilisation des push de l'IPX ? ma première version était par requête http, pour le pilotage et le retour d'état. Y avait pas encore la notion de Parent/Child à ce moment là. Je rencontrais des problèmes étranges lors ce que je pilotais plusieurs sorties simultanément avec la commande fibaro:call({id1, id2, id3}, "turnOn") une fois sur deux, j'avais id2 qui n'était pas pris en compte. je devais séparer en 3 appels, intercallant une tempo( setTimeout) pour que les 3 s'allument. Je sais pas pourquoi, c'est comme si l'IPX, n'arrivait pas à traiter plusieurs requêtes simultanément. Bref ça m'a saoulé, les Parents/Child sont arrivés, j'ai l'habitude des socket, et voilà. Je ne regrette pas du tout. Le code dans le parent, qui décrypte la trame reçue à chaque changement d'une entrée/sortie/compteur, est peu lourd, surtout que j'ai fais un petit IHM dans le parent pour avoir une visu sur l'état de l'IPX : Mais ça tourne nickel, et plus de soucis. Je peux partager le code avec plaisir, mais pas sur ce topic, je te laisse en ouvrir un... Après ça pas du code grand public
Messages recommandés