Aller au contenu

UN petit coup de main SVP

henri-allauch

Par henri-allauch
dans Support

 Partager

Messages recommandés

  • Réponses 130
  • Créé
  • Dernière réponse

Meilleurs contributeurs dans ce sujet

Jours populaires

Meilleurs contributeurs dans ce sujet

Jours populaires

Messages populaires

jang
jang

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("/refre

jang
jang

function dumpScene(id) local s,c,f = api.get("/scenes/"..id) c = json.decode(s.content) f = io.open("Scene_"..id.."_actions.lua","w"); f:write(c.actions); f:close() f = io.open("Scene_"..id.."

Barelle
Barelle

Un quickApp mineur 

Images postées

henri-allauch Contributor

henri-allauch

Posté(e)
  • Auteur
Posté(e) (modifié)

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é par henri-allauch
Lazer Rising Star

Lazer

Posté(e)
Posté(e)

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 Contributor

jjacques68

Posté(e)
Posté(e) (modifié)
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é par jjacques68
henri-allauch Contributor

henri-allauch

Posté(e)
  • Auteur
Posté(e)

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

  • Upvote 1
henri-allauch Contributor

henri-allauch

Posté(e)
  • Auteur
Posté(e)

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

 

henri-allauch Contributor

henri-allauch

Posté(e)
  • Auteur
Posté(e)

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 ?

 

jjacques68 Contributor

jjacques68

Posté(e)
Posté(e) (modifié)
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é par jjacques68
henri-allauch Contributor

henri-allauch

Posté(e)
  • Auteur
Posté(e)

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 Rising Star

Lazer

Posté(e)
Posté(e)

Oui voilà, fait comme tu veux :D

 

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 Contributor

jjacques68

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

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

:police: 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... :3:

 

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

 

Modifié par jjacques68
Lazer Rising Star

Lazer

Posté(e)
Posté(e)

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 Contributor

jjacques68

Posté(e)
Posté(e)
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... :)

henri-allauch Contributor

henri-allauch

Posté(e)
  • Auteur
Posté(e)

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 Contributor

jjacques68

Posté(e)
Posté(e) (modifié)

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é par jjacques68
henri-allauch Contributor

henri-allauch

Posté(e)
  • Auteur
Posté(e)

{"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 Contributor

jjacques68

Posté(e)
Posté(e)

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

  • Thanks 1
Lazer Rising Star

Lazer

Posté(e)
Posté(e)

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.

  • Like 1
henri-allauch Contributor

henri-allauch

Posté(e)
  • Auteur
Posté(e)

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 Rising Star

Lazer

Posté(e)
Posté(e)

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.

  • Thanks 1
jang Newbie

jang

Posté(e)
Posté(e)
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.

  • Like 1
  • Thanks 1
  • Upvote 1
 Partager
Aller sur la liste des sujets
×
×
  • Créer...