jluc2808 Posté(e) le 23 mai 2023 Signaler Posté(e) le 23 mai 2023 re bonjour , je voudrais simuler un clic sur un walli controller, lorsque le store venitien qu'il commande (via association de groupe) est en position fermée ou ouverte (je m'explique : lorsque les walli controller commandes les BSO, il veulent être 'réveiller' pour envoyer une commande - même si le walli est alimenté par du 24DC) donc actuellement , si je monte ou descend un BSO et si je le stoppe , pas de souci la commande suivante est prise en compte par contre si je le laisse aller sur les butées hautes / basses (donc pas de stop à l'inter) pour lui envoyer une autre commande je suis obligé d'appuyer une 1ère fois sur l'inter (attendre la validation par anneau vert) et ensuite la commande est prise en compte donc mon abjectif est de supprimer ce double appui que j'ai appelé 'reveil' par un ordre GEA qui va envoyer le clic manquant au walli lorsque butée basse et haute là je vois pas comment coder cela. âme charitable IN
fredokl Posté(e) le 23 mai 2023 Signaler Posté(e) le 23 mai 2023 Salut @jluc2808, essai ça. GEA.add({"Value", 84, true},-1,"",{"Property",{452,457,460,463}, "Value", "white"}) GEA.add({"Value", 84, false},-1,"",{"Property",{452,457,460,463}, "Value", "green"})
Lazer Posté(e) le 23 mai 2023 Signaler Posté(e) le 23 mai 2023 @jluc2808 Nickel tu es au bon endroit Pour info sur les subtilités de la HC3 à connaitre : Prenons l'exemple de ton premier module Walli dont l'ID est 452 Dans ton navigateur, tu peux voir son JSON complet en utilisant cette URL : /api/devices/452 Il y a toutes les infos qui concernent le module. Parmi les paramètres importants, il y a les propriétés, qui sont toutes accessibles dans la sous-rubrique "properties". Ces propriétés peuvent généralement être modifiées depuis GEA à l'aide de différentes actions telles que "Value", "Property", etc... En fait l'action "Value" va mettre à jour uniquement la propriété "value" de ton module, alors que l'action "Property" est plus large car il permet de mettre à jour n'importe laquelle des propriétés du module (enfin presque, certaines sont en lecture seule ou bien pas franchement recommandé de les modifier) Dans tes lignes plus haut, tu essayes de mettre à jour la propriété "ringUpperColor". Est-ce qu'elle existe bien ? Car elle n'existe pas sur le Wall Dimmer à ma disposition. Si c'est bien le cas, alors tu peux effectivement utiliser "Property". Ensuite plus bas dans le JSON, tu as la rubrique "actions" : Ce sont des fonctions que tu peux appeler, le chiffre représente le nom d'argument(s) attendu(s). On retrouve les classiques turnOn et turnOff que la plupart des actionneurs disposent (single switch, dimmer, etc), mais aussi des spécifiques à tel ou tel module, comme "setRingOnColor", etc Encore une fois dans mon Walli Dimmer la fonction "setRingsLightMode" que tu essayes d'appeler n'existe pas, mais elle doit exister sur ton Walli Controller je suppose. Quoi qu'il en soit, tu ne peux pas appeler cette fonction comme tu mettrais à jour la propriété d'un module. Dans ce cas, il faudrait utiliser l'action "Call" de GEA : {"Call", {452,457,460,463}, "setRingsLightMode", "on"} Par ailleurs cette suite d'ID ce n'est pas très ergonomique pour s'y retrouver. Tu peux utiliser un tableau d'ID, dont le prototype est présent dans le fichier config donné en exemple à l'importation de GEA. Et de nombreux exemples sur le forum, voir ici ou sur le Showroom GEA. 1
jojo Posté(e) le 23 mai 2023 Signaler Posté(e) le 23 mai 2023 bienvenue enfin au bon endroit ... on va commencer simple par les actions : la syntaxe semble ok, si tu es sûr dy nom des propriétés (cfr json du module) et des valeurs qu'elle peuvent prendre . (je n'ai pas de Walli, donc je ne peut pas valider) Pour les conditions (idem, je n'ai pas FGD, donc je ne peut rien dire). Est-ce que les FGD ont un TurnOn, turnOff ? Si oui, ok de mettre l(id pour tester s'il est allumé. S'il est off, j'utiliserais {"TurnOff", <id module>} au lieu de <id module>! Et comment le module répond si allumé à 1 % (On ou Off ?) Je ferais une règle à la fois pour être sûr que syntaxe ok
jluc2808 Posté(e) le 23 mai 2023 Signaler Posté(e) le 23 mai 2023 (modifié) ah oui tout ça, merci de ces explications j'ai appelé l'api/devices/452 1 - dans les actions j'ai : setRingsLightMode ==> {"Call", {452,457,460,463}, "setRingsLightMode", "on"} 2 - dans properties j'ai "ringBottomColor": "white", "ringBrightness": 100, "ringLightMode": "off", "ringUpperColor": "white", ==> {"Property",{452,457,460,463},"ringUpperColor","White"} {"Property",{452,457,460,463},"ringBottomColor","White"} 3 - maintenant j'ai un doute sur la syntaxe de la condition (ON ou OFF pour le module id=84) dans properties j'ai "state": false, "value": 0 ==> soit je prend ce que m'a proposé @fredokl GEA.add({"Value", 84, true},-1,"",{Actions}) ou j'avais essayé ce que j'avais trouvé dans la doc dans la partie test l'état d'un module avec l'exemple de id[TV] GEA.add(84!,-1,"",{Actions}) GEA.add(84,-1,"",{Actions}) 4 - pour le tableau des id, oui je vais voir à utiliser id[nom_du_module] mais comme j'ai mis des noms à rallonge Modifié le 23 mai 2023 par jluc2808
jluc2808 Posté(e) le 23 mai 2023 Signaler Posté(e) le 23 mai 2023 (modifié) il y a 20 minutes, jojo a dit : bienvenue enfin au bon endroit ... on va commencer simple par les actions : la syntaxe semble ok, si tu es sûr des nom des propriétés (cfr json du module) Est-ce que les FGD ont un TurnOn, turnOff ? Si oui, ok de mettre l(id pour tester s'il est allumé. S'il est off, j'utiliserais {"TurnOff", <id module>} au lieu de <id module>! oui j'ai regardé dans le json, les noms des propriétés sont OK (je les avaient prises à partir d'un scenario BLOCK mis en LUA) dans les actions j'ai un TurnOff et TurnOn et j'ai posté juste au dessus les properties dispos : value ou state edit : je viens de regarder , quand j'allume la lampe du FGD j'ai "state": true, "value": 99 et quand elle est éteinte "state": false, "value": 0 Modifié le 23 mai 2023 par jluc2808
jluc2808 Posté(e) le 24 mai 2023 Signaler Posté(e) le 24 mai 2023 (modifié) je reviens après pas mal de testes qui ne donnent rien - pour la partie conditions j'ai testé les syntaxes suivantes : {"Property", 84, "value", 0} et {"Property!", 84, "value", 0} fonctionne {"Value", 84, 0} et {"Value!", 84, 0} fonctionne mais pas {"Value", 84, true ou false} 84 fonctionne mais pas 84! - pour la partie action j'ai testé toutes les syntaxes suivantes et aucune ne fonctionnent: {"Call", {452,457,460,463}, "setRingsLightMode", "on"} ==> ne donne rien après avoir regardé dans l'api/device/452 le json du ringLightMode est à off {"Property",{452,457,460,463},"ringBottomColor","green"} ==> ne donne rien dans le json le ringButtomColor est à white {"Parameter",452,150,3} ==> rapporte une Erreur, vérifier : ["Parameter",[452,150,3]] Modifié le 24 mai 2023 par jluc2808
jluc2808 Posté(e) le 24 mai 2023 Signaler Posté(e) le 24 mai 2023 Il y a 15 heures, jluc2808 a dit : re bonjour , je voudrais simuler un clic sur un walli controller, lorsque le store venitien qu'il commande (via association de groupe) est en position fermée ou ouverte (je m'explique : lorsque les walli controller commandes les BSO, il veulent être 'réveiller' pour envoyer une commande - même si le walli est alimenté par du 24DC) donc actuellement , si je monte ou descend un BSO et si je le stoppe , pas de souci la commande suivante est prise en compte par contre si je le laisse aller sur les butées hautes / basses (donc pas de stop à l'inter) pour lui envoyer une autre commande je suis obligé d'appuyer une 1ère fois sur l'inter (attendre la validation par anneau vert) et ensuite la commande est prise en compte donc mon abjectif est de supprimer ce double appui que j'ai appelé 'reveil' par un ordre GEA qui va envoyer le clic manquant au walli lorsque butée basse et haute là je vois pas comment coder cela. âme charitable IN bonjour, est-ce que quelqu'un aurait une piste sur ce point ?
Lazer Posté(e) le 24 mai 2023 Signaler Posté(e) le 24 mai 2023 Je suis en train de penser à un truc en lisant ton dernier message, mais encore une fois sachant que je n'ai pas ce module "Walli Controller". Il est alimenté par secteur ou par batterie ? Car si c'est sur batterie, il est endormi et ne répondra pas aux sollicitations. Autrement dit tu ne pourras pas lui demander de s'allumer/éteindre à la demande. C'est un principe de base du Z-Wave. J'avais fait un récapitulatif à ce sujet d'ailleurs : Ensuite, si ce module est bien sur secteur (attention cela se configure lors de l'inclusion du module, il faut l'exclure et le réinclure pour changer de mode d'alimentation), alors il est réveillé, participe au routage du réseau, etc. Du coup, tu peux le piloter, il faut juste que tu trouves la bonne syntaxe / commande / paramètres à envoyer. Mais attention, modifier les propriétés du module n'est pas la bonne solution. Car ça va modifier les propriétés de la représentation logique du module, c'est à dire celle qui est stockée dans la base de données de la box. Mais ça n'enverra aucune consigne au module physique (trame Z-Wave) Pour cela, il faut bien passer par les actions, donc avec GEA il faut utiliser "Call" comme je te l'ai indiqué. Reste donc à exécuter la bonne action, avec le bon paramètre. Et là dessus je ne sait pas t'aider, n'ayant pas ce module, je ne peux pas reproduire. Remarque, si tu veux mettre GEA hors de cause, tu peux tenter l'opération dans une scène en mode bloc, puis la convertir en LUA. Tu trouveras alors les bons arguments à utiliser.... normalement en LUA ça sera dans une fonction hub.call()
jluc2808 Posté(e) le 25 mai 2023 Signaler Posté(e) le 25 mai 2023 @lazer, le module est sur secteur et a été inclus dans ces conditions (sur secteur), donc pas de phénomène de réveil lié à la batterie ce que je constate avec son usage : c'est que en mode association (pas en mode scène) hormis quand le module est configuré en mode : simple ou double donc dans min cas en store vénitien il faut que je clic 2 fois pour avoir une action - dans le cas ou le store a été arrêté via le bouton (donc 1 clic) alors le clic suivant est pris en compte sans délai (montée, descente ou orientation des lamelles ) , mais dans le cas ou le BSO est arrivé en bout de course (haute ou basse) alors l'action suivante, répond avec l'anneau qui clignote en vert (comme pour sire j'ai pris en compte la commande) mais rien ne se passe et c'est seulement sur le clic suivant qu'une action se déclenche (montée/descente/orientation des lames) j'ai l'impression, mais je peux me tromper, que le premier clic après action est comme si c'était systématiquement un stop (appui quand le volet descend ça stoppe) est-ce qu'il y a une syntaxe en GEA pour voir ce qui se passe sur cet appui pour du beurre ? pour les changements de couleur des anneaux des walli controller - je retiens ta solution de faire une scène en mode block , puis conversion en LUA et voir ce que la HC3 à coder. le code généré est : hub.call({[1] = 452, [2] = 457, [3] = 460, [4] = 463, }, 'setRingsLightMode', "on") hub.call({[1] = 452, [2] = 457, [3] = 460, [4] = 463, }, 'setProperty', "ringUpperColor","white") hub.call({[1] = 452, [2] = 457, [3] = 460, [4] = 463, }, 'setProperty', "ringBottomColor","white") donc si je reprend le GEA - suite à la condition l'action devrait être {"Property", {452,457,460,463}, "ringUpperColor", "white"}, ça fait parti des tests que j'ai déjà réalisé (voir mon post précédent) et rien ne se passe , quand je consulte le json du 452 alors ringUpperColor est toujours à green idem pour setRingsLightMode mon action a été codifiée en {"Call", {452, 457, 460, 463}, "setRingsLightMode", "on"} , idem rien ne se passe et si je regarde le json le ringLightMode est à Off
Lazer Posté(e) le 25 mai 2023 Signaler Posté(e) le 25 mai 2023 Il y a 2 heures, jluc2808 a dit : est-ce qu'il y a une syntaxe en GEA pour voir ce qui se passe sur cet appui pour du beurre ? Euh... Non... en fait pas sûr de bien comprendre ta demande. Mais si tu veux débugguer le fonctionnement du module, ce n'est pas GEA qu'il faut utiliser, mais le faire à la main en LUA dans une scène dédiée, pour bien comprendre la logique du fonctionnement de ces modules (vu que je n'ai ni Walli Controller, ni BSO, je n'ai aucune idée du comportement attendu) Une fois que c'est au point, même conseil qu'hier, tu pourras le retranscrire dans GEA. Il y a 2 heures, jluc2808 a dit : action devrait être {"Property", {452,457,460,463}, "ringUpperColor", "white"}, ça fait parti des tests que j'ai déjà réalisé (voir mon post précédent) et rien ne se passe Normal, je n'ai expliqué hier pourquoi. Modifier les propriétés d'un module n'agit que sur sa représentation dans la DB, mais ne déclenche aucune action sur le module Z-Wave proprement dit. Il y a 2 heures, jluc2808 a dit : mon action a été codifiée en {"Call", {452, 457, 460, 463}, "setRingsLightMode", "on"} , idem rien ne se passe Et là je viens de comprendre pourquoi, en allant lire le code source. C'est une limitation de GEA, l'action Call ne peut pas prendre un tableau d'ID. Essaye avec 1 seul ID, et ça devrait fonctionner. Si c'est OK, je verrai pour modifier GEA afin qu'il prenne plusieurs ID. PS : la doc de syntaxe ne donne qu'une seul ID pour cette action Call, il n'y a pas d'exemple avec plusieurs ID... du coup la doc est correcte.
jluc2808 Posté(e) le 25 mai 2023 Signaler Posté(e) le 25 mai 2023 Il y a 2 heures, Lazer a dit : Euh... Non... en fait pas sûr de bien comprendre ta demande. Mais si tu veux débugguer le fonctionnement du module, ce n'est pas GEA qu'il faut utiliser, mais le faire à la main en LUA dans une scène dédiée, pour bien comprendre la logique du fonctionnement de ces modules (vu que je n'ai ni Walli Controller, ni BSO, je n'ai aucune idée du comportement attendu) Une fois que c'est au point, même conseil qu'hier, tu pourras le retranscrire dans GEA. Normal, je n'ai expliqué hier pourquoi. Modifier les propriétés d'un module n'agit que sur sa représentation dans la DB, mais ne déclenche aucune action sur le module Z-Wave proprement dit. Et là je viens de comprendre pourquoi, en allant lire le code source. C'est une limitation de GEA, l'action Call ne peut pas prendre un tableau d'ID. Essaye avec 1 seul ID, et ça devrait fonctionner. Si c'est OK, je verrai pour modifier GEA afin qu'il prenne plusieurs ID. PS : la doc de syntaxe ne donne qu'une seul ID pour cette action Call, il n'y a pas d'exemple avec plusieurs ID... du coup la doc est correcte. je ne suis pas certains d'avoir les compétences pour faire ce debugging du module walli controller en LUA, mais qui ne tente rien pour le changement de couleur j'ai oublié de mentionné que j'ai aussi fait l'essai avec un changement directement sur les paramètres, sauf si je me suis trompé dans la syntaxe , j'ai systématiquement un message d'erreur GEA.add({"Value", 84, true},-1,"",{"Parameter", 462, 150, 3}) je vais tester avec un Call unitaire comme précisé
jluc2808 Posté(e) le 25 mai 2023 Signaler Posté(e) le 25 mai 2023 j'ai regardé pour faire une scène en mode block puis transformation en LUA, mais la seule possibilité de condition est en mode scene centrale pas en mode store venitien alors pour avoir plus d'info j'ai le json du module et de son module parent Pour le module parent { "id": 334, "name": "334 - inter studio ch haut parent", "roomID": 232, "view": [ ], "type": "com.fibaro.zwaveDevice", "baseType": "com.fibaro.device", "enabled": true, "visible": false, "isPlugin": false, "parentId": 1, "viewXml": false, "hasUIView": false, "configXml": false, "interfaces": [ "polling", "zwave", "zwaveAssociation", "zwaveConfiguration", "zwaveMultiChannelAssociation", "zwaveSlaveRouting" ], "properties": { "associations": [ { "endPointId": 0, "groups": [ { "groupInfo": { "commands": [ { "command": "Device Reset Locally Notification", "commandClass": "Command Class Device Reset Locally" }, { "command": "Central Scene Notification", "commandClass": "Command Class Central Scene" }, { "command": "Multilevel Sensor Report", "commandClass": "Command Class Sensor Multilevel" } ], "name": "Lifeline", "profile": "General: Lifeline" }, "id": 1, "multiChannel": { "bitAddressable": false, "max": 1, "set": [ { "endPointId": [ 0 ], "nodeId": 1 } ], "view": [ { "endPointId": [ 0 ], "nodeId": 1 } ] }, "singleChannel": { "max": 1, "set": [ ], "view": [ ] } }, { "groupInfo": { "commands": [ { "command": "Basic Set", "commandClass": "Command Class Basic" } ], "name": "On/Off (1)", "profile": "Control: Control Key 1" }, "id": 2, "multiChannel": { "bitAddressable": false, "max": 5, "set": [ ], "view": [ ] }, "singleChannel": { "max": 5, "set": [ ], "view": [ ] } }, { "groupInfo": { "commands": [ { "command": "Switch Multilevel Set", "commandClass": "Command Class Switch Multilevel" } ], "name": "Dimmer (1)", "profile": "Control: Control Key 1" }, "id": 3, "multiChannel": { "bitAddressable": false, "max": 5, "set": [ ], "view": [ ] }, "singleChannel": { "max": 5, "set": [ ], "view": [ ] } }, { "groupInfo": { "commands": [ { "command": "Basic Set", "commandClass": "Command Class Basic" } ], "name": "On/Off (2)", "profile": "Control: Control Key 2" }, "id": 4, "multiChannel": { "bitAddressable": false, "max": 5, "set": [ ], "view": [ ] }, "singleChannel": { "max": 5, "set": [ ], "view": [ ] } }, { "groupInfo": { "commands": [ { "command": "Switch Multilevel Set", "commandClass": "Command Class Switch Multilevel" } ], "name": "Dimmer (2)", "profile": "Control: Control Key 2" }, "id": 5, "multiChannel": { "bitAddressable": false, "max": 5, "set": [ ], "view": [ ] }, "singleChannel": { "max": 5, "set": [ ], "view": [ ] } }, { "groupInfo": { "commands": [ { "command": "Basic Set", "commandClass": "Command Class Basic" }, { "command": "Switch Multilevel Set", "commandClass": "Command Class Switch Multilevel" } ], "name": "Multidevice", "profile": "Control: Control Key 3" }, "id": 6, "multiChannel": { "bitAddressable": false, "max": 5, "set": [ { "endPointId": [ 1 ], "nodeId": 17 } ], "view": [ { "endPointId": [ 1 ], "nodeId": 17 } ] }, "singleChannel": { "max": 5, "set": [ ], "view": [ ] } }, { "groupInfo": { "commands": [ { "command": "Switch Multilevel Set", "commandClass": "Command Class Switch Multilevel" } ], "name": "Slats", "profile": "Control: Control Key 4" }, "id": 7, "multiChannel": { "bitAddressable": false, "max": 5, "set": [ { "endPointId": [ 1 ], "nodeId": 17 } ], "view": [ { "endPointId": [ 1 ], "nodeId": 17 } ] }, "singleChannel": { "max": 5, "set": [ ], "view": [ ] } } ] } ], "categories": [ "other" ], "configured": true, "dead": false, "deadReason": "", "deviceControlType": 1, "deviceIcon": 28, "deviceRole": "Other", "deviceSpecificData": "h'00000000000031cd", "deviceSpecificIdType": "Serial Number", "deviceState": "Configured", "endPointId": 0, "icon": { }, "lastWorkingRoute": [ 1 ], "lastWorkingRouteRequestStatus": "ok", "lastWorkingRouteRequestTimestamp": 0, "lastWorkingRouteResponseTimestamp": 1684765273, "log": "", "logTemp": "", "manufacturer": "", "markAsDead": true, "model": "", "neighborList": [ 1, 54, 59, 75, 81, 86, 92, 97, 107, 115, 120, 125, 130, 135, 140, 145, 150, 157, 162, 168, 174, 180, 186, 191, 197, 203, 209, 215, 221, 227, 233, 239, 248, 254, 263, 269, 275, 281, 293, 313, 328, 331, 337, 340, 343, 346, 349, 352, 356, 359, 362, 365, 368, 371, 374, 377, 380, 383, 386, 389, 392, 398, 417, 421, 424, 427, 430, 433, 436, 439, 442, 445, 448, 451, 456, 459, 462, 467, 470, 473, 476, 479, 489, 508, 511, 514, 517, 520, 523, 535, 557, 575, 577, 582 ], "neighborListRequestStatus": "ok", "neighborListRequestTimestamp": 0, "neighborListResponseTimestamp": 1684765273, "nodeId": 63, "parameters": [ { "id": 13, "lastReportedValue": 100, "lastSetValue": 100, "size": 1, "value": 100 }, { "id": 20, "lastReportedValue": 6, "lastSetValue": 6, "size": 1, "value": 6 }, { "id": 150, "lastReportedValue": 1, "lastSetValue": 1, "size": 2, "value": 1 }, { "id": 151, "lastReportedValue": 1, "lastSetValue": 1, "size": 2, "value": 1 }, { "id": 152, "lastReportedValue": 99, "lastSetValue": 99, "size": 2, "value": 99 }, { "id": 153, "lastReportedValue": 99, "lastSetValue": 99, "size": 2, "value": 99 } ], "parametersTemplate": 872, "pollingInterval": -1, "pollingTimeSec": 0, "productInfo": "1,15,35,1,16,0,7,0", "saveLogs": true, "securityLevel": "S0", "securitySchemes": [ "S0" ], "serialNumber": "h'00000000000031cd", "supportedDeviceRoles": [ "Other" ], "useTemplate": true, "userDescription": "", "zwaveCompany": "Fibargroup", "zwaveInfo": "3,7,14", "zwaveSoftwareVersion": { }, "zwaveVersion": "7.0" }, "actions": { "getLastWorkingRoute": 0, "getNeighborList": 0, "getParameter": 1, "poll": 0, "reconfigure": 0, "requestNodeNeighborUpdate": 0, "setParameter": 2 }, "created": 1683728489, "modified": 1684620534, "sortOrder": 270 } et pour le module inter walli lui-même { "id": 335, "name": "inter studio chambre haut", "roomID": 232, "view": [ { "assetsPath": "dynamic-plugins/com.fibaro.fgwc201", "name": "com.fibaro.fgwc201", "translatesPath": "/assets/i18n/com.fibaro.fgwc201", "type": "ts" } ], "type": "com.fibaro.FGWC201", "baseType": "com.fibaro.remoteController", "enabled": true, "visible": true, "isPlugin": false, "parentId": 334, "viewXml": false, "hasUIView": false, "configXml": false, "interfaces": [ "FGWC201", "fibaroFirmwareUpdate", "zwave", "zwaveCentralScene", "zwaveIndicator", "zwaveMultiChannelAssociation", "zwaveProtection" ], "properties": { "parameters": [ { "id": 13, "lastReportedValue": 100, "lastSetValue": 100, "size": 1, "value": 100 }, { "id": 20, "lastReportedValue": 6, "lastSetValue": 6, "size": 1, "value": 6 }, { "id": 150, "lastReportedValue": 1, "lastSetValue": 1, "size": 2, "value": 1 }, { "id": 151, "lastReportedValue": 1, "lastSetValue": 1, "size": 2, "value": 1 }, { "id": 152, "lastReportedValue": 99, "lastSetValue": 99, "size": 2, "value": 99 }, { "id": 153, "lastReportedValue": 99, "lastSetValue": 99, "size": 2, "value": 99 } ], "pollingTimeSec": 0, "zwaveCompany": "Fibargroup", "zwaveInfo": "3,7,14", "zwaveVersion": "7.0", "RFProtectionState": 0, "RFProtectionSupport": 0, "categories": [ "remotes" ], "centralSceneSupport": [ { "keyAttributes": [ "Pressed", "Released", "HeldDown", "Pressed2", "Pressed3" ], "keyId": 1 }, { "keyAttributes": [ "Pressed", "Released", "HeldDown", "Pressed2", "Pressed3" ], "keyId": 2 } ], "configured": true, "dead": false, "deadReason": "", "deviceControlType": 1, "deviceIcon": 216, "deviceRole": "Other", "endPointId": 0, "firmwareUpdate": { "info": "", "progress": 0, "status": "UpToDate", "updateVersion": "7.0" }, "icon": { }, "indicatorSupportedProperties": [ ], "indicatorValue": [ { "id": 0, "properties": { "0": 0 } } ], "localProtectionState": 0, "localProtectionSupport": 7, "log": "", "logTemp": "", "manufacturer": "", "markAsDead": true, "model": "", "nodeId": 63, "parametersTemplate": "872", "productInfo": "1,15,35,1,16,0,7,0", "protectionExclusiveControl": 0, "protectionExclusiveControlSupport": false, "protectionState": 0, "protectionTimeout": 0, "protectionTimeoutSupport": false, "ringBottomColor": "white", "ringBrightness": 100, "ringLightMode": "off", "ringUpperColor": "white", "saveLogs": true, "serialNumber": "h'00000000000031cd", "supportedDeviceRoles": [ "Other" ], "updateVersion": "", "useTemplate": true, "userDescription": "", "walliOperatingMode": "venetianBlindsController" }, "actions": { "abortUpdate": 1, "reconfigure": 0, "retryUpdate": 1, "setIndicatorValue": 1, "setRingsLightMode": 0, "startUpdate": 1, "updateFirmware": 1 }, "created": 1683728519, "modified": 1684763491, "sortOrder": 271 } je ne vois rien qui puisse être utilisé sous la forme de condition dans du GEA ou même du LUA mais comme je l'ai dit, je n'ai pas forcément toutes les compétences
Lazer Posté(e) le 26 mai 2023 Signaler Posté(e) le 26 mai 2023 Il y a 14 heures, jluc2808 a dit : pour le changement de couleur j'ai oublié de mentionné que j'ai aussi fait l'essai avec un changement directement sur les paramètres, sauf si je me suis trompé dans la syntaxe , j'ai systématiquement un message d'erreur GEA.add({"Value", 84, true},-1,"",{"Parameter", 462, 150, 3}) Ce module 462, c'est un parent ou un enfant ? Est-ce que tu peux essayer avec l'ID du module parent. Ensuite, tu dis que tu as systématiquement un message d'erreur, mais si tu ne dis pas lequel, tu avoueras que c'est compliqué de t'aider Profites en pour activer toutes les traces de debug. Dans la fonction config de ton fichier de config, tu ajoutes les 2 instructions suivantes : GEA.debug = true GEA.lldebug = false Et avant de lancer le test, isole la règle qui fait la modification de paramètre, car le log sera très verbeux, il ne faut conserver que l'essentiel.
jojo Posté(e) le 26 mai 2023 Signaler Posté(e) le 26 mai 2023 Le 25/05/2023 à 21:02, Lazer a dit : Modifier les propriétés d'un module n'agit que sur sa représentation dans la DB, mais ne déclenche aucune action sur le module Z-Wave proprement dit. ok, mais alors à quoi sert cette action ? Aurais-tu un exemple ?
jojo Posté(e) le 26 mai 2023 Signaler Posté(e) le 26 mai 2023 Il y a 22 heures, jluc2808 a dit : { "id": 334, "name": "334 - inter studio ch haut parent", question : pourquoi mets-tu l'id du module dans son nom ?
Lazer Posté(e) le 26 mai 2023 Signaler Posté(e) le 26 mai 2023 il y a 11 minutes, jojo a dit : ok, mais alors à quoi sert cette action ? Aurais-tu un exemple ? Si tu ne sais pas, c'est que tu n'en as pas besoin C'est ce qu'on faisait avec les fake devices par exemple, mais c'est du passé, depuis qu'on a les QuickApps, on peut coder proprement.
jojo Posté(e) le 26 mai 2023 Signaler Posté(e) le 26 mai 2023 ok, donc utile pour modifier les propriétés d'un QA, , mais ne fonctionne pas pour modifier celles d'un module physique. Quand je repense aux cas où je l'utilisait, c'était des QA, donc normal que je ne me dois pas dit : "c'est quoi ce beens, pourquoi ça ne fonctionne pas comme je veux ?" en fait c'est très logique, merci d'avoir réveillé mon neurone
jluc2808 Posté(e) le 26 mai 2023 Signaler Posté(e) le 26 mai 2023 Il y a 1 heure, jojo a dit : question : pourquoi mets-tu l'id du module dans son nom ? ça c'est juste parce que quand je récupère le nom dans HA (via le plugin) j'ai cette info en direct.
jluc2808 Posté(e) le 26 mai 2023 Signaler Posté(e) le 26 mai 2023 Il y a 10 heures, Lazer a dit : Ce module 462, c'est un parent ou un enfant ? Est-ce que tu peux essayer avec l'ID du module parent. Ensuite, tu dis que tu as systématiquement un message d'erreur, mais si tu ne dis pas lequel, tu avoueras que c'est compliqué de t'aider Profites en pour activer toutes les traces de debug. Dans la fonction config de ton fichier de config, tu ajoutes les 2 instructions suivantes : GEA.debug = true GEA.lldebug = false Et avant de lancer le test, isole la règle qui fait la modification de paramètre, car le log sera très verbeux, il ne faut conserver que l'essentiel. oui le module 462 est un parent, pas un enfant le message d'erreur est : Erreur, vérifier : ["Parameter",[462,150,3]] j'ai mis le debug que tu m'as conseillé résultat: Ajout immédiat #1 : ["Property",[84,"state",true]] => ["Parameter",[462,150,3]] [27.05.2023] [01:05:35] [DEBUG] [QA_GEA_592]: @0s [Validation*] #1 : ["Property",[84,"state",true]] => ["Parameter",[462,150,3]] [27.05.2023] [01:05:35] [DEBUG] [QA_GEA_592]: [Démarrage] #1 : ["Property",[84,"state",true]] => ["Parameter",[462,150,3]] [27.05.2023] [01:05:35] [DEBUG] [QA_GEA_592]: [action] ["Parameter",[462,150,3]] [27.05.2023] [01:05:35] [ERROR] [QA_GEA_592]: [27.05.2023] [01:05:35] [ERROR] [QA_GEA_592]: Erreur, vérifier : ["Parameter",[462,150,3]]
Lazer Posté(e) le 27 mai 2023 Signaler Posté(e) le 27 mai 2023 OK merci, j'analyserai ça dès que possible. En attendant tu as pu faire le test du Call avec 1 seul ID ? Il y a 20 heures, jojo a dit : ok, donc utile pour modifier les propriétés d'un QA, , mais ne fonctionne pas pour modifier celles d'un module physique. Quand je repense aux cas où je l'utilisait, c'était des QA, donc normal que je ne me dois pas dit : "c'est quoi ce beens, pourquoi ça ne fonctionne pas comme je veux ?" en fait c'est très logique, merci d'avoir réveillé mon neurone En fait, QA ou module physique, c'est pareil. Si tu modifies la propriété "value" d'un QA, la fonction setValue (ou turnOn, ou turnOff, etc) ne sera pas appelée, et le QA n'aura donc pas agit sur l'appareil qu'il est censé commencer (généralement un appareil sur IP) La bonne pratique pour agir sur les modules (qu'ils soient physique ou virtuel), c'est toujours de passer par les actions (listées comme telles dans le JSON du module) car cela va exécuter le code situé dans la fonction correspondante. A noter, comme je l'ai déjà dit de nombreuses fois sur le forum, toutes les fonctions membre de la classe QuickApp sont automatiquement exportées, dont on peut considérer que ce sont des actions, bien qu'elles ne soient pas nécessairement listées dans les actions du JSON. En revanche, il y a certaines propriétés qui sont juste là pour faire joli... par exemple les champs manufacturer, model, etc... si ça t'amuses, tu peux les modifier en direct, pour le coup ça ne passe pas par une fonction. Mais tout cela n'est pas lié à GEA, c'est lié au fonctionnement général de la HC3.
jluc2808 Posté(e) le 27 mai 2023 Signaler Posté(e) le 27 mai 2023 retour test avec 1 seul ID dans le calll rappel le code généré dans le scénario en mode block puis transformé en LUA est : hub.call({[1] = 452, [2] = 457, [3] = 460, [4] = 463, }, 'setRingsLightMode', "on") même après exécution du scénario précédent le json du module id 452 donne "ringLightMode": "off", donc comme je suis à distance je ne peux pas contrôler si l'anneau s'est allumé ou non ? j'ai quand même fait l’exécution du code GEA GEA.add({"Property", 84, "state" , true},-1, "", {"Call", 452, "setRingsLightMode", "on"}) GEA.add({"Property", 84, "state" , false},-1, "", {"Call", 452, "setRingsLightMode", "off"}) le report console est OK [28.05.2023] [00:13:47] [TRACE] [QA_GEA_592]: ---------------------------------------------------------------------------------------------------- [28.05.2023] [00:13:47] [TRACE] [QA_GEA_592]: Démarrage par événement de GEA 7.36 : mode device #84 FGD212 couloir étage (couloir étage) state [28.05.2023] [00:13:47] [TRACE] [QA_GEA_592]: ---------------------------------------------------------------------------------------------------- [28.05.2023] [00:13:47] [DEBUG] [QA_GEA_592]: [Démarrage] #7 : ["Property",[84,"state",false]] => ["Call",[452,"setRingsLightMode","off"]] [28.05.2023] [00:13:47] [DEBUG] [QA_GEA_592]: [action] ["Call",[452,"setRingsLightMode","off"]] [28.05.2023] [00:14:20] [TRACE] [QA_GEA_592]: ---------------------------------------------------------------------------------------------------- [28.05.2023] [00:14:20] [TRACE] [QA_GEA_592]: Démarrage par événement de GEA 7.36 : mode device #84 FGD212 couloir étage (couloir étage) state [28.05.2023] [00:14:20] [TRACE] [QA_GEA_592]: ---------------------------------------------------------------------------------------------------- [28.05.2023] [00:14:20] [DEBUG] [QA_GEA_592]: [Démarrage] #6 : ["Property",[84,"state",true]] => ["Call",[452,"setRingsLightMode","on"]] [28.05.2023] [00:14:20] [DEBUG] [QA_GEA_592]: [action] ["Call",[452,"setRingsLightMode","on"]] [28.05.2023] [00:15:00] [TRACE] [QA_GEA_592]: ---------------------------------------------------------------------------------------------------- [28.05.2023] [00:15:00] [TRACE] [QA_GEA_592]: Démarrage par événement de GEA 7.36 : mode device #84 FGD212 couloir étage (couloir étage) state [28.05.2023] [00:15:00] [TRACE] [QA_GEA_592]: ---------------------------------------------------------------------------------------------------- [28.05.2023] [00:15:00] [DEBUG] [QA_GEA_592]: [Démarrage] #7 : ["Property",[84,"state",false]] => ["Call",[452,"setRingsLightMode","off"]] [28.05.2023] [00:15:00] [DEBUG] [QA_GEA_592]: [action] ["Call",[452,"setRingsLightMode","off"]] maintenant je verrais quand je serais sur place pour dire si l'anneau est allumé et éteint , parce comme je l'ai mentionné au dessus je ne vois rien avec le json du module 452 un autre point qui m'interpêle, comme tu l'as expliqué (@Lazer) plus avant, les actions sont listées dan le json avec derrière chaque action possible le nombre d'argument de l'action et pour setRingsLightMode il y a 0 , cela veut dire pas d'argument ? actions": { "abortUpdate": 1, "reconfigure": 0, "retryUpdate": 1, "setIndicatorValue": 1, "setRingsLightMode": 0, "startUpdate": 1, "updateFirmware": 1
Lazer Posté(e) le 28 mai 2023 Signaler Posté(e) le 28 mai 2023 Merci pour ces tests. Mais du coup, j'ai un gros doute là, tu as déjà réussi à modifier la couleur de l'anneau ? Que ça soit en mode bloc, en modifiant le paramètre Z-Wave directement, ou par une autre méthode ? Parce que là j'ai l'impression que tu passes du temps sur GEA alors que si ça se trouve, le problème est ailleurs, au niveau du module... déjà comme tu le soulignes doublement, le nombre d'argument à 0 pour l'action setRingsLightMode, ainsi que la propriété ringLightMode qui reste toujours sur off, ça ne semble pas normal. Je te l'avais dit plus haut, il faut comprendre le fonctionnement de ton module, en LUA s'il le faut, avant de s'attaquer à GEA. Je le rappelle, GEA est juste un "Gestionnaire d'événements automatiques", un moteur de scénario, il ne fait rien de plus que de s'appuyer sur les mécanismes mis à disposition par Fibaro sur la HC3.
jluc2808 Posté(e) le 28 mai 2023 Signaler Posté(e) le 28 mai 2023 Pour répondre exactement a tes interrogations légitimes : - oui j'ai déjà mis la couleur et l'allumage sur cet anneau et tous ceux du groupe via une scène block - en mode bloc transformée en LUA, j'ai ce code qui fonctionne et qui éclaire l'anneau en vert lorsque la lumière est allumée du côté condition: { conditions = { { id = 84, isTrigger = true, operator = "==", property = "state", type = "device", value = true } }, operator = "all" } du côté action : hub.call({[1] = 452, [2] = 457, [3] = 460, [4] = 463, }, 'setRingsLightMode', "on") hub.call({[1] = 452, [2] = 457, [3] = 460, [4] = 463, }, 'setProperty', "ringUpperColor","green") hub.call({[1] = 452, [2] = 457, [3] = 460, [4] = 463, }, 'setProperty', "ringBottomColor","green") et ce code LUA (transformation mode block) qui fonctionne lorsque la lumière est éteinte condition: { conditions = { { id = 84, isTrigger = true, operator = "==", property = "state", type = "device", value = false } }, operator = "all" } action: hub.call({[1] = 452, [2] = 457, [3] = 460, [4] = 463, }, 'setRingsLightMode', "on") hub.call({[1] = 452, [2] = 457, [3] = 460, [4] = 463, }, 'setProperty', "ringUpperColor","white") hub.call({[1] = 452, [2] = 457, [3] = 460, [4] = 463, }, 'setProperty', "ringBottomColor","white")
jojo Posté(e) le 28 mai 2023 Signaler Posté(e) le 28 mai 2023 Le 27/05/2023 à 20:33, Lazer a dit : En fait, QA ou module physique, c'est pareil. Oui, merci du rappel. Mais donc je reste toujours avec ma question : pourquoi l'action Property, si elle ne sert à rien (sauf à modifier les propriétés "pour faire joli") Je suis bien d'accord que cela n'a rien à voir avec GEA, mais c'est juste pour mourir moins bête ...
Messages recommandés