base de connaissances Gestion des appareils enfants

[jjacques68]

ah ben du coup ça marche nickel !

 

merci @Krikroff @jang

[jang]

à 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

[jjacques68]

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.

[Krikroff]

[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

[jjacques68]

oula... vous partez dans une autre galaxie là  bon ben je vous laisse...

 

merci encore...

[jang]

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"

 

[mprinfo]

@jjacques68 je pense qu'il est l'heure de l'apéritif pour nous.


Envoyé de mon BLA-L29 en utilisant Tapatalk

[Krikroff]

Pour moi aussi


Envoyé de mon iPhone en utilisant Tapatalk

[jjacques68]

 allé... cheers everybody ! 

[Lazer]

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é le 17 mai 2020 par Lazer

[mprinfo]

Demain promis j'arrive aujourd'hui c'est repos forcé

Envoyé de mon BLA-L29 en utilisant Tapatalk

[jjacques68]

nan mais c'est bon c'est réglé, il manquait des infos c'est tout...

[Lazer]

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)

[mprinfo]

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

[Lazer]

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.

[jjacques68]

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 

[Lazer]

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

 

 

[Lazer]

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

[Lazer]

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 

100% d'accord

[jjacques68]

il y a 10 minutes, mprinfo a dit :

dans l'est on réfléchis à haute voix

tu rigoles mais au boulo je parle tout seul... ça m'aide énormément !

par contre ça rend fou mes collègues...

[jjacques68]

@Lazer tu es entrain de lire tout les post ?

 

ok je comprends pourquoi tu râles  

Modifié le 17 mai 2020 par jjacques68

[jang]

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

[Lazer]

OK thank you, your're right.

 

I personally don't use setTimeout() in child's constructor, I was just answering jjacques68's question.

 

My childs are updated from the main parent device.

[jjacques68]

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 ?

[jang]

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() )