Tuto HC2 Mise À Jour Rapide Des Virtual Devices Mais Faible Charge Sur La Hc2

[Sakkhho]

Qu'entends tu par différence de résolution ?

je suis en 4.056

[sebcbien]

Ok toi c'est sur une heure... Moi c par minute, j'ai rien dit ;-)

Sent from my Note4

[Sakkhho]

oui 1h car sur 1minute on voit pas grand chose :-)

[sebcbien]

Voici chez moi sur 1/2h...

 

no comments...

 

[Sakkhho]

pas mal du tout, 

je vais essayer de décaler les actions dans GEA systématiques (celle qui n'ont pas de conditions de temps ou de variables)

 

est ce que les requetes sur des API exterieures peuvent aussi charger la barque ?

Car recemment j'ai rajouter WAZE, et SNCF, en + de WU que j'avais avant

[sebcbien]

Perso j'en fais quand même quelques une (2 vd météo, 3 devices netatmo-2 thermostats et 1 station météo avec 3 modules additionnels, 3 modules netatmo de fibaro, des push vers thingspeak et emoncms, 5 caméras IP, mon nas synology, 2 eco devices, ma vmc, mon ampli, xbmc etc...)

Donc je dirais normalement pas plus que d'autres...

Sent from my Note4

[sebcbien]

et voici sur +- 2h

 

[Steven]

Un petit commentaire sur GEA. Contrairement à  ce que l'on peux penser, en terme de mémoire, GEA est mieux adapté dans certain cas. Je m'explique :

 

GEA effectuer toutes les x secondes un traitement et un seul à  la fois donc on est sà»r de ne pas avoir 5 traitements différents en simultané. En gros, si on est pas trop gourmand, GEA pourrait être un atout (bien que cela n'a jamais été le but).

 

Maintenant, la facilité de GEA fait qu'on a tendance a répété les opérations trop fréquemment pour rien (j'en fais parti). Exemple rafraîchir un VD toutes les 30 secondes alors  qu'il ne travaille que toutes les heures. Je suis même persuadé que la plus part d'entre nous rafraîchisse des informations même quand ils dorment alors que cela ne sert à  rien.

 

Un point interréssant de GEA comparer à  la plus par des scénario que j'ai vu. C'est que GEA vérifie l'heure en priorité .. exemple : 

GEA.add({"Value-", id["TEMPERATURE"], 21}, 10*60, "", {{"turnOff", id["VMC_DOUBLE_FLUX"]},{"Time","23:00","06:00"}})

GEA va vérifier la valeur de température UNIQUEMENT si c'est entre 23:00 et 06:00 alors que la plus part des scénarios vérifie les 2 puis effectue l'action. 

 

C'est pas énorme mais cela aide à  diminuer les appels qui peuvent être groumant.

 

Voilà  .. mais .. GEA est une usine qui fait tout plus ou moins bien .. .GEA ne vaudra jamais un code écrit spécifiquement pour un traitement précis. Donc si vous avez le possibilité d'écrire vos propres scénarios cela sera toujours plus optimisé que GEA pour autant que vous fassiez attention.

 

Cordialement.

[Sakkhho]

Steven. Décaler de quelques secondes (par exemples mettre1 action toutes les 60s et une autre toutes les 65s au lieu des 2 toutes les 60s) les actions GEA ne sert donc à(presque rien) ?

[sebcbien]

Bien sur le "scheduler" de gea lui même est très optimisé et on peut définir des plages horaires d'utilisations, je ne remets pas ça en question.

le "problème" c'est qu'avec gea, toute les action prévues sont déclencées toutes pile en mème temps, il n'y a pas de "glissement".

Que ce soit toutes les 30s,60s ou 5 min, si je schedule avec gea le déclenchement de 3 devices toutes les 5 min, les 3 seront toujours lancés pile en même temps (ou àquelques ms d'intervalle)

idem pour les vd devant être déclenchés toutes les minutes..

Et là, (dépendant des VD bien sûr), la charge peut être lourde pour la DB et la box

[sebcbien]

4.058 beta... on va rigoler... :-/

 

Other improvements:

- Due to multiple requests we introduced mechanism of limiting number of single scene instances running simultaneously. Maximum number is 10 instances active at the same time. It is available in all types of scenes. In case of exceeding given number the additional scene will not be started and proper notification will appear in Notification center. Remember, that all block and magic scenes based on time have always once instance running in loop, so if there is only single instance allowed, clicking "Run" button will have no effect. 

- In case of exceeding 95% of RAM's "used space", no new scenes will be triggered until that value drops again

[BenjyNet]

Alors làles amateurs de GEA, on risque de rigoler effectivement

[sebcbien]

gea ne demande qu'une seule instance je crois.

Et une nouvelle instance est lancée pour les trigger en instantané.

Rien de bien méchant car l'instance "instantanée" ne dure que quelques ms...

[Lazer]

Normalement, peu de risques d'avoir plus de 10 instances simultanées d'une même scène.... sauf scène codée avec les pieds.

[Lazer]

en fait j'ai quand même un doute sur la compréhension..... j'espère que la limitation c'est 10 instances d'une même scène, et pas 10 scènes différentes, auquel cas on est mal.

[BenjyNet]

Ouais c'est pas clair, au départ j'avais compris ta 2eme proposition (10 scenes différentes) puis après réflexion je me dis que non, c'est pas possible leur truc sinon c'est mort !

[sebcbien]

J'ai eu le même doute que vous...

Leur anglais est vraiment très approximatif...

Sent from my Note4

[Sakkhho]

Bon j'ai laissé tourné le diagnostique et c'était pas beau du tout ...

j'ai désactivé GEA pour voir la différence.

 

Edit : bon comportement bizarre, flat pendant 3-4minutes, puis saturation à  100% pendant 15s, et retour à  0% ...

Edit2 : bon j'ai tout rallumé à  fond :-) , redémarrage de la box, aucun pic à  100% depuis 5mn ... RAM à  71%libre + 10% de cache... 

j'arrête de me prendre la tete :-)

[Steven]

Je vois même pas comment on pourrais avoir 10 instances d'une même scène en simultané. Sauf cas annoncé par Lazer .. le codage par les pieds.

[Steven]

Je me permet de donner mon avis sur tout cela.

 

A ce jour, 2015, on a des systèmes fiables et robustes. Et j'ai peur qu'on se prenne la tête pour pas grand chose.

 

N'importe quel ordinateur sur n'importe quel système d'exploitation est capable d'absorbé 10'000'000'000 traitements en séquentiel (un après l'autre). Par contre ce qui est plus dur à  prévoir se sont les traitements en parallèle (en même temps).

 

GEA ne peux pas être remise en compte, sa conception et surtout son utilisation ne mettra pas votre box à  coin, cela n'est pas possible.

 

Ce qui est dangereux ce sont les requêtes HTTP externes (GEA ne gère pas cela), les requêtes HTTP que vous faites sont clairement coà»teuses .. pourquoi ?

 

A chaque requête HTTP déclenchée, le système doit lancé un traitement qui va attendre la réponse, si la réponse arrive, il effectue son traitement puis termine sa tache. Si votre requête ne répond pas ou met trop de temps, cette tâche reste active quelque secondes avant de s'arrêter. Imaginons que cette tâche reste active plus de 3 secondes et que vous faite une requête toutes les 3 secondes ... Aiiiieeeee, cela s'empile jusqu'à  l'explosion si la gestion de tout cela n'est pas 100% parfaite.

 

Donc si vous voulez ne pas perdre trop de temps et que vous souhaitez optimiser votre box, concentrer vous sur les requêtes externes à  votre box. La base de données et le système interne est de la bombe et ne risque pas grand chose.

 

[Steven]

Je suis passé en 4.058 .. il me dit que "GEA" et "CabronKarotz" ont trop d'instances. Voici donc les déclencheurs de ma scène "CabronKarotz" :

--[[
%% autostart
%% properties
%% globals
--]]

et GEA qui le lance :

  GEA.add( true , 5*60, "", {
      {"Scenario", 6}, {"Repeat"}
  })

Donc ma scène CarbonKarotz a un maximum possible de 2 instances toutes les 5 minutes pour une durée de 2ms (j'ai vérifié le debug).

[DEBUG] 09:31:50: 63/37
[DEBUG] 09:36:50: 63/37
[DEBUG] 09:41:50: 63/37
[DEBUG] 09:46:50: 63/37
[DEBUG] 09:51:50: 63/37
[DEBUG] 09:56:50: 67/33
[DEBUG] 10:01:50: 67/33

Encore un grand bravo pour Fibaro, ils ont trouvé un moyen de faire peur aux utilisateurs et de se déchargé en cas de "soucis".

 

 

EDIT :

 

ATTENTION, il y a une nouvelle option sur les scènes :  Je retarde j'ai pas suivis l'évolution de cette version.

[sebcbien]

Bien sur le "scheduler" de gea lui même est très optimisé et on peut définir des plages horaires d'utilisations, je ne remets pas ça en question.

le "problème" c'est qu'avec gea, toute les action prévues sont déclencées toutes pile en mème temps, il n'y a pas de "glissement".

Que ce soit toutes les 30s,60s ou 5 min, si je schedule avec gea le déclenchement de 3 devices toutes les 5 min, les 3 seront toujours lancés pile en même temps (ou à  quelques ms d'intervalle)

idem pour les vd devant être déclenchés toutes les minutes..

Et là , (dépendant des VD bien sà»r), la charge peut être lourde pour la DB et la box

Salut Steven,

Je suis tout à  fait d'accord avec toi.

Je voudrais juste préciser ceci par rapport à  mon commentaire ci-dessus:

Ce n'est pas les lignes gea simples, checks etc en tout genre dont je veut parler, mais plutôt du déclenchement de "gros" VD, systématiquement et sans conditions, celles que l'on met ici:

  GEA.add(true, 2*60, "",{
      {"VirtualDevice", id["VD_THERMOSTAT"], "1"},
      {"Repeat"}
    }) 

  GEA.add(true, 1*60, "",{
      {"VirtualDevice", id["VD_STATISTIQUES"], "1"},
      {"VirtualDevice", id["VD_VMC"], "1"},
      {"VirtualDevice", id["VD_NETATMO"], "1"},
      {"Repeat"}
    }) 

Exemple de "gros" vd chez moi:

- VMC - mon module va lire l'état de ma vmc en http, récupère les données et les pousse vers emoncms

- Thermostat: idem mais avec netatmo, va lire 3 devices en http et pousse les résultats vers emoncms

- Eco devices, idem

etc

etc.

 

Ce n'est donc pas gea le problème, mais les autre gros virtual devices, qui chargent la box ET qui vont être tous lancés pile en même temps, chargeant la box encore plus que s'ils étaient lancés séparément.

Donc perso, j'ai arrêté d'utiliser gea comme "bête scheduler" et j'utilise le main loop des vd en y insérant un timing qui permet un "glissement" des horaires de déclenchement

[Steven]

J'approuve et on se rejoint sur le soucis des requêtes HTTP.

[pepite]

La meme messieurs, mais j ose pas passer en 4.58 ;-)