Krikroff

Tu as vraiment beaucoup de besoins ? Un device WekeOnLan par Périphérique c'est plus simple à gérer que de coder non ?

@jjacques68, c'est quoi l'idée: utiliser une instance unique du plugin pour tout tes besoins de WakeOnLAn ?

@jjacques68, tu as vérifié si il n'y avait un plugin WanOnLan au fait ?

Bof bof ça va juste lisser les écarts si tu veux mon avis, d’ailleurs il n’est pas précisé si c’est le prix public recommandé ou le prix d’achat HT (non négocié/ remisé) qui bouge en vrai. En complément de cette annonce il y a aussi le nouveau positionnement tarifaire des HCLite et HC2 suite à la mise en avant de la nouvelle box premium [emoji51] Envoyé de mon iPhone en utilisant Tapatalk

Soit en fait le prix auquel tout le monde l’achète depuis des mois.. Tres bien pour le Walli mais que je trouve encore beaucoup trop onéreux. Le wallplug non mais, qui ici a acheté récemment un WP à 64,90€ ?

Je n’ai pas encore sauté le pas (ça me démange depuis des mois) et j’avoue être parfaitement ignare dans le domaine mais un ingénieur méthode au taff ne jure que par prusa ... bien l’impression que les retours sont unanimes !!! Envoyé de mon iPhone en utilisant Tapatalk

Bienvenue sur le forum Envoyé de mon iPhone en utilisant Tapatalk

Bonjour, il faudrait essayer de procéder à un redémarrage pour voir... Envoyé de mon iPhone en utilisant Tapatalk

Bienvenue sur le forum,et merci pour la contribution

Utiliser une variable d'un Quick App comme trigger d'une scène en effet ce n'est pas possible, je trouve que c'est cohérent. En revanche avec un peu d'huile de coude il est parfaitement possible d’accéder et d'utiliser une variable d'un QA depuis une scène, voici comment: -- Description: retrieve a quick app variable by name -- arg: [id] (integer): > QA device ID -- arg: [name] (string): QA variable name -- arg: [cs] (boolean): Search is case sensitive or not -- Return: The QA variable value or nil do function getQuickAppVariable(id, name, cs) assert(tonumber(id),"getQuickAppVariable(id, name), arg [id] must be a number") assert(type(name)=="string","getQuickAppVariable(id, name), arg [name] must be a string") local v, r = api.get(string.format("/devices/%s", id)).properties.quickAppVariables, nil if (not cs) then name = name:lower() end for i=1, #v do local search = v[i].name if (not cs) then search = v[i].name:lower() end if (search == name) then r = v[i].value break end end return r end end et pour l'utiliser local value = getQuickAppVariable(941, "IP_Address") print(value)

Même sans antenne la « performance » est bien meilleure que sur HC2 / HCLITE , les retours sont unanimes [emoji108] Envoyé de mon iPhone en utilisant Tapatalk

Ce ne sont pas des informations accessibles ni partagées par Fibaro. Il faudra procéder par élimination suivant nos retours d’expérience pour en déduire le fonctionnement exact j'en ai peur...

L'idée ici est partager nos retours d' expérience sur l'utilisation des variables dans les Quick App. Nous connaissons tous pour la plupart l'existence des variables globales mais le HC3 dans les Quick App apporte une nouvelle notion de variable au niveau du QA. Cela va considérablement simplifier la vie du développeur et du l'utilisateur au quotidien. L'utilisation est très simple et repose sur 2 méthodes: La création ou la mise à jour d'une variable existante : self:setVariable("NOM_DE_LA_VARIABLE", "VALEUR_DE_LA_VARIABLE") > le set se charge de créer la variable si elle n'existe pas, bien joué Fibaro La lecture de la valeur d'une variable : self:getVariable("NOM_DE_LA_VARIABLE") Avouons le c'est difficile de faire plus simple Les variables ainsi ajoutées sont visibles depuis l'onglet "Variables" au niveau du périphérique, comme ceci: Ou bien encore en interrogeant l' API via le SWAGGER intégré au Home Center ...

L'idée de ce Quick App est de représenter sur la forme d'un module du type "binary sensor" l'état du détecteur de mouvement intégré à l' Intercom Fibaro C'est ultra basique, mais cela illustre de manière extrêmement simple comment un Quick App va permettre de donner de la visibilité à des valeurs, données, états etc. masqués et ceci sans grand effort, pour une fois ! Les méthodes du Quick App sont appelées via un fibaro.call depuis des scènes: https://www.domotique-fibaro.fr/topic/14116-utiliser-le-détecteur-de-proximité-de-lintercom-fibaro-dans-une-scène/ https://www.domotique-fibaro.fr/topic/14115-détection-du-tamper-de-lintercom-fibaro-dans-une-scène/ Le code à reporter dans l'éditeur LUA du QA est le suivant: -- Quick APP -- Name: QA FGIC-00X - Motion sensor -- Description: Fibaro Intercom motion sensor -- Type: Binary sensor function QuickApp:onInit() self:debug("onInit") end function QuickApp:breached(value) self:updateProperty("value", toboolean(value)) self:updateProperty("lastBreached", os.time()) end function QuickApp:tamper(tripped) if toboolean(tripped) then self:updateProperty("logTemp", "tamper tripped") end end function QuickApp:dead(value, reason) self:updateProperty("dead", toboolean(value)) self:updateProperty("deadReason", tostring(reason or "")) end do function toboolean(value) if (type(value) == "number") then return (value~=0) end return (not not value) end end Rien de sorcier Ensuite il faut extrapoler: Les méthodes pourraient également être appelées depuis une box externe au HC via des requêtes Les états pourraient être modifiés directement par le QA lui même à l'aide d'un code qui irait interroger des systèmes diverses (API d'un service en ligne, API d'un objet connecté etc.) Bref le champ des possibles est relativement vaste. Tout ceci est réalisé un petit peu à l'aveugle mais j'essaierai dans la mesure du possible de vous proposer des choses de plus en plus complexes

Hello @TonyC, du coup je pense que tu vbas trouver ton bonheur ici https://www.domotique-fibaro.fr/forum/117-hc3/ Si tu peux me faire un retour sur le fonctionnement stp ?

DECLARATIONS (Conditions/Triggers) { operator = "any", conditions = { -- firstRelayIsOpen { id = 000, isTrigger = true, operator = "anyValue", property = "firstRelayIsOpen", type = "device" }, -- secondRelayIsOpen { id = 000, isTrigger = true, operator = "anyValue", property = "secondRelayIsOpen", type = "device" } } } ACTIONS -- firstRelayIsOpen -- secondRelayIsOpen local trigger = sourceTrigger print("property:"..trigger.property) print("id:"..trigger.id) print("type:"..trigger.type) print("value:"..tostring(trigger.value))

DECLARATIONS (Conditions/Triggers) { operator = "any", conditions = { -- input1 { id = 000, isTrigger = true, operator = "anyValue", property = "input1", type = "device" }, -- input2 { id = 000, isTrigger = true, operator = "anyValue", property = "input2", type = "device" } } } ACTIONS -- input1 -- input2 local trigger = sourceTrigger print("property:"..trigger.property) print("id:"..trigger.id) print("type:"..trigger.type) print("value:"..tostring(trigger.value))

DECLARATIONS (Conditions/Triggers) { operator = "any", conditions = { -- buttonOneIsPressed { id = 000, isTrigger = true, operator = "anyValue", property = "buttonOneIsPressed", type = "device" }, -- buttonTwoIsPressed { id = 000, isTrigger = true, operator = "anyValue", property = "buttonTwoIsPressed", type = "device" }, -- buttonThreeIsPressed { id = 000, isTrigger = true, operator = "anyValue", property = "buttonThreeIsPressed", type = "device" } } } ACTIONS -- buttonOneIsPressed -- buttonTwoIsPressed -- buttonThreeIsPressed local trigger = sourceTrigger print("property:"..trigger.property) print("id:"..trigger.id) print("type:"..trigger.type) print("value:"..tostring(trigger.value))

Le QA est disponible dans la partie dédiée du forum en suivant ce lien:

DECLARATIONS (Conditions/Triggers) { operator = "any", conditions = { -- proxymityStateChanged { id = 000, isTrigger = true, operator = "anyValue", property = "proxymityStateChanged", type = "device" } } } ACTIONS local trigger = sourceTrigger print("property:"..trigger.property) print("id:"..trigger.id) print("type:"..trigger.type) print("value:"..tostring(trigger.value)) Et pourquoi pas l'utilisation d'un quick app de type binary sensor en complément fibaro.call(0000,"breached", trigger.value)

DECLARATIONS (Conditions/Triggers) { operator = "any", conditions = { -- tamper { id = 000, isTrigger = true, operator = "anyValue", property = "tamper", type = "device" } } } ACTIONS local trigger = sourceTrigger print("property:"..trigger.property) print("id:"..trigger.id) print("type:"..trigger.type) print("value:"..tostring(trigger.value))

Pour le Garden j'ai remonté le problème sur le serviceDesk Fibaro pour investigation...

Peut être des modification des variable via l' API alors ?

Oui je viens de tester et je confirme ce que tu observes, j'essaie de comprendre mais cela ne me semble pas logique en effet ... Ou alors il faut que je me prenne une vodka peut-être

Bon l'essentiel c'est que cela fonctionne bien pour toi... Juste une question: les 2 QA concernés tu les avais créer avant la dernière mise à jour ou récemment ? Peut être des modification des variable via l' API ?