henri-allauch

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 ?

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.

@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 ?

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

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

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

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

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

@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 .....

Je n'arrive pas à capter dans refreshStates la trame indiquant le start de la box Une scène triggée sur property = "start", type = "se-start", le détecte correctement Dans le QA je ne trouve pas la trame event pour ce start Voici le début de la log après sauvegarde donc restart des services j'ai volontairement laissé les lignes inutiles pour voir le timing des démarrages des QA En fait la seule scène qu'il me reste c'est juste pour detecter le démarrage de la box Une idée ? LogAuBoot.lua RefreshStates.lua

IL me semble qu'on dit bien sur le userID non ?

Il y a 15 jours en faisant un QA ca fonctionnait avec 2 ce soir non Pas grave on s'adapte

Pour Info : dans une scene : fibaro.alert("push", {2}, "Hello Henri") ( 2 = Id User ) fonctionne sur l'ensemble des mobiles dans un QA ce mode ne fonctionne plus aucun push ( pourtant il fonctionnait dans une précédente beta ) il faut : fibaro.alert("push", {22,43}, "Hello Henri") ( 22 et 43 Id des mobiles )

SI elle est partageable ... Je la cherche cette fonction GetVariableQA()

1° J'ai installé un ancien Wallplug 3.52 ( j'ai reçu un module neuf mais impossible de l'inclure ni de l'exclure idem sur ma HC2 alors que le vieux ok du premier coup ) J'ai en standard : Paramètre 40: Reporting significant changes in power. Sélectionné: 80% Paramètre 42: Reporting small changes in power. Sélectionné: 15% Paramètre 43: Time period within which the Wall Plug may sent up to 5 reports on small changes in power (resulting from parameter 42 settings). Sélectionné: 30s IL faut les mettre à 0 ou sur ce type de device c'est inutile et ce WP n'est fait pour la HC3 que pour des essais initiaux ? Et donc éviter en sa présence l'inclusion d'autre module qui pourraient s'en servir de passerelle

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

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

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

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

Et a ton avis il vaut mieux le sien ou celui que tu as mis ici 2.6 Moi il fonctionnent bien a priori le tien fonctionne bien j'ai quelques connection en erreur mais ça ne plante pas. [17.03.2021] [14:15:29] [DEBUG] [QA_NETATMO_34]: Current time : 14:15:29 - Last updated values : 14:14:51 - Next loop in 572 seconds at 14:25:01 ... [17.03.2021] [14:15:39] [ERROR] [QA_NETATMO_34]: Connection error: Operation canceled [17.03.2021] [14:25:01] [DEBUG] [QA_NETATMO_34]: Current time : 14:25:01 - Last updated values : 14:14:51 - Next loop in 30 seconds at 14:25:31 ...

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 !!

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 ?

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

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

@lazer OK avec plaisir ta version fonctionne bien et il y aura moins de log