Aller au contenu

Messages recommandés

Posté(e) (modifié)
Il y a 2 heures, Lazer a dit :

@henri-allauch d'ailleurs je ne vois pas bien comment tu voudrait intercepter le boot de la box dans le refreshState depuis un QA, puisque le QA a nécessairement démarré après le boot de la box.

@Lazer

Oui tu as raison et voit bien dans le log le démarrage  du QA .

Simplement comme le démarrage est bien détecté par par le trigger dans une scène, je pensais ( à tord ) qu'il y avait un évènement dans refreshStates

Il y en a pas.  Ta méthode de détection, ou le post d'une fake events dans  refreshStates par @jang   c'est OK

Merci à vous 2 et à @jjacques68

Et pour le moment plus de scène j'ai un QA de contrôle et d'action basé sur le temps ( un espèce de AT ... ) 

Et un autre QA basé sur les évènements captés dans refreshStates.

Les deux traitent les actions simples ou délègueront à des QA spécialisés. 

Pourquoi pas GEA ? GEA et ( Autres ) c'est un peut une RollsRyce 

C'est plaisir de faire et de comprendre ( à mon échèle ) , en m'appuyant sur vos travaux. Et en utilisant aussi des QA comme DOMOCHARTS NETATMO NETWORKMonitor ...

Ce n'est qu'un début .....

Modifié par henri-allauch
Posté(e)
il y a 6 minutes, henri-allauch a dit :

C'est plaisir de faire et de comprendre ( à mon échèle ) , en m'appuyant sur vos travaux.

100% d'accord avec toi :) 

 

Perso j'ai encore fait un QA supplémentaire uniquement pour les actions devant être déclenchées à des heures bien précises.

J'aurai pu le mettre dans le refreshState, vu qu'il boucle toutes les 50 ms.

Contrôler l'heure, et déclencher les actions spécifiques.

Mais les "heures" de déclenchement sont stockées dans des variables de QA divers (afin de pouvoir les paramétrer souhait).

Et je récupère le contenu de ces variables QA via la méthode partagée par @Lazer (ou @jang ou @Krikroff je sais plus :)

J'ai donc préféré le séparer du resfreshState pour le soulager un peu...

 

image.png.ff956b7c767aa34ddfcbf823057f9640.png

 

 

Posté(e) (modifié)
il y a 10 minutes, jjacques68 a dit :

refreshState, vu qu'il boucle toutes les 50 ms.

Pour le moment suis à 1 seconde ( mais 2 devices de test ) j'ai donc de la marge 

Modifié par henri-allauch
Posté(e)

:) j'ai mis 50 ms car c'est lui qui m'allume les lumières avec les PIR.

Il permet aussi de rafraîchir l'IHM que je me suis fait.

Donc pas moyen d'attendre plus longtemps :7:

Posté(e) (modifié)
il y a 16 minutes, jjacques68 a dit :

Mais les "heures" de déclenchement sont stockées dans des variables de QA

Je me suis inspiré de ta méthode et @Lazer a partagé sa  fonction GetVariablesQA

 

Modifié par henri-allauch
  • Like 1
Posté(e)

Perso je suis à 100ms dans GEA pour refreshStates (et c'est paramétrable par l'utilisateur), mais je ne vois pas de raison de mettre plus ou moins.

50 ou 100 ms, du point de vue de l'utilisateur, c'est la même chose : instantané.

En fait, le plus gros délai, sera comme toujours le capteur PIR lui-même.

Plus la latence Z-Wave qui n'est pas nulle.

 

il y a 51 minutes, jjacques68 a dit :

Mais les "heures" de déclenchement sont stockées dans des variables de QA divers (afin de pouvoir les paramétrer souhait).

A ce sujet, as-tu regardé le QuckApp GEA Alarm ?

Il est indépendant de GEA, et permet de régler autant d'heures qu'on le souhaite, directement depuis une interface graphique (les boutons du QA), avec planning par heure/minutes et jours de la semaine.

On peut aussi régler les heures "programmatiquement", donc mon intention à terme, c'est que GEA pourra régler l'heure, s'auto-déclencher une fois le moment venu, tout en laissant la possibilité à l'utilisateur de reprendre la main et de régler manuellement l'heure désirée.

Les heures/jours sont stockées dans des variables du QA lui-même (pas de variables globales)

 

Exemple de scénario :

- GEA calcule tout seul l'heure de mise en route du chauffe-eau chaque nuit, en fonction de la température afin d'économiser et de ne pas chauffer trop d'eau inutilement.

- Ponctuellement, je sais que le lendemain j'aurai besoin d'un maximum d'eau chaude (invités à la maison par exemple), alors avant de me coucher j'avance moi-même l'heure)

 

Évidemment le même genre de scénario est applicable à l'heure du réveil-matin, ou à tout autre cas de figure.

  • Like 1
Posté(e)
37 minutes ago, jjacques68 said:

:) I took 50 ms because it is he who turns on the lights with the PIRs.

It also allows you to refresh the GUI that I made for myself.

So no way to wait any longer : 7:

 

If you use request ("http://127.0.0.1:11111/api/refreshStates?last=" ... 

you can poll with 0 delay.

 

With refreshStates the trick is to efficiently map incoming refresh event to what what function/rule you want to call.

Posté(e)
il y a 3 minutes, Lazer a dit :

En fait, le plus gros délai, sera comme toujours le capteur PIR lui-même.

Plus la latence Z-Wave qui n'est pas nulle.

tout à fait...

ou peut-être une manière de coder pas très clean aussi :lol:

 

il y a 3 minutes, Lazer a dit :

A ce sujet, as-tu regardé le QuckApp GEA Alarm ?

non pas regardé,

Ta description donne envie

je vais jeter un oeil :) 

Posté(e) (modifié)
il y a 5 minutes, jang a dit :

 

 If you use request ("http://127.0.0.1:11111/api/refreshStates?last=" ... 

yes I use it.

0 delay !!!

the box will melt !!

Modifié par jjacques68
Posté(e)
il y a 31 minutes, jjacques68 a dit :

yes I use it.

0 delay !!!

the box will melt !!

Do we know that? I believe that in a normally loaded HC3 there are enough events to even it out (processing events/second). I.e you poll often and get few events each time or you poll less often and get many. In a light environment the request will hang waiting for new events taking no CPU.

  • Thanks 1
Posté(e)
il y a 4 minutes, jang a dit :

the request will hang waiting for new events taking no CPU.

ah ok ! 

I understand, so I set 0 delay, I will see if something change...

thanks !!

Posté(e) (modifié)

On en apprend tout le temps : c'est la bible des HC2 HC3 ce forum

 

D'après vous serait til possible de faire dans le style :

self:warning( "test" )

 

un self:XXX(args) ou XXX serait une fonction existante et nommée dans une variable

 

Modifié par henri-allauch
Posté(e)

Oui c'est pas clair ( dans ma tête non plus )

 

Dans ce tableau  j'indique un ID de QA et la fonction à éxecuter et ses arguments  ( issu d'un de tes exemples ) c'est OK

 

{property="property", propertyName="*", deviceID=Id_Bouton_TEST_1,  value=false, id=self.QA_MailTo,  func="MyMail" , args="Id_Bouton_TEST_1 OFF"},

je cherche une solution pour y inscrire  une fonction qui sera appelé lors de l'analyse de cet element de table par exemple

{property="property", propertyName="*", deviceID=Id_Bouton_TEST_1,  value=false, .........  func= self:fonction("TEST" },

 

je sais pas si c'est plus clair 

Posté(e)

OK donc dans ce genre

function QuickApp:H()
 
    self.Lesactions = {
        {num = 1, Action = function(self,d) self:warning("TEST 1")  end},
        {num = 2, Action = function(self,d) self:error("TEST 2")  end},
        {num = 3, Action = function(self,d) self:trace("TEST 3")  end},
    } 

    for _, myA in ipairs(self.Lesactions) do  
       self.Lesactions[myA.num].Action(self)
    end  
end

 

Posté(e) (modifié)
Le 21/03/2021 à 18:16, jjacques68 a dit :

I understand, so I set 0 delay, I will see if something change...

@jjacques68 Tu as essayé 0 ?

 

Moi Oui  de suite  dans la log j'ai vu passé des error refreshStates end of file 

Puis ça a figé avec de demandes de rafraichir l'écran ou de vider le cache

plusieurs reboot, ca parait ok puis dès que je vais sur la page de log -> idem

reboot et on bloque sur la led de gauche clignotante

galère pour faire booter en mode récupération je le laisse réparer et charger ma sauvegarde de 14h47 -> idem

re galère pour démarer en récupération

je repart sur la config Usine ( il me met direct en 4.070 mais vide )

je restaure backup de 14h47 ca semble OK j'ai perdu quelques lignes écrites cet apm mais pas grave

 

je ne sais pas s'il y avait un problème latent mais ? 

 

 

Modifié par henri-allauch
Posté(e)

je ne dis pas être sur que c'est ça, mais les  error refreshStates end of file ça c'est sur.

Après c'est peut être aussi mon code ...

Mais une bonne sauvegarde juste avant ce sera plus prudent.

Posté(e)

Y a t'il une solution ( simple ) pour récupérer le retour d'une fonction de QA

fibaro.call(ID_QA, "fonction", "variable")

j'ai lu par VG, vous en utilisez d'autre ?

Posté(e)

hm, je m'étais posé la même question à l'époque.

A part les VG, y a pas de remèdes miracles.

 

sinon en détournant l'utilisation des fichiers dans les QA...

J'avais fait un truc là-dessus

Mais c'est très lourd, je ne l'utilise pas.

 

Vaut mieux copier/coller la fonction dans le QA

Posté(e) (modifié)
Il y a 4 heures, henri-allauch a dit :

Is there a (simple) solution to get the return of a QA function

 

No, and it's tricky also for Fibaro as it is between 2 different processes (each QA is its own process)

This is one way to do it

https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/?do=findComment&comment=207479

 

Client (unfortunately needs most code, but can be put in a "Library file")

do
  local var,n = "RPC_"..plugin.mainDeviceId,0
  api.post("/globalVariables",{name=var,value=""})
  function rpc(id,fun,args,timeout)
    fibaro.setGlobalVariable(var,"")
    n = n + 1
    fibaro.call(id,"RPC_CALL",var,n,fun,args)
    timeout = os.time()+(timeout or 3)
    while os.time() < timeout do
       local r = fibaro.getGlobalVariable(var)
       if r~="" then 
          r = json.decode(r)
          if r[1] == n then
             if not r[2] then error(r[3],3) else return select(3,table.unpack(r)) end
          end
       end
    end
    error(string.format("RPC timeout %s:%d",fun,id),3)
  end
end

local function defineRemote(id, fun, timeout) _G[fun]=function(...) rpc(id, fun, {...}, timeout) end end

function QuickApp:test()
  n=100
  local t0 = os.clock()
  for i=1,n do
    foo(3,i)   -- Remote call to QA 58 and function foo with args 3,i 100 times and calculate average time
  end
  print(string.format("Call time: %.3fms",((os.clock()-t0)*1000)/n))
end

function QuickApp:onInit()
    self:debug("RPC")
    defineRemote(58,"foo") -- define remote function foo from QA 58
    sel:test()
end

The "server" (with deviceID 58) that exports 'foo' is much simpler. In fact, all global functions in QA 58 can be called from remote. 

function QuickApp:RPC_CALL(var,n,fun,args)
    local res = {n,pcall(_G[fun],table.unpack(args))}
    fibaro.setGlobalVariable(var,json.encode(res))
end

function foo(x,y) return x+y end -- Remote function

The time it takes for a call is ~11.7ms, which is quite ok.

[23.03.2021] [21:41:00] [DEBUG] [QUICKAPP57]: Call time: 11.757ms

 

Modifié par jang
  • Thanks 1
Posté(e) (modifié)

@jjacques68 oui j'avais lu ton post par les fichiers de QA

mais comme la méthode de @jang

cela reste un peu complexe pour le résultat que j'attendait

je vais dupliquer la fonction 

 

Modifié par henri-allauch
  • Like 1
×
×
  • Créer...