UN petit coup de main SVP

[Lazer 8 486]

Dans le code source de GEA (fichier main, tout en bas), tu trouveras un exemple simple et fonctionnel

[henri-allauch 225]

Simple et fonctionnel mais très lié à GEA

Je n'arrive pas à le faire tourner en dehors

Je comprend le principe mais comment charger    
    triggers = {}

pour faire tourner la boucle loop  ?

 

J'essaye de faire tourner qq lignes de lua Hors GEA

 

Modifié 16 mars 2021 par henri-allauch

[Lazer 8 486]

oui la variable trigger c'est le mécanisme interne de GEA pour filtrer les événements qui se produisent, mais cette partie là tu ne la prends pas, c'est à toi de faire tes propres tests.

Le mieux pour commencer c'est de regarder le contenu de la réponse, un tableau avec un ou plusieurs événements, tu vas en découvrir énormément, c'est très bavard.

[jjacques68 602]

il y a une heure, Lazer a dit :

tu vas en découvrir énormément, c'est très bavard.

et comment, faut faire un sacré tri  

@henri-allauch Je te donnerais bien mon script, mais pareil... il était simple au début, maintenant ça se complique...

Modifié 16 mars 2021 par jjacques68

[henri-allauch 225]

On va faire l'inverse demain je vais essayer d'avancer un exemple simple et court

et si je coince je mettrais le lua pour avoir l'info qui me manquera

[henri-allauch 225]

Je n'ai pas pu faire  fonctionner un simple exemple lua refreshStates depuis le code GEA  mais j'ai vu que le principe

Donc je me suis rabatu sur l'exemple  de @jgab danshttps://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/?tab=comments#comment-201173

J'ai fait tourner un exemple et  compris le principe ( il dit qu'i la amélioré et de jeter un coup d'oeil dans  fibaroapiHC3.lua file how to poll for events ) 

Mais avant de mettre en pratique je sollicite votre avis :

Sur la HC2 j'ai pour chaque action à traiter sur évènement : une scène simple qui fait ce  dont besoin triggé par un device, une VG, ...

Pour la HC3 j'ai globalement le choix entre : 

   soit même principe ( solution confortable pour l'esprit mais pas au gout du jour ) 

   soit une scene à trigger multiple qui dispatche vers des QA pour traiter les actions 1 QA par type d'action par exemple

   soit un QA qui traite l'ensemble des  trigger et les actions à mener pour les # evenements  ( on se rapproche par le principe d'un mini GEA  )

 

Vos avis sont les biens venus et je vous en remercie

 

[Lazer 8 486]

Ta dernière proposition me rappelle ce que fait @jang justement avec son Webhook QA : https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/page/6/?tab=comments#comment-202423

[henri-allauch 225]

Sait-on si la HC3  fait des refreshStates à intervalles, pour réveiller les scènes en attente de  trigger déclarés 

ou c'est directement du code pour chaque device qui produit le trigger ?

 

[Lazer 8 486]

Aucune idée du fonctionnement interne....

[jjacques68 602]

Il y a 2 heures, henri-allauch a dit :

soit une scene à trigger multiple qui dispatche vers des QA pour traiter les actions 1 QA par type d'action par exemple

c'était ma première version, je l'ai vite oublié, les trigger sont pas toujours évident à mettre en place et peu conviviaux...

 

Il y a 2 heures, henri-allauch a dit :

soit un QA qui traite l'ensemble des  trigger et les actions à mener pour les # evenements  ( on se rapproche par le principe d'un mini GEA  )

c'est ma solution actuelle :

 

un seul et unique QA où j'ai :

• la fonction qui tourne en boucle pour analyser le refreshState
• la liste de tous les trigger avec action à faire (dans un tableau)
• Les actions peuvent être directement écrite dans la liste (si c'est simplement allumer qqch) ou faire appel à une méthode d'un autre QA si plus compliqué

 

EDIT : vu comme ça, c'est franchement pas compliqué, mais après on rajoute des tonnes de trucs (gestion des notification, mémo des log, ...) c'est là que ça devient un peu l'usine à gaz...

Modifié 17 mars 2021 par jjacques68

[henri-allauch 225]

La question sur le fonctionnement interne des trigger :

 c'est que pourquoi refaire un système de detection d'évènements si la box le fait correctement ( c'est une charge supplémentaire )

je le conçois pour GEA qui en fait est un outil de langage ouvert et qui doit s'adapter à des configurations et des demandes différentes

donc l'adaptation se fait de manière automatique et les triggers sont variables et nombreux

Mais pour des configurations personnelles je me demande ci c'est pas mieux d'utiliser les trigger de scènes puis l'accès à des QA

Après j'ai toujours préféré des taches ou fonctions simples construites pour faire complètement une chose et une seule.

Ecole des années 70 dictée par les créateurs du c et d'unix  

Centraliser tout dans un QA ca rend aussi comme le dit @jjacques68 une usine à gaz donc si ça plante tout plante et la lecture devient difficile

Comme je ne suis pas pressé j'ai bien envie de tenter la solution2

Bientôt vous allez me répondre  : fait bien comme tu veux !!

[Lazer 8 486]

Oui voilà, fait comme tu veux

 

Non mais sérieusement, je n'ai pas de solution miracle, ou en tout cas, en l'état actuel de mes connaissances de la HC3, je ne sais pas quelle est la meilleure solution d'un point de vue utilisation des ressources de la box.

 

Perso j'aime bien tout centraliser dans GEA, car je trouve que c'est un moyen clair de visualiser tous mes scénarios, mais peut être parce que je lis couramment la ligne de commande (façon Matrix lol... non juste Unixien inside...)

Le risque de plantage ? Ben disons que c'est du tout ou rien, du coup si un truc ne marche pas, on le remarque immédiatement, ça ne risque pas de passer inaperçu. Et puis ça fait un seul truc à monitorer (avec un Watchdog), on ne risque pas d'oublier une scène à part dans un coin.

J'ai 200 règles, je ne me vois pas devoir gérer autant de scènes, ça serait in-maintenable (et pour revenir sur les perfs, pas sûr que la box gère correctement les triggers sur autant de scènes différentes). Et puis chaque scène étant un processus Linux, la consommation en mémoire vive serait largement supérieure.

 

Après pour des scénarios plus classiques, enfin surtout moins nombreux, le mécanisme de trigger des scènes proposé par Fibaro est très bien.

 

L'essentiel est de trovuer chaussure à son pied... mais pour cela il faut souvent en essayer plusieurs.

[jjacques68 602]

Il y a 3 heures, Lazer a dit :

le mécanisme de trigger des scènes proposé par Fibaro est très bien

 oui mais nan... sauf que...  attention :

 

La raison pour laquelle je me suis séparé des scènes est très simple : il n'y a plus de multi-instances possible !!!

 

un exemple tout con parmi plusieurs que j'ai vécu :

 

J'avais 1 scène unique qui me gère l'éclairage automatique des pièces via les PIR.

J'avais tous les PIR en trigger pour cette scène.

La scène allumait la lumière en fonction du trigger.

C'était super bien foutu.

(cette manière de faire était un héritage de la HC2)

 

ça marchait nickel, MAIS... pour un célibataire...  :

 

Si 2 personnes entrent plus ou moins simultanément dans 2 pièces différentes, et bien qu'une seule s'allumera.

Car tu n'as qu'une seule instance possible.

Pour moi c'était pas acceptable.

Sur la HC2 tu pouvais en avoir 10 max, fallait y aller pour que 10 personnes entrent simultanément dans 10 pièces différentes  

 

J'avais plusieurs mécanismes de ce genre qui fonctionnaient bien, mais avec des loupés (gestion des notification, log des evenements, ...)

 

D'où mon passage par le refreshState, car là, quoi qu'il arrive, tu verras le changement d'état de tous les modules, (le FIFO des appels des méthodes, déjà expliqué par @Lazer je sais plus où), fera que tout ce passe bien...

Après j'ai commencé à me servir du resfreshState avant que @Lazer ne code GEA... sinon je pense que j'aurai pris GEA...

Et pareil, j'ai quasi 200 lignes dans ma liste de trigger ,

et dire qu'avant tout était dans des scènes... 

 

Depuis, je n'ai plus aucun soucis de ce genre.

 

Modifié 17 mars 2021 par jjacques68

[Lazer 8 486]

Oui mais ton souci était lié au fait que tu avais un usage un peu extraordinaire des scènes : trop de déclencheurs

 

La logique de Fibaro, c'est une scène = un événement => 1 action

Dans cet usage, le mono instance ne devrait pas être un souci.

 

Faut pas oublier qu'on est quelques uns ici à utiliser nos box de façon relativement intensive, du coup on est obligés de trouver des astuces.

[jjacques68 602]

il y a 28 minutes, Lazer a dit :

quelques uns ici à utiliser nos box de façon relativement intensive

bah en même temps, ils nous mettent les outils pour, on en profite...

[Lazer 8 486]

J'ai failli l'écrire en plus

 

tout à fait d'accord

 

[henri-allauch 225]

Un événement X réveille une scène, la scène réveillée traite les actions ... 

Un nouvel événement arrive pendant ce temps 

Pas de nouvelle occurence de la scène

L'événement est perdu ou on attend la fin d'execution de la scène pour la réveiller a nouveau ? 

 

C'est vrai que dans ce cas ce n'est plus un choix mais une nécessité de passer par resfreshState 

 

 

[jjacques68 602]

il y a 2 cas de figure suivant l'option choisi dans les propriétés de la scène :

Soit un nouvel événement annule l'instance en cours pour en commencer une nouvelle (alors là c'est une rupture net de l'instance en cours)

Soit le nouvel événement est ignoré au profit de l'instance en cours.

Modifié 17 mars 2021 par jjacques68

[henri-allauch 225]

{"type":"DeviceActionRanEvent","created":1615920908,"sourceType":"user","sourceId":2,"objects":[{"objectType":"device","objectId":93}],"data":{"id":93,"actionName":"setProperty","args":["power","2095.00"]}},
{"type":"DevicePropertyUpdatedEvent","created":1615920908,"sourceType":"system","objects":[{"objectType":"device","objectId":93}],"data":{"id":93,"property":"power","oldValue":2035.0,"newValue":2095.0}},
{"type":"DeviceActionRanEvent","created":1615920908,"sourceType":"user","sourceId":2,"objects":[{"objectType":"device","objectId":93}],"data":{"id":93,"actionName":"setProperty","args":["value","2095.00"]}},
{"type":"DevicePropertyUpdatedEvent","created":1615920908,"sourceType":"system","objects":[{"objectType":"device","objectId":93}],"data":{"id":93,"property":"value","oldValue":2035.0,"newValue":2095.0}},
 

DeviceActionRanEvent  ??  je trouve pas  .. si je traite le DevicePropertyUpdatedEvent power ou value que faire du DeviceActionRanEvent

[jjacques68 602]

tu n'es pas obligé de traiter toutes les infos, moi, de mémoire, je traite les "DevicePropertyUpdateEvent", "NotificationCreatedEvent" et "CentralSceneEvent".

Les autres trames passent aux oubliettes  

[henri-allauch 225]

Pour avis avant d'aller plus loin voici mon test

Il faut que je recherche aussi si son utilisation de VG pour trigger et éviter un  blocage et toujours d'actualité 

TestRefreshStates.lua

[Lazer 8 486]

L'événement d'une Variable Globale :

{
    "type": "GlobalVariableChangedEvent",
    "data": {
        "oldValue": "0",
        "newValue": "1",
        "variableName": "Vacances"
    },
    "created": 1602618012
}

 

J'ai cartographié beaucoup d'événements de mon coté, car je les utilise comme triggers dans GEA.

C'est fou tout ce qui existe, et c'est vraiment super en fait, car on peut détecter tout ce qui se passe sur la box.

[henri-allauch 225]

Oui j'ai vu comment faire pour les VG

Je voulais dire il faut que vois si l'utilisation par @jgab d'une VG pour éviter un blocage si pas d'événements en retour de l'appel à l'appi est toujours d'actualité 

 fibaro.setGlobalVariable(tickEvent,tostring(os.clock()) ) -- hack because refreshState hang if no events...

en fait il met tickevent dans une VG pour être sur que le retour de refreshStates ne sera pas vide 

 GlobalVariableChangedEvent = function(self,d)
            if d.variableName == tickEvent then return end

 

[Lazer 8 486]

A priori ce n'est pas nécessaire, car il y a toujours des événements sur la box, j'imagine qu'il avait détecté ce bug tout au début, sur une box sans rien.

En tout cas dans GEA ne n'ai pas implémenté ce hack, et ça ne semble avoir jamais posé de problème. Et pourtant je n'ai que 5 modules Z-Wave.

[jang 225]

Il y a 4 heures, henri-allauch a dit :

Yes I saw how to do for the VG

I wanted to say we must see if the use by @jgab  of a VG to avoid a blocking if no events in return of the call to the app is still relevant 

in fact he puts tickevent in a VG to be sure that the return from refreshStates will not be empty 

 

 

This is not necessary anymore as we use

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

that doesn't block other timers. It was necessary when we used

api.get("/refreshStates...)

that hanged and blocked timers if there were no events.