UN petit coup de main SVP

[jjacques68]

je vais poser une question bête mais je la pose : 

 

pourquoi les "self" dans les arguments des fonctions ?

comme : 

function startPolling(self,interval)
	...
end

...

startPolling(self,1000)

ou encore: 

DevicePropertyUpdatedEvent = function(self,d) ... end,

 

[Barelle]

Pour avoir la visibilité sur les fonctions déclarées comme rattachées à la classe QuickApp.

 

QuickApp:fonction(a, b, c) est syntactiquement équivalent à fonction(self, a, b, c). Dans ce dernier cas fonction est locale au quickapp sans appartenir à la classe QuickApp...

[Lazer]

@Barelle juste histoire de polémiquer un peu  :

 

Dans ce dernier cas fonction est locale au fichier du quickapp...

 

Et encore, c'est vrai si tu déclares la fonction avec local function(...)

Sinon elle sera globale (c'est à dire accessible depuis tous les fichiers du QA)

Mais dans tous les cas on est bien d'accord qu'elle ne sera pas exposée aux autres QuickApp par le biais de fibaro.call()

 

Je crois qu'on va noyer tout le monde
 

[jjacques68]

il y a 11 minutes, Barelle a dit :

QuickApp:fonction(a, b, c) est syntactiquement équivalent à fonction(self, a, b, c)

ok je comprends.

 

il y a 11 minutes, Barelle a dit :

Dans ce dernier cas fonction est locale au quickapp sans appartenir à la classe QuickApp

euh..... la je comprends pas ducoup...

C'est l'inverse, fonction à patient à la classe QuickApp !! à cause du self

 

roah punaise ça m'a toujours rendu dingue ce truc !!

Tu crois avoir compris... puis tu vois un autre exemple qui te flingue les neuronnes  

[jjacques68]

il y a 1 minute, Lazer a dit :

Je crois qu'on va noyer tout le monde

c'est fait.

[Lazer]

Sa phrase était ambiguë.

 

Explication :

 

Dans ce dernier cas fonction est locale au quickapp (le QA en tant que module, donc pas accessible depuis les autres QA via l'API fibaro.call()) sans appartenir à la classe QuickApp (la classe QuickApp en LUA)

 

En fait, toutes les fonctions déclarées dans QuickApp (y compris onInit() du coup) sont automatiquement exportées, donc exécutables depuis n'importe où via l'API.

Il y a les fonctions que l'on crée, et les fonctions prédéfinies (le fameux self:debug(), ce n'est que la fonction debug prédéfinie (qui est en fait héritée de la classe parent, mais peu importe)... qu'on peut s'amuser à redéfinir si on veut ! )

 

Est-ce plus clair ainsi ?

[jjacques68]

euh... franchement, sans vouloir te vexer, avec tout le respect, toute mon admiration, toutes ma sympathie et toute ma reconnaissance : NON

 

[Lazer]

je vais me confiner pour la peine

 

Attendons la version de @Barelle alors qui sera peut être plus compréhensible

 

[jjacques68]

c'est réalisable de représenter le fonctionnement sur un schéma, une map, le rendre visuel quoi ?

je encore pas trouvé de tel documents...

[Lazer]

Hum.... oui.... ça devrait être faisable, mais c'est pas mal de travail.... ça m'embête car ça va être sans fin cette discussion, on est en train de partir dans un cours de LUA là.

[jjacques68]

j'imagine bien oui, je te demande de le faire forcément toi même, je me dit que ça doit exister quand même !!

une sorte de cartographie...

 

[Barelle]

Un rapide exemple, mais non testé...

 

local delay	= 60; -- la variable sera visible par l'ensemble du code

function QuickApp:onInit()
	-- On prépare l'environnement d'éxécution :
	--  - vérification de la cohérence des variables
	--  - récupération des éléments nécessaires
	--  - initialisation des childs
	--  - ...
	
	local ok, err = pcall(function() mainLoop(self); end)
	if not ok then self:error("onInit>>>Error calling mainLoop : ".. err); end
end -- QuickApp:onInit


function mainLoop(self) -- On passe self en paramètre pour pouvoir utiliser les fonction natives du quickapp comme self:trace, self:debug...
	--
	-- On fait le boulot
	--
	processLeBoulot(self);
	
	fibaro.setTimeout(delay * 1000, function() mainLoop(self); end);
end -- mainLoop

function round(num, numDecimalPlaces) -- On ne passe pas self en paramètre car on n'en a pas besoin
	return tonumber(string.format("%." .. (numDecimalPlaces or 0) .. "f", num));
end -- round

function processLeBoulot(self);
	self:debug("Silence, je bosse !");
	
	self:trace("pi avec 2 décimales : ".. round(math.pi, 2));
end -- processLeBoulot

 

Modifié le 18 mars 2021 par Barelle
Erreur de syntaxe

[jjacques68]

donc si,je suis ce que tu dis, dans la fonction mainloop(), si je mets pas le self en argument, je ne peux pas utiliser les instructions self:debug() et autres ?

[Barelle]

Oui, sauf à la déclarer pour qu'elle appartienne à la classe QuickApp : function QuickApp:mainLoop()

[jjacques68]

oui tout à fait.

 

et le coup du quickApp sans majuscule, c'est quoi une "bibliothèque" ?

[Barelle]

Un quickApp mineur 

[Lazer]

On en avait déjà parlé il y a quelques mois il me semble, non ?

 

QuickApp, c'est la classe

quickApp, c'est un objet instancié à partir de la classe

 

Je vais essayer de retrouver la discussion....

 

EDIT : voilà

 

 

Modifié le 18 mars 2021 par Lazer

[jjacques68]

ahhhhhhhh, faut que je relise à tête reposée...

[Lazer]

il y a 24 minutes, jjacques68 a dit :

c'est quoi une "bibliothèque"

C'est un un terme générique, tu trouveras plus généralement le terme library en anglais, improprement traduit "librairie" en français (faux-amis)

 

En informatique on appelle librairie tout ce qui est un bout de code partageable et réutilisable par plusieurs programmes.

L'exemple bien connu, ce sont les tristement célèbres DLL dans Windows (Dynamic Link Library, le truc qui manque parfois quand tu installes un programme, et il refuse de s'exécuter)

Tous les OS utilisent ce principe, Linux, etc, mais ça n'a rien de standardisé, le concept de librairie est général, après chacun l'implémente comme il veux.

Et ça se sont les librairies partagées, mais tu peux aussi, quand tu compiles un programme, attacher une librairie en statique afin que le programme soit totalement autonome et ne dépende pas d'une librairie externe. Le programme est ainsi plus portable, mais aussi plus lourd (espace occupé)

 

Appliqué au LUA, quand tu utilises les fonctions dans json, net, os, etc, ce sont des librairies, qui sont fournies en standard au LUA ou bien ajoutées par Fibaro.

 

 

Appliquée aux QuickApps, ma façon de faire (qui n'est pas forcément idéale, mais en tout cas je l'aime bien), c'est de considérer les fichiers à l'intérieur de chaque QA comme des librairies, qui me permettent de facilement réutiliser (par copier/coller... oui désolé LOL) des bouts de codes entiers d'un QA à un autre. Par exemple ma librarie tools que j'utilise partout (et que j'améliore au fur et à mesure), mais aussi Notifications, SNMP, etc.

C'est du code qui n'est pas directement lié au QuickApp. Car le code que je met dans mes librairies effectue des opérations indépendantes, qui n'agissent pas directement sur le QuickApp. Ainsi c'est relativement portable et réutilisable dans un autre contexte. Dans l'univers Fibaro on peut citer les modules virtuels et les scènes, mais le LUA existe aussi en dehors. Et bien justement, l'autre jour pour le boulot j'avais une grosse quantité de données à traiter, j'avais le choix entre le Shell ou Excel, mais aucune des 2 solutions ne me convenait. J'ai installé rapidement LUA sous Linux (apt install lua), et j'ai copié/collé ma librairie tools car j'avais besoin de certaines fonctions dedans.

[henri-allauch]

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

[jjacques68]

ça je sais pas.

 

mais perso je ferais autrement.

si tu veux détecter le boot de la box, utilises un QA.

le onInit() des QA étant exécuté qu'une seul fois au démarrage de la box, fais toi un spécifiquement à cette usage.

C'est que j'ai fait, pour être notifié par mail que la box a redémarré.

ça marche très bien.

 

et du coup tu te sépares de ta dernière scène  

 

edit : ou mets la notification dans le onInit() de ton refrehState()

Modifié le 20 mars 2021 par jjacques68

[Lazer]

Il faut aussi penser à tester le timestamp contenu dans serverStatus via /api/settings/info pour vérifier que le QA n'a pas été redémarré longtemps après le reboot de la box

[jjacques68]

tiens c'est pas bête ça !

ça évite la notification à chaque fois que tu touches au QA !!

 

EDIT : par contre est-ce que cette info est mise à jour de suite au boot, parce que ça drop sévère...

Modifié le 20 mars 2021 par jjacques68

[Lazer]

Cette valeur est mise à jour suite au boot, au backup, etc, bref tout ce qui redémarre les services Fibaro.

 

Il suffit de le comparer au os.time() courant, si par exemple le delta est inférieur à 120 secondes, on peut raisonnablement penser que la box vient de booter, sinon c'est juste le QA qui a été redémarré.

C'est comme ça que GEA procède depuis la HC2, de même que l'une de mes scènes que je m'étais fait à l'époque.

 

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

 

[jang]

Il y a 1 heure, Lazer a dit :

This value is updated following boot, backup, etc., in short, anything that restarts the Fibaro services.

 

It suffices to compare it to the current os.time (), if for example the delta is less than 120 seconds, we can reasonably assume that the box has just booted, otherwise it is just the QA which has been restarted.

This is how GEA proceeds from the HC2, as well as one of my scenes that I had done at the time.

 

@ henri-allauch besides I do not see how you would want to intercept the boot of the box in the refreshState from a QA, since the QA necessarily started after the boot of the box.

 

Yes, that's how I do it in EventRunner4 too.

    local uptime = api.get("/settings/info").serverStatus or 0
    if os.time()-uptime < 30 then quickApp:post({type='se-start'}) end

I have a post function that adds fake events to my refreshStates loop. Nice way to test functionality in the system too...