Steven

Il me semble que IFTTT est activé pour les thermostats Somfy. https://www.somfy.fr/so-open-with-somfy ... ils sont gonflé quand même "SO OPEN". Oups et un API en plus : https://developer.somfy.com/apis-docs

Par contre, il faut pas oublié que le Delta intègre aussi une Tahoma Somfy (sous réserve), ce qui n'est pas négligeable pour les personnes comme moi qui ont des BSO Somfy. Reste à voir l'ouverture de cela (API, IFTTT, ... ?) Beaucoup d'inconnu mais j'adhère au principe pour ma part. Et il y a aussi le pont Philipps Hue.

Le réponse me semble évidente. Est-ce plus rapide de parcourir 2 tableaux ou 4 tableaux. t.exemple.etat = 2 tableaux t.exemple.Suite.n.v = 4 tableaux Dis toi que chaque tableau correspond à un dictionnaire. Tu recherches dans le premier qui va te donner un référence sur le 2ème qui tu vas ouvrir et parcourir à la recherche du mot état pour enfin en lire la définition. Quand est-il lorsque tu dois rechercher dans 4 dictionnaires ? Je donne comme exemple un dictionnaire car la plus part des recherches dans des tableaux sont justement basées sur des recherches "dichotomique" (https://fr.wikipedia.org/wiki/Recherche_dichotomique)

Absolument, bien que optimisé, encoder/décoder du json c'est effectuer de la transformation de chaîne de caractères, c'est donc toujours un peu lent (on parle de micro/nanoseconds). La base de données est capable d'avaler une quantité de données vraiment importante, et si les index sont bien placés, les performances sont juste remarquable, donc inutile d'hésiter àl'exploiter. JSON quant à lui à des limite. Prenons un exemple simple ... la récursivité ( A appel B et B appel A) Résultat : local tableauA, tableauB = {}, {} tableauA["A"] = "Aa" tableauA["B"] = tableauB tableauB["A"] = tableauA tableauB["B"] = "Bb" print( json.encode(tableauA) ) Krakkk boooommmmm [DEBUG] 08:47:18: 2018-11-30 08:47:18.646926 [ fatal] Unknown exception: /usr/share/lua/5.2/json/encode.lua:130: Recursive encoding of value Néanmoins, entre les performances de la HC2 et la base de données. Je dirais que chercher la performance à outrance ne sert à rien. Il vaut mieux simplifier le code pour en optimiser la maintenance. LUA n'étant pas un langage des plus simple à maintenir, je pense que l'effort doit être mis là dessus en priorité. Alors, pour répondre à ta question. Stocker un tableau de JSON n'est, pour moi, pas optimiser en terme de maintenance. La HC2 ne permet pas de "voir" un tableau de JSON, l'écran des VG n'affiche rien de parlant. On est donc obligé de faire un morceau de code pour parcourir le JSON afin d'en connaitre la structure. Le créateur du code, lui, connait la structure car c'est lui qui la mise en place, mais une autre personne qui reprend le code sera un peu perdu au début. Mettre en commentaire la structure pour aider l'utilisateur est fort utile, mais basé sur mes 27 ans de développement, je peux t'assurer que la documentation ne suit JAMAIS les évolutions du code et que seul le code fait office de documentation. C'est bien triste, mais c'est un fait. Voilà, je crois que mon gros pavé te donne mon avis personnel sur la question. La version 6.x de GEA a été écrite dans ce sens. Je n'arrivais plus maintenir les versions précédentes. Je suis donc reparti de 0 pour tout récrire motivé par la sale bête de @pepite. Have fun

Lol, si tes questions sont tordues ... quelles sont celles de @pepite

Le test que j'ai effectué était sur 10'000 itérations, par contre, par défaut, il y a 1'000 dans le script. fibaro:getGlobal(VG) retourne la valeur et la date de dernière modification de la vg. local v, m = fibaro:getGlobal(VG) v = valeur m = LastModificationTime

Au travail, au milieu du bureau, c'est pour voir combien d'air brasse mes collègues. Les résultats sont souvent impressionnant.

Le code, concernant un VirtualDevice, n'a absolument pas changé depuis quelques mois. Je ne mettrais donc pas GEA en cause dans ce cas précis. Par contre le changement de couleur d'un wallplug passe par un http:put et il n'y a aucune garanti quant au délai de prise en compte du changement de couleur. Il se peut aussi que le changement du firmware de la HC2 aie un impact la dessus. GEA ne fonctionnant que toutes les 30s, il ne devrait pas utiliser suffisamment de ressources pour empêcher ta HC2 de faire son travail. En gros, je comprends pas ... mais peut-être que quelqu'un d'autre à une idée ?

Voici une petite scène pour toi : --[[ %% properties %% globals --]] local VG = "Chauffage" local ID_LAST_BREACH = 53 local NB_ITERATION = 1000 -- Affiche dans la console --- function log(name, start) if (start) then fibaro:debug("<span style=\"font-family:monospace; white-space:pre; clear:both; float:right\"> "..name .. " " .. (os.time()-start) .. "s</span>") else fibaro:debug("<span style=\"font-family:monospace; white-space:pre; clear:both; float:right\"> "..name .. "</span>") end end -- Execution des fonctions --- function execute(name, func) if (not pcall(function() local start = os.time() for i= 1,NB_ITERATION do func() end log(name, start) end)) then fibaro:debug("ERROR : " .. name) end end log("Test de performance") log("----------------------------------------------") log("") -- Tests --- execute("getLastBreach :", function() local m = fibaro:getValue(ID_LAST_BREACH, "lastBreached") end) execute("getVG :", function() local v,m = fibaro:getGlobal(VG) end) log("") log("----------------------------------------------") log("ALL DONE") Tu constateras que l'appel à la VG est légèrement plus rapide que de remonter le "lastBreached" d'un module. Test effectué sur 10'000 itérations. [DEBUG] 09:30:13: Test de performance [DEBUG] 09:30:13: ---------------------------------------------- [DEBUG] 09:30:13: [DEBUG] 09:30:45: getLastBreach : 32s [DEBUG] 09:31:14: getVG : 29s [DEBUG] 09:31:14: [DEBUG] 09:31:14: ---------------------------------------------- [DEBUG] 09:31:14: ALL DONE

Pour la 1ère question, c'est délicat. Cette ligne va être exécutée 1 seule fois puis mise en attente jusqu'au prochain changement de ta variable "EtatWeather". Donc quand tu dis qu'elle a du mal à passer, c'est peut-être normal. Il faudrait plus d'info sur ce que tu appels "mal à passer". Pour ta 2ème question, je dirais que la ligne "semble" correcte, hormis que je ne mettrais pas les accolades qui englobent id["DET_PORTE_PARENTS"]. (Pour id["VOLET_PARENT"] si tu n'as qu'un ID les accolades sont facultatives).

J'ai peur qu'il faille y aller par élimination. La 1ère ligne déclenche un scénario 23 et semble la plus complexe. Je te propose dans un premier temps, de la mettre en commentaire et de faire quelques tests. Si le problème persiste ... heuuuu, ben je me jette au lac .

heuuuu

Il y en a qui aime se compliquer la vie . GEA.add(ECT......, 30, "", { {"Virtualdevice", 121, "31"}, {"sleep", 2*60, {"Virtualdevice", 121, "5"}}, {"sleep", 3*60, {"turnOff", 142}} })

Aucune idée. Quelles sont les commandes liées à ta variable "Presence_Cour" ?

C'est pas moi qui est répondu intelligemment, c'est @Lazer

Il y a un exemple de code ici mais c'est pas si simple : http://lua-users.org/wiki/WeekNumberInYear

@Renan Embête toi pas, passe sous Jeedom.

Disons que le soucis est avant tout que j'en ai marre d'entendre de gens venir vanter les mérites de Jeedom (ou d'autres solutions) en décriant Fibaro sur ce même forum. Avant ma HC2, j'utilisais ma Zibase Pro (que j'ai toujours). Mais jamais, je dis bien jamais, il me serait venu l'idée d'aller sur le forum de Zibase pour critiquer leur box et dire que la HC2 est bien mieux. Je me vois mal aller sur leur forum pour leur dire "Ben moi avec ma HC2 je peux faire des scripts et transférer le résultat sur ma Zibase. Comme cela vous aurez un super truc vu que la Zibase est même pas capable de le faire". "Avant j'avais une Renault, maintenant une Telsa, ah ben, si j'allais sur le forum Renault pour dire comment chargé ma Telsa sur l'allume cigare de ma Renault" (Ceci n'est évidement qu'un exemple). Bref, c'est le genre de comportement que je trouve complètement déplacé et qui ne sert absolument à rien. Ici on parle "plugins Fibaro" donc on cherche et s'exprime autour des plugins sur la HC2 ou HCLite ... on s'en fiche des autres box ... il y a même un topic dédié à ces autres box sur ce forum (Ce que je ne comprends même pas hormis si ce n'est pour parler d'intégration de modules Fibaro avec d'autres box). Et étrangement, c'est souvent des utilisateurs Jeedom qui viennent sur ce forum, les autres, on ne les entends pas. C'est un peu comme si les Jeedomiens avaient besoin de se rassurer. Voilà, ce fut mon coup de gueule de la semaine. Et surtout, tu me connais, je ne te vise pas personnellement, c'est juste que ton message fut la goutte d'eau en trop de la journée.

C'est toujours le même débat Le jour où Fibaro fera payer ses plugins (4€ pour le thermostat ou 2€ pour connaitre la température) ont pourra en reparler. On est pas sur le même modèle économique donc pas les même services. Donc pour 0€, je dirais "Merci Fibaro" de nous permettre de connecter facilement notre HC à Netatmo.

Bien sûr que oui ... qui d'autre que toi va tomber sur de nouveaux bugs sinon

Ok, sous jeedom, c'est probablement plus simple, mais cela n'est pas impossible sous HC2, c'est juste plus compliqué. Un petit script et on a toutes les informations nécessaires (batteries inclus) et la possibilité de les mettre à jour. Jeedom ne fait que d'exploiter les API de Netatmo, ce qui est aussi réalisable depuis la HC2.

Pas faux ... je bascule aussi de suite.

Je suis en Beta 4.512 et GEA 6.11 et toi ?

Aucun problème pour moi avec cette simple ligne de test : GEA.add(true, 0, "LED", {"LedBrightness", 100}) Pourrais-tu tester s'il te plaît ?

Si ton tableau est connu et que tu n'as pas besoin de json, les performances sont excellentes comparées à une recherche en base. Et dans ce cas, il n'y a même pas photo. En revanche, si tu dois stocker ton tableau dans une VG avec du json, le gain me semble beaucoup moins significatif.