Centralisation de fonctions LUA dans une scène

**vinzcenzo** · le 18 octobre 2020

En évaluant le job que j’aurai potentiellement à faire pour changer de box, je me suis mis à inventorier le code LUA utilisé sur ma HC2.

Je me suis rendu compte que j’avais dupliqué pas mal de code (fonctions, routines, etc.) et surtout lors de correction de certaines portions de code j’ai oublié de le corriger dans quelques scènes ou ce code était dupliqué…

Alors ce week-end, j’ai planché sur une solution me permettant de simplifier mon code et de le centraliser. Donc voici ci-dessous, ce que j'ai effectué.

Stratégie

création d'une scène que j'ai nommée scGloFuncLib (id:186) et qui est structurée comme suit :
- VARIABLES/CONSTANTES PERSONNALISABLE PAR L'UTILISATEUR;
  - variables et constantes, modifiable par l'utilisateur, lui permettant d'adapter les valeurs à son environnement;
- VARIABLES/CONSTANTES INTERNES (à ne pas modifier);
  - variables et constantes, nécessaires au bon fonctionnement de la scène. La valeurs définies ici sont sensées être optimisées et ne devraient pas être modifiées par les utilisateurs => risques d'effets de bord non maîtrisés;
- LES FONCTIONS INTERNES
  - les fonction internes sont les fonction qui ne sont pas appelée en dehors de la scène, mais qui sont utiles à aux fonctions "exposées";
- LES FONCTIONS EXPOSÉES
  - les fonctions exposées, sont les fonction accessibles avec un appel externe depuis une autre scène/VD;
- MAIN
  - permet d'analyser les arguments et d'appeler les fonctions concernées en vérifiant et en passant les bons paramètres;
appel de la scène susmentionnée depuis une autre scène/VD avec le code suivant :

fibaro:startScene(186, { "myFunction1", "p1", "p2", "pN" })

Limitations

La limitation de ce système pour l'instant et le retour de valeur entre la scène qui appelle la fonction et celle qui l'exécute.

N'ayant pour l'instant pas ce besoin, je n'ai rien fait. Mais si cela devait changer, je procéderais certainement de la manière suivante :

création d'une variable globale avant l'appel de la fonction;
appelle de la fonction via la scène scGloFuncLib en passant le nom de la variable globale créée;
récupération de la valeur de la variable globale;
destruction de la variable globale.

Squelette du code LUA

---- ***********************************************************************
---- VARIABLES/CONSTENTES PERSONNALISABLES PAR L'UTILISATEUR
---- ***********************************************************************
---- Description
----    variables et constantes, modifiable par l'utilisateur, lui
----    permettant d'adapter les valeurs à son système.
---- -------------------------------------------------------------------
---- myFonction1
---- -------------------------------------------------------------------
FUNCTION1_DEF_PARAM2 = "123456asdf";
---- -------------------------------------------------------------------
---- log_debug
---- -------------------------------------------------------------------
IS_DEBUG_MODE = true;


---- ***********************************************************************
---- VARIABLES/CONSTENTES INTERNES (à ne pas modifier);
---- ***********************************************************************
---- Description
----    variables et constantes, nécessaires au bon fonctionnement de la
----    scène. La valeurs définies ici sont ensées être optimisées et ne
----    devraient pas être modifiées par les utilisateurs => risques
----    d'effets de bord non maîtrisés.
---- -------------------------------------------------------------------
---- System
---- -------------------------------------------------------------------
MD5_HASH = "cb2b8c02de4f322cd67fd8e7a88d420f";


---- ***********************************************************************
---- LES FONCTIONS INTERNES
---- ***********************************************************************
---- Description
----    les fonction internes sont les fonction qui ne sont pas appelées
----    en dehors de cette scène, mais qui sont utiles aux fonctions
----    "exposées".
---- -------------------------------------------------------------------
---- function : log_std
---- -------------------------------------------------------------------
---- paramètres : 
----   str  : log a envoyer dans la fenêtre de debug
---- retour : <aucun>
---- -------------------------------------------------------------------
function log_std(str) 
    if IS_DEBUG_MODE then 
      fibaro:debug("<font color='yellow'>"..str.."</font>");
    end
end


---- ***********************************************************************
---- LES FONCTIONS EXPOSÉES
---- ***********************************************************************
---- Description
----    les fonctions exposées, sont les fonction accessibles avec
----    un appel externe depuis une autre scène/VD.
---- -------------------------------------------------------------------
---- function : myFunction1
---- -------------------------------------------------------------------
---- paramètres 
----   _param_no1 : paramètre1
----   _param_no2 : paramètre2
----   retour     : <aucun>
---- -------------------------------------------------------------------
function myFunction1 (_param_no1, _param_no2)
  -- * exécution de ma fonction "exposée
end


---- ***********************************************************************
---- MAIN 
---- ***********************************************************************
---- Description :
----   la boucle principal permet d'analyser les arguments et d'appeler
----   les fonctions concernées en leurs passant les bons paramètres.
---- Arguments :
----   args[1] = <functionName> : nom de la fonction appelée
----   args[n] = <parameters>   : parametres des fonctions appelées
---- -------------------------------------------------------------------

-- * première chose à faire vérifier s'il y a des arguments
if fibaro:args() == nil then
	-- * pas d'argmuent alors on sort de la scène
	return
else
	-- * arguments, alors on les entre dans une table
    func_args = fibaro:args();	
	-- * puis on vérifie que le premier argument (nom de la fonction) existe
	if func_args[1] == nil or func_args[1] == "" then
		-- * pas de args[1] alors on sort de la scène, car aucune fonction a appeler
		return
    -- * si args[1] = myFunction1 alors on traite les paramètres par rapport à cette fonction
	elseif func_args[1] =="myFunction1" then
  ---- -------------------------------------------------------------------
  ---- calling myFunction1 function
  ---- -------------------------------------------------------------------
  ---- Parameters : 
  ----   args[2] = param_no1 (obligatoire)
  ----   args[3] = param_no2 
  ---- -------------------------------------------------------------------  
    local param_no1,param_no2
    -- * vérificatio du premier paramètre args[2] qui est obligatoire
    if func_args[2] == nil or func_args[2] == "" then
        -- * le paramètre est obligatoire, alors si pas renseigné on sort de la scène
        return
    else
      -- * on attribue args[2] à la variable param_no1
      param_no1 = func_args[2];    
    end  
    -- * vérificatio du deuxième paramètre args[2] qui est facultatif
    if func_args[3] == nil or func_args[3] == "" then
        -- * le paramètre est facultatif, possibilité d'attribuer une valeur par défaut si vide ou null
        param_no2 = FUNCTION1_DEF_PARAM2;
    else
      -- * on attribue args[2] à la variable param_no2
      param_no2 = func_args[3];    
    end    
    
    
    myFunction1 (param_no1,param_no2);
    return
  else
    -- * si args[1] ne correspond à aucune des fonctions exposées (func_args[1] =="FunctionName")  , alors on sort de la scène.
		return
  end
-- fin de l'execution de la scène.
end

Modifié le 18 octobre 2020 par vinzcenzo

**Lazer** · le 18 octobre 2020

C'est beau, mais..... si tu comptes passer sur HC3 :

oublie les scènes qui ne sont clairement pas mises en avant :
- 1 seule instance maximum
- je n'ai pas trouvé comment passer des arguments
- toujours pas possible de récupérer le retour, sauf à utiliser la méthode bien lourde des variables globales
les QuickApps c'est l'avenir
- justement, on peut maintenant définir des fichiers au sein de chaque QuickApp, super pratique pour décomposer son compte et utiliser des librairies de fonctions

**vinzcenzo** · le 18 octobre 2020

Pour la HC3, je ne suis pas sûr que ce sera la solution pour moi... ce qui m'embête avec cette HC3 c'est de repartir dans la même logique d'utilisateur bêta testeur pendant de longues années, avec un produit qui marchotte de version en version, avant d'avoir un truc de stable. Ceci parce que Fibaro n'a pas su capitaliser sur sont expérience et a voulu repartir sur une feuille presque blanche.

Mon premier objectif, avec cette centralisation, c'est d'épurer 5 ans de codage sur ma HC2... quand j'ai un bout de code avec min. 8 variantes mais qui font la même chose, je me dis que je peux mieux faire

**Lazer** · le 18 octobre 2020

Ta première phrase, tu peux l'application à Jeedom, Domoticz, Home Assistant, ça sera exactement pareil. La seule différence c'est que c'est gratuit (enfin, faut quand même payer une machine pour l'héberger)

Si tu veux un système stable, qui ne soit pas en développement, tu peux prendre une Somfy Box par exemple, tu pourras faire.... rien... avec.

Sinon pour la logique du raisonnement de mutualisation des fonctions, je suis d'accord

**vinzcenzo** · le 18 octobre 2020

il y a 4 minutes, Lazer a dit :

Ta première phrase, tu peux l'application à Jeedom, Domoticz, Home Assistant, ça sera exactement pareil. La seule différence c'est que c'est gratuit (enfin, faut quand même payer une machine pour l'héberger)

Alors pour moi ce n'est pas qu'une question de prix... bien que ça me troue effectivement le cul de payer une box plus de 400€ pour un support inexistant!

Avec Jeedom, Domoticz, HomeAssistant, openHAB (aussi) ça bouge quand même un peu plus... certes le côté app mobile est peut-être moins aboutie, mais ça évolue quand même assez rapidement et ça reste moins blackbox.

Qu'on soit d'accord, je vais pas non plus chier sur Fibaro... car je trouve qu'il y a de très bonnes choses.... mais comme je l'ai dit dans un autre poste je peine à comprendre leur stratégie... j'aime bien leurs produits, mais leur approche client n'est pas à la hauteur de leurs prétentions marketing et je trouve dommage qu'il n'exploitent pas plus le potentiel qu'ils ont entre leurs mains!

**Lazer** · le 18 octobre 2020

Ah mais je ne dis pas le contraire, ça évolue plus vite sur les solutions open-source

Je réagissais juste à ta phrase "repartir dans la même logique d'utilisateur bêta testeur pendant de longues années, avec un produit qui marchotte de version en version, avant d'avoir un truc de stable" parce que tu auras exactement la même chose sur les solutions open-source, et même, je pense à la lecture des forums, en pire :

Non parce que sérieusement, en dehors des blogueurs qui font la promo de telle ou telle solution, quand tu vas fouiner sur le forums, tu te rends vite compte que l'herbe n'est pas plus verte ailleurs du point de vue de la stabilité, du support. J'ai même vu des gens en revenir pour dire que c'est plus stable chez Fibaro. Comme quoi...

Après, ces solutions open-source, si tu es geek, que tu as une infra virtualisée, la possibilité de snapshoter pour revenir en arrière, là y'a moyen de s'éclater.

Si tu veux piloter whatmille objets connectés aussi, tant les plugins sont nombreux.

Si tu es développeur et que tu sais écrire tes propres plugins, il n'y a plus aucune limite.

Bref, faut poser le pour et le contre, perso je reste chez Fibaro parce que ça marche bien (mon HC2 va fêter ses 7 ans le mois prochain), c'est bien plus stable que la lecture des forums ne le laisse croire (normal on entend toujours les râleurs, moi compris), et je maitrise la solution (la HC3 est différente en apparence, mais on retrouve beaucoup de concepts identiques).

Et j'en ai rien à faire de piloter des objets connectés chinois à pas cher buggués de partout (coucou Xiaomi, Sonoff, ...).

La relative "non-ouverture" de la HC3 ne me dérange pas, j'y trouve largement mon compte (elle permet déjà tellement plus que la HC2)

Je suis d'accord avec tes remarques concernant Fibaro..... cependant leur stratégie est très claire, surtout depuis le rachat par NICE : offre orientée vers les pros (comprendre : les intégrateurs).

Le grand public, l'utilisateur final, ils s'en moquent. De toute façon, même à l'époque de la HC2, ils n'ont jamais écouté les retours utilisateurs.

On peut s'estimer heureux d'avoir la possibilité d'acheter la box en direct.

En tout cas, ils ne cherchent absolument pas à concurrencer les solutions "open-sources qui savent tout faire", cela ne cible pas du tout la même population.

Leur concurrent, c'est Somfy, qui pour rappel est le distributeur n°1, et de très loin, en box domotique. Sauf que quand tu compares la HC3 et une box Somfy, il y a un monde entre les deux. Il y a donc un potentiel énorme, reste à Nice d'arriver à promouvoir leur offre (au travers des intégrateurs justement... la domotique rentre en force chez les gens par l’automatisation du portail et des volets)

**vinzcenzo** · le 18 octobre 2020

Citation

c'est bien plus stable que la lecture des forums ne le laisse croire (normal on entend toujours les râleurs, moi compris)

Je suis d'accord avec toi alors ... Oui, maintenant, la HC2 est bien stable, mais ça n'a pas toujours été le cas... même si souvent les problèmes de stabilités viennent de ce qu'on fait avec, mais encore une fois sans visibilité c'est compliqué de pouvoir diagnostiquer correctement et de savoir d'où ça vient

Sinon pour rebondir aussi sur :

Citation

cependant leur stratégie est très claire, surtout depuis le rachat par NICE : offre orientée vers les pros (comprendre : les intégrateurs)

Je pense que justement, si c'était vraiment l'orientation qu'ils voulaient donner, il y aurait un peu plus de possibilité de justement intégrer des choses "plus pro" et monitorer les choses par des professionnels. Il y a certes un pas dans ce sens avec la HC3... mais pas suffisamment à mon goût (je sais je suis un peu un chieur :98: )

We'll see what happens...

**Lazer** · le 18 octobre 2020

Justement non en fait.

Un pro a besoin de vendre un truc qui marche, qui soit stable, et fiable dans le temps.

Un truc qui ne lui plombe pas sa rentabilité en faisant du SAV à outrance chez les clients mécontents.

Donc les trucs avancés, les moutons à 5 pâtes qui font papa maman, c'est bien pour les geeks qui ne comptent pas leurs heures, mais pas pour les pros.

La HC3 (ou même la HC2) en fait déjà trop pour les besoins d'un pro, très clairement avec nos nombreux Modules Virtuels / Quick Apps, Scènes alambiquées, règles GEA, etc... on en fait déjà largement plus que ce que n'importe quel intégrateur va mettre en place chez un client.

Et j'aimerais pas être à la place du pro qui tombe chez le client "à moitié geek", celui qui a vu qu'on pouvait connecter un module Zigbee Xiaomi ou un relai Wi-Fi Sonoff, et va demander à son intégrateur de lui fournir une solution interopérable avec tout.

L'enfer du pro, se retrouver à déployer une solution qu'il ne maitrise pas, et qui va lui revenir à coup sûr dans la tronche quand le client qui a bidouillé va venir se plaindre que plus rien ne fonctionne.

Mon métier c'est de l'informatique, et c'est vraiment pareil.

Je déploie une solution fermée à base d'UNIX propriétaire, je sais que ça va fonctionner, le résultat est prévisible et parfaitement documenté par l'éditeur, jamais aucune surprise (sauf bug/plantage/panne, ça peut toujours arriver)

Je vais déployer un Linux, c'est juste l'enfer tant les possibilités sont infinies, t'es incapable de prédire le temps que tu vas y passer, il n'y a pas 2 configurations identiques.

(bon celui qui n'a jamais fait d'UNIX ne peut pas comprendre cela dit...)

**vinzcenzo** · le 18 octobre 2020

De mon côté ça fait plus de 20 ans que je fais de l'intégration IT en SSI dans le software dév. et dans les infrastructures réseau et sécurité (j'ai même eu l'occasion de créer et développer une société proposant produits pour le B2B sur des segments de niche) donc l'intégrateur pro je vois tout a fait ce qu'il a besoin... et effectivement un pro a besoin de ce que tu dis... mais pas que...

Pour éviter de perdre de l'argent le pro à aussi besoin :

d'un SAV digne de ce nom (ici en Suisse même les intégrateurs ont tout autant de problèmes à contacter et à être entendu par le support Fibaro!!!), c'est généralement le distributeur (qui est multi-marques) qui fait le job du constructeur.. c'est un peu ballaud quand même (lui aussi aimerai avoir plus de rentabilité j'imagine);
d'outils de diagnostiques efficaces et professionnels, sans devoir faire du wireshark ou d'un analyseur de spectre de fréquence pour essayer de comprendre ce qui se passe dans la box de son client;
de ne pas être obligé d'être lié à un système cloud pour des fonction de base tel que l'alerting ou le remote controle.... ceci pour ne pas être dépendant de l'infrastructure de Fibaro et pour des raison de confidentialité et du disponibilité du système;
besoin de produits lui permettant de développer des services voir un écosystème à forte valeur ajoutée, donc un flexibilité et une toolbox digne de ce nom;

Donc déjà nous sommes à des années lumière pour que Fibaro soit le produit idéal en terme d'intégration professionnelle... Ou alors ils ont vraiment foiré leur étude de marché, s'ils s'adressent qu'à ce type de personnes... :93:

Il ne faut dès lors pas se leurer, les box Fibaro vont rester pour une communauté de geeks ou d'utilisateurs démerdes. Monsieur et madame tout le monde auront plutôt tendance à se diriger vers du Apple HomeKit ou du Samsung SmartThings... contrôllé par du Siri, Google Assistant ou Alexa...

Si aujourd'hui j’étais intégrateur, et devais intégrer professionnellement un produit domotique pour du Home Automation, je ne proposerait jamais du Fibaro, ou quelques autres solutions OpenSource soit dit en passant... Mais une vrais solution éprouvées dans le building automation fournis par un leader tel que par exemple ici en suisse Feller... mais nous ne sommes pas dans la même catégorie, et la tu ne peux dire que ça va pas plomber la rentabilité ou ne pas être fiable dans le temps... Question fiabilité, sécurité et stabilité rien à redire et ça fonctionne comme une horloge...

il y a 39 minutes, Lazer a dit :

Mon métier c'est de l'informatique, et c'est vraiment pareil.

Je déploie une solution fermée à base d'UNIX propriétaire, je sais que ça va fonctionner, le résultat est prévisible et parfaitement documenté par l'éditeur, jamais aucune surprise (sauf bug/plantage/panne, ça peut toujours arriver)

Je vais déployer un Linux, c'est juste l'enfer tant les possibilités sont infinies, t'es incapable de prédire le temps que tu vas y passer, il n'y a pas 2 configurations identiques.

(bon celui qui n'a jamais fait d'UNIX ne peut pas comprendre cela dit...)

Une blackbox c'est une chose... mais tu fournis la toolbox nécessaire à l'opération de ta solution... vu que tu bosses dans l'intégration UNIX, l'exemple VMware doit de parler. L'hyperviseur ESXi et très fermé voir limite blackbox et ce même sur une base Linux (base qui est devenu très propriétaire depuis un certaine nombre d'année maintenant). Mais d'un autre côté même en étant si fermée, ils offrent une palette d'outils de diagnostique et de déploiement phénoménal et l'hyperviseur n'en reste pas moins robuste... un ESXi tu le déploie sans problème jusqu'à la petit virgule de configuration en ligne de commande, ou avec des outils DevOPS tel que Ansible, et aussi tu peux valider tous tes métriques CPU/Memoire/Disques/Network avec un ESXTop.

Et pour Linux/BSD tout à fait d'accord, et même au niveau distribution... un Ubuntu ne prendra pas le même temps à installer qu'une Gentoo ou qu'un Free/Net ou OpenBSD.

Au final comme je l'ai dit auparavant, je ne chie pas du tout sur Fibaro... pour l'usage que j'en fait c'est cool. Par contre, il me manque indéniablement des choses pour que je soit OK de me diriger les yeux fermer sur une nouvelle HC3, sans remettre en question ce que j'ai, ce que je désire et ce que propose le constructeur...Heureusement qu'il y a une telle communauté de passionnés, parce que ça permet d’exploiter cette boite à fond et de na pas lâcher... :13:

**Lazer** · le 20 octobre 2020

Oui tu as raison.

Les intégrateurs, les vrais pros de la domotique (pas les électriciens/poseurs d'alarme et de volets qui installent 1 box domotique tous les 2 mois), font du KNX. C'est cher, valable uniquement en construction/rénovation lourde (donc cher aussi !), du coup le marché ne se développe pas (particulièrement en France)

Les trucs pour le grand public vendus sur les étagères de la Fnac ou de l'AppStore pour la famille Michu, j'appelle pas ça de la domotique perso... Mais des objets connectés.

Donc oui la domotique est un marché de niche, et le restera très longtemps.

Soit tu veux un système fermé qui ne fait rien à part allumer les lumières depuis ton smartphone comme dans les publicités débiles, soit du veux une vraie domotique "intelligente" (ce terme ne veux rien dire, il vaut mieux parler de maison autonome, c'est à dire une maison bourrée de capteurs qui sait réagir seule aux différents événements)., dans ce cas pas le choix que de nous tartiner la configuration à la main. Rien n'existe sur l'étagère, et la domotique avancée restera longtemps un marché de niche pour geeks.

J'ai coutume de comparer la domotique avec l'informatique.... des années 80/90 ! Parce que c'est bien là qu'on en est, c'est à dire avant l'an 2000 de l'informatique, l'explosion d'Internet, l’interopérabilité de tous les ordinateurs autour d'un réseau commun.

La domotique, c'est le DOS des années 80, se tartiner des commandes à la main avec des profils config.sys personnalisés en fonction de l'usage car 640k de mémoire c'est pas assez. C'est le Windows des années 90 où chaque nouvelle version impose un reformatage complet de son système. C'est le Linux des années 90/2000, se recompiler des noyaux la nuit si tu veux intégrer le driver du dernier périphérique à la mode. Le document Office qui ne peut être ouvert sur autre chose que Office lui-même. Etc....

Tu m'étonnes que ça ne décolle pas !

Dans 10 ou 20 ans, on en reparlera.

Ce qui me désole, c'est que ça fait 7 ans que je fais de la domotique, ça n'a pas évolué d'un pouce. Le Zigbee cartonne, alors qu'il est moins évolué que Z-Wave. EnOcean est un échec cuisant. Les tentatives de standardisation type OpenThread ont fait plouf. La mode est aux objets et modules connectés sur Wi-Fi.... youhou, on est vachement avancé avec ça...

Bref, ce débat on l'a déjà eu 100x sur le forum, et les autres forums, rien de nouveau.... fait ton choix de "centrale domotique" en fonction de tes besoins, de tes compétences, du temps que tu es prêt à y consacrer, etc

Perso comme dit, je reste chez Fibaro car c'est un environnement que je maitrise, j'en connais les limitations, mais surtout il est stable, c'est plus important que de pouvoir intégrer le dernier objet à la mode à mes yeux.

Connexion

Centralisation de fonctions LUA dans une scène

Messages recommandés

vinzcenzo

Lazer

vinzcenzo

Lazer

vinzcenzo

Lazer

vinzcenzo

Lazer

vinzcenzo

Lazer

Outils

Appli Mobile

Appli Tablette

Fibaro Finder

Documentation

Plus

Activité