Aller au contenu

Gestion des appareils enfants


Krikroff

Messages recommandés

à l’instant, Krikroff a dit :

with the refresh state? Or by using what is behind it?

With my fibaroapiHC3.lua sdk I automatically crate a proxy on the HC3 for my QuickApp (running in ZeroBrane studio).

The proxy QuickApp sends all actions/ui events back to the code in ZBS. A procy looks like:

local function urlencode (str) 
  return str and string.gsub(str ,"([^% w])",function(c) return string.format("%%% 02X",string.byte(c))  end) 
end
local function POST2IDE(path,payload)
    url = "http://"..IP..path
    net.HTTPClient():request(url,{options={method='POST',data=json.encode(payload)}})
end
local IGNORE={updateView=true,setVariable=true,updateProperty=true} -- Rewrite!!!!
function QuickApp:actionHandler(action) 
      if IGNORE[action.actionName] then 
        return self:callAction(action.actionName, table.unpack(action.args))
      end
      POST2IDE("/fibaroapiHC3/action/"..self.id,action) 
end
function QuickApp:UIHandler(UIEvent) POST2IDE("/fibaroapiHC3/ui/"..self.id,UIEvent) end
function QuickApp:CREATECHILD(id) self.childDevices[id]=QuickAppChild({id=id}) end

function QuickApp:onInit()
 self:debug('Proxy Holidays',' deviceId:',self.id)
 IP = self:getVariable('PROXYIP')
 function QuickApp:initChildDevices() end
end

QuickApp:actionHandler / QuickApp:UIHandler

Lien vers le commentaire
Partager sur d’autres sites

il y a une heure, Krikroff a dit :

Le problème des ids c’est plus général comme sujet, le QA lui même change d’ID en cas de mise à jour

alors visiblement tant qu'on touche que au code, c'est ok.

L'ajout / modification de fonction est instantanément pris en compte. Sans changement d'ID des Child.

 

Faut juste pas vouloir ajouter de variables au Child. Dans ce cas faut le recréer.

Lien vers le commentaire
Partager sur d’autres sites

[mention]jang [/mention] C’est bien vu , mais j’utilise mon propre SDK ...

 

Je te confirme qu’il est possible de surcharger onAction et UIEvent... Car en fait les QA d’aujourd’hui sont les plugins d’avant

 

 

Envoyé de mon iPhone en utilisant Tapatalk

Lien vers le commentaire
Partager sur d’autres sites

il y a 8 minutes, jjacques68 a dit :

amazing

 

in the "__init", like that, it crashes

 


but with that, it's ok :


with 1 ms delay ...

0 fonctionne également. Vous revenez de __init().

 

__init appelle :onInit()

 

Mieux vaut mettre à jour les "child states" après "initChildDevices"

 

  • Like 1
Lien vers le commentaire
Partager sur d’autres sites

Putains les gars, vous faites les questions réponses tous seuls, enfin surtout JJacques, c'est impossible de suivre et encore moins de répondre là..... 15 messages en 1 heure, ça serait pas mieux de tester avant de poser la question ?

 

Comme on dit, tourner 7 fois sa langue dans sa bouche....

 

Modifié par Lazer
  • Like 1
Lien vers le commentaire
Partager sur d’autres sites

Il y a 2 heures, jjacques68 a dit :

un inconvénient quand même et pas un petit !! :

 

si un jour on fait une modification sur les Child, il faut supprimer l'ancien pour créer le nouveau avec les modifications !!

et du coup l'ID du Child change à chaque fois, un peu pénible si on l'utilise comme trigger ou autre...

  

à moins que j'ai loupé qqch ? 

Euh mais je comprend pas là ?
Pourquoi tu voudrais faire une mise à jour du Child, il n'y a aucune raison de le faire, et donc de changer son ID !

 

Le child utilise le code LUA du parent, et c'est ça qui est génial, tu modifies le code LUA de ton parent = 1 seule modification, et tes 200 devices enfants en profite. Cela simplifie tellement les mises à jours et évite des copiers/coller fastidieux de code.

 

Les seules choses que tu aies besoin de changer sur ton child device, c'est :

- son nom, modifiable par l'utilisateur dans le GUI

- ses variables => on retombe dans le bug que j'ai signalé, impossible de modifier ses variables via le GUI (pour l'instant j'espère)

Lien vers le commentaire
Partager sur d’autres sites

Putains les gars, vous faites les questions réponses tous seuls, enfin surtout JJacques, c'est impossible de suivre et encore moins de répondre là..... 15 messages en 1 heure, ça serait pas mieux de tester avant de poser la question ?
@lazer dans l'est on réfléchis à haute voix
Je rigole mais je suis comme@jjacques68

C'est vrai que c'est pas facile à suivre

Envoyé de mon BLA-L29 en utilisant Tapatalk

Lien vers le commentaire
Partager sur d’autres sites

Il y a 1 heure, Krikroff a dit :

[mention]Lazer [/mention] toujours pas certain de bien comprendre, tu veux gérer quoi avec les variables dans tes childs que tu ne peux pas gérer dans le parent ?

Dans le cas de mon IPX800, je crée un Child par entrée/sortie de l'IPX.

Il faut que pour chaque Child, je puisse préciser, par une variable, à quel E/S il est associé : entrée numériques D1 à D56, entrée analogique A1 à A4, sorties numériques R1....

 

Si tu as un IPX avec 56 entrées numériques maximum, je ne vais pas créer 56 Childs devices si je n'ai besoin de gérer que, admettons, 10 entrées dans la HC3.

Donc plutôt que de créer les 56 children, je laisse à l'utilisateur la possibilité de ne créer que les 10, et de modifier la variable de chacun de ces 10 modules, pour spécifier à quelle entrée numérique il est associé. C'est une propriété propre au Child, par au Parent.

Lien vers le commentaire
Partager sur d’autres sites

il y a 2 minutes, Lazer a dit :

Le child utilise le code LUA du parent, et c'est ça qui est génial, tu modifies le code LUA de ton parent = 1 seule modification, et tes 200 devices enfants en profite. Cela simplifie tellement les mises à jours et évite des copiers/coller fastidieux de code.

en effet, mais je l'ai compris après avoir écrit ma remarque :unsure:

Lien vers le commentaire
Partager sur d’autres sites

Il y a 1 heure, jjacques68 a dit :

EDIT : je précise que cette méthode est appelée dans le code "__init" du "Child"

Justement, tu es ultra limité dans le __init(), c'est précisé dans la doc :

 

WARNING: QuickApp.childDevices is not accessible in a child’s constructor, only in their methods.

 

 

=> Il faut que tu fasses un appel à setTimeout() pour exécuter une autre fonction qui aura les droits d'accéder à tous les objets

 

 

Lien vers le commentaire
Partager sur d’autres sites

il y a une heure, Krikroff a dit :

Pour ton problème de parent, je pense simplement qu'il n'est pas possible d'y accéder dans un init ( comportement qui me semblerai attendu ). Si c'est bien le cas, alors il y a un Hack possible avec un SetTimeout ;)

Voilà je confirme c'est ce que je disais au dessus :)

Lien vers le commentaire
Partager sur d’autres sites

il y a 47 minutes, Krikroff a dit :

Ex: 1 client HTTP mutualisé au niveau du parent est suffisant pour tous les enfants.

Le parent doit être l’orchestrateur du QA, c’est lui qui doit tout gérer, fournir... Enfin c’est ma vision des choses emoji4.png

100% d'accord :60:

Lien vers le commentaire
Partager sur d’autres sites

il y a 15 minutes, Lazer a dit :

Precisely, you are ultra limited in __init (), it is specified in the doc :

 

WARNING: QuickApp.childDevices is not accessible in a child's constructor, only in their methods.

 

 

=> You must make a call to setTimeout () to execute another function which will have the rights to access all objects

 

 

 

setTimeout is the wrong weapon.

 

child = self:createChildDevice(....) -- create new child, do minimal work here.

child:Ask_State() -- child is completely setup - update state

 

self:initChildDevices ({ [ "com.fibaro.binarySwitch" ] = IPX , }) -- create existing childs, , do minimal work here.

for _,child in pairs(self.childDevices) do child:Ask_State() end -- childs are completely setup, update states

Lien vers le commentaire
Partager sur d’autres sites

il y a 19 minutes, jang a dit :

child = self:createChildDevice(....) -- create new child, do minimal work here.

child:Ask_State() -- child is completely setup - update state

 

self:initChildDevices ({ [ "com.fibaro.binarySwitch" ] = IPX , }) -- create existing childs, , do minimal work here.

for _,child in pairs(self.childDevices) do child:Ask_State() end -- childs are completely setup, update states

i think I just understand it !

It's the parent which initialize the child, and not the child which initialize itself !

that's correct ?

Lien vers le commentaire
Partager sur d’autres sites

il y a 12 minutes, jjacques68 a dit :

i think I just understand it !

It's the parent which initialize the child, and not the child which initialize itself !

that's correct ?

 

Almost... the parent asks the child to create himself, by calling the child's constructor. A child does not have a parent (is not aware of the parent) before being fully initialised (__init and _onInit are finished). When the child is fully initialised the parent sets the 'parent' field of the child to the parent. (in createChildDevice() and initChildDevices() )

  • Like 1
Lien vers le commentaire
Partager sur d’autres sites

×
×
  • Créer...