Tuto HC2 Gea : Gestionnaire D'événements Automatique

[Steven]

Merci pour ton retour

Oui, une fois les conditions remplies, on interroge le périphérique concerné pour connaître sont état. Ceci en moyenne toute les 30 secondes. A cette fréquence, on est loin d'un Polling

Pour éviter de trop faire appel au Z-Wave, les conditions calculable sont traitées en priorité (heure, jours, variable globale,...)

Ta mise en garde est plus que judicieuse, comme d'habitude, mais je pense sérieusement qu'on est volontairement très loin d'un Polling qui pourrait chatouiller le réseau Z-Wave.

Je reste toujours disponible àla critique surtout si cela vient de toi

Envoyé de mon GT-I9192 en utilisant Tapatalk

[Krikroff]

Oui je comprends bien ton raisonnement mais 30 secondes ou bien 300 secondes, peu importe en Z-Wave cela reste du Polling (action consistant à  interroger un périphérique Z-Wave), il n'est pas rare d'ailleurs de fixer le Polling d'un périphérique à  plusieurs minutes. Le Z-Wave est un réseau un peu particulier avec mine de rien pas mal de limites (qui tendent a s’effacer avec le Z-Wave+ ).
 
La bonne pratique voudrais que l'interrogation des nÅ“uds se fasse en file d'attente et espacé d'un temps déterminé en Idle avant l'interrogation suivante et cela justement pour éviter les phénomènes de surcharge du réseau Z-Wave. Après je ne sais pas comment le HC2 traite en back-end les interrogations des périphériques en LUA mais ce qui est certain c'est que le Polling peut avoir des conséquence très désagréable: en gros plus il y a de trame et plus il y a de trames d'erreurs c'est comme ça ! Je passe aussi sur le fait que l'interrogation doit rentrer en concurrence avec le contrôleur (HC2) avec pour conséquence un allongement du délai de traitement
 
Ce qu'il faut retenir c'est que plus il y a de périphériques Z-Wave dans le réseau et plus le Polling doit être espacé, le type et l' implémentation Z-Wave des périphériques est aussi déterminant dans le choix de cette fréquence. cf. le HC2 sur la page configuration du réseau Z-Wave: Fibaro fait des recommandations en fonction du nombre de périphériques. Aussi Par exemple sur un réseau de taille moyenne le HC2 peut mettre jusqu' à  20 minutes pour faire un Polling complet.
 
Tiens je viens de trouver ça sur le site eedomus, et cela va dans le sens de mes propos:
 

- Le réglage du polling nécessite donc de prendre en compte ses paramètres tout en cherchant à  le limiter au maximum. En effet le polling génère du traffic Z-Wave qui peut avoir un effet négatif sur la qualité de votre réseau.
- Un polling défini à  30 secondes sur 20 périphériques va engendrer un important traffic de fond qui laissera moins de place aux commandes sur les actionneurs ou à  la remontée des données de vos capteurs sur piles.
- De même, un polling inutile sur un périphérique difficilement joignable voire absent va engendrer des tentatives de dialogue inutiles qui peuvent avoir un effet négatif sur votre réseau.
- Un polling trop fréquent peu conduire à  des ralentissements, voire une saturation de votre réseau Z-Wave.

 
Bon allé j'arrête de vous prendre la tête avec ça, tant que ça marche et que vous n'observez pas de comportement étrange (en plus des bugs déjà  existant ) tout va bien.

 

[Shyrka973]

Je suppose que vous discutez du polling avec les modules alimentés par le courant: dimmer, prise électrique, ...

Pour les autres, les valeurs retournées sont les dernières connue par le HC2.

Envoyé de mon iPad àl'aide de Tapatalk

[Krikroff]

Oui c'est ça tout a fait cela concerne les périphériques alimentés .

[Steven]

Je me permet de revenir vite sur ce sujet.

 

On est d'accord   

Le polling est un manière d'interroger, à  intervalle régulier, un périphérique pour connaitre son état. 

Le polling est par la HC2 qui à  chaque interrogation va stocker les valeurs du périphérique dans sa base. 

Il s'agit du fameux paramètre : Délai entre chaque interrogation qui dans 99% des cas est à  0 (pas de polling). 

 

On est pas d'accord   

GEA ne modifie pas ce polling ... GEA interroge à  intervalle régulier la base de données de la HC2. Lorsque nous interrogeons la valeur d'un périphérique en LUA (fibaro:getValue(...)) nous interrogeons la HC2 pour qu'elle nous donne la dernière valeur qu'elle a dans sa base. Nous ne provoquons (normalement) aucun appel z-wave.

 

Donc la mise en garde contre le polling est judicieuse, mais elle n'a rien à  voir avec les scénarios est les scripts. A moins que l'implémentation du getValue sur la HC2 soit de très très mauvaise facture, ce que je doute vu les performances de cette dernière.

 

 

De plus, quand nous regardons le code généré par un scénario en mode bloc,

 

Condition : Si la lampe est allumé et que nous sommes lundi 9:54 alors...

on voit que le code généré vérifie l'état de la lampe toutes les minutes tous les jours .. soit 10079 interrogations inutiles

 

GEA ne vérifie la lampe que si nous sommes lundi à  9:54.

 

 

Krikroff ... Il est important que tu me confirmes cela sinon je modifie mon code pour ne plus faire de getValue().

[Krikroff]

Il n'y a pas de soucis Steven, il ne peut ressortir que de bonnes choses de tout cela .

 

Le paramètre : Délai entre chaque interrogation qui dans 99% des cas est à  0 équivaut à  "Polling gérer par le HC2" c'est pas pareil.

 

Pour le reste je suis d'accord avec toi et je vais essayer d'obtenir des informations précises sur les points judicieux que tu soulèves  , ce que je suis sur c'est qu'au début du HC2 le getValue interrogeait le périphérique, je l'utilisait pour faire remonter l'état d'un Dimmer AeonLab avec mesure d'energie associé à  un contrôleur secondaire (une telco) parce-que l’état ne remontait pas instantanément au HC2. Cela à  peut-être changé et cela serait pertinent.

 

ET ... ravi de nos échanges constructifs!

[fredo]

@krikroff

t'as de la chance d'avoir des échanges constructifs avec Steven... moi j'attends la rencontre avec ce monsieur pour échange de baffes ! 

[Moicphil]

Frédo, je dois rencontrer Steven Mercredi prochain...Si tu veux je lui en met une de ta part ? 

[fredo]

@Moicphil,

oui, on fait comme ça.

Donne lui une baffe, je te la rendrai ! 

...tu le rencontres dans quel coin?

[Moicphil]

Pas convenu encore de l'endroit, mais ça sera vers les montagnes, je suis en Haute -Savoie la semaine prochaine...

[fredo]

rooooh la chance !!!

j'aimerais bien venir.

[Moicphil]

Ben viens ! 

[Krikroff]

Voici les nouvelles, donc tu as parfaitement raison Steven, le getValue interroge uniquement la base du HC2 et ne n'interroge pas ou plus le périphérique donc PAS DE POLLING   d'ailleurs il n'existe pas ou plus de moyen à  ce jour pour faire un poll en lua

[Lazer]

"tu as parfaitement raison Steven" => Ca t'en bouche un coin Fredo

 

@Krikroff & Steven : Merci pour cet échange, et cette recherche instructive

[fredo]

@Lazer

bah ouais, Steven a l'esprit tordu mais il n'est pas si bête que ça !

Et moi, je n'y comprends rien à  ce qu'ils racontent... enfin si, parce que du GetEvent, HdlEvent, PutEvent et autres, j'en ai bouffé pas mal quand je faisais de la programmation évènementielle sur 68HC711.

C'est juste que je ne me suis pas encore mis au GEA, mais j'ai hâte (d'autres choses à  régler d'urgence, tu sais lesquelles !  )

Donc en attendant, je suis rageur car je n'exploite pas vraiment le HC2 (à  part allumer ma lampe du salon).

Je n'ai pas de scénario pour des automatismes, faut que je m'y mette rapidement.

Si tu viens avec nous le 20/09, on s'occupera de notre ami Steven 

[Lazer]

Le 20/09, c'est pas gagné... si c'est toujours à  l'autre bout de la France.

 

En ce moment je traine à  Clermont-Ferrand, mais d'après la carte des membres, c'est en plein désert domotique.

 

Pour la HC2, commence avec des blocs graphiques pour faire te faire la main sur quelques scénarios basiques, plus ou moins utile (j'ai géré tout mon chauffage avec ça l'hiver dernier quand même).

[Steven]

@Krikroff

Merci beaucoup, tu me rassure.

@Lazer

Merci d'avoir choisi mon camp contre le méchant fredo.

@fredo

Nah Nah Nah Ner

... Mode Dodo ON...

[PITP2]

Je suis entrain d'essayer d'utiliser GEA.

J'ai copié tout le script et j'ai modifié la première partie ainsi

 

--[[
%% autostart
%% properties
40 valueSensor
40 value
%% globals
--]]

 

 

40 étant une prise electrique (aeon labs) avec prise en compte de la consommation

 

après le dernier end du script collé dans la scene , j'ai ajouté uniquement cette ligne de code

 

GEA.add({"Sensor-", 40, 80}, 1*60, "Consommation #value# inférieur à  80W depuis 1 minute", {{"turnOff",40}})

 

 

mais cela ne coupe pas ma prise ... rien ne se passe .... dois je ajouter d'autres lignes ?

[HANSOLO]

Le fait de déclarer un id dans l'entête sert pour un déclenchement immédiat (-1 dans la zone de test d'une ligne GEA.add)

 

Dans ton cas, pas besoin comme tu test si la conso est <80w plus d'une minute.

 

Pour moi la syntaxe est bonne, essaye en supprimant les deux lignes pour l'id 40 dans l'entête.

[PITP2]

si je comprends bien le parametre 

 

1. %% autostart

 

fait qu'à  l'enregistrement de la scene celle ci se lance toute les 30 secondes automatiquement ?

 

je n'ai pas ajouté cette ligne à  mon code

1. GEA.checkEvery = 30 -- On vérifie toutes les X secondes

 

Puisque pour moi c'est déjà  dans le code principal

 

PS j'ai supprimé les lignes avec les 40 mais cela ne change rien.

[PITP2]

j'ai trouvé je n'avais pas mis le 

GEA.run()

à  la fin ... la honte 

[HANSOLO]

Ben oui, si tu ne copie pas tout le code àSteven .....

[Moicphil]

@Moicphil,

oui, on fait comme ça.

Donne lui une baffe, je te la rendrai ! 

...tu le rencontres dans quel coin?

 

Ca y est Frédo... et il a pas bronché !

[fredo]

@moicphil

Une bonne chose de faite !!! 

Il tendra l'autre joue en septembre 

Merci 

[Steven]

Oh oui, oh oui

Envoyé de mon GT-I9192 en utilisant Tapatalk