Temps de latence traitement de règle avec plusieurs actions

[Osiris1979]

Bonsoir,
J'ai créé une règle pour éteindre 4 lampes à partir de l'appui d'un bouton de ma télécommande NODON associée à ma BOX EEDOMUS.
Bien que ma règle fonctionne, je constate un temps de latence relativement long (entre 4 et 5 secondes) pour que l'extinction des 4 lampes soit effective.

J'ai donc plusieurs questions :
1) Est ce que ce temps de latence est normal ?
2) Y a t'il une méthode de programmation plus ingénieuse que la programmation de plusieurs actions en parallèle (voir mon imprime écran ci-dessous) ?

D'avance merci
Thierry

[DomoCro]

Je ne sais pas si c'est normal (encore que j'aie tendance à considérer que les questions qui commencent par "est-ce-que c'est normal" contiennent déjà la réponse) mais en tout cas c'est assez courant.

Je rencontre ce problème pour des actions que je déclenche avec un "Button" Fibaro. (C'est peut-être aussi le cas de ton "Interrupteur central chambre ?)

Je n'ai pas trouvé de solution pour raccourcir le délai, mais comme mon souci principal était de savoir si ma demande avait bien été prise en compte, j'ai utilisé la synthèse vocale pour énoncer l'action à accomplir.

Parce que, curieusement, la diffusion de l'annonce est toujours quasi immédiate (moins d'une seconde) alors que les allumages et extinctions commandés peuvent s'échelonner sur plusieurs secondes...

Au final, je me suis habitué à cette façon de faire, pas très orthodoxe, mais qui me convient... faute de mieux.

[Osiris1979]

Bonjour Domocro,

Merci pour ta réponse et oui effectivement ma commande est réalisée par un Button de chez FIBARO.

J'ai un peu avancé "empiriquement" sur le sujet. Je pense que le "problème" ne vient pas des règles contenant plusieurs actions. En effet, je me suis "amusé" à remplacer les actionneurs de type Interrupteur Zwave par 3 actionneurs RTS volets roulants somfy (que je pilote par un émetteur/récepteur dongle RFPlayer connecté à la BOX). Et pour le coup, je n'observe pas de temps de latence.

Euh Ok maintenant que je sais çà, tu me diras ca ne résout pas le problème initial du temps de lantence de l'éclairage. Il faut sans doute que je me penche sur le protocole zwave pour avoir une pseudo réponse (mais est ce vraiment nécessaire au final ? )

[influman]

exclure et réinclure le bouton, regarder la matrice radio...

[DomoCro]

Je ne pense pas que le bouton y soit pour grand chose car, et c'est pour ça que j'utilise une notification vocale, l'action sur le bouton est bien détectée immédiatement.

C'est ensuite que les commandes d'éclairage mettent "un certain temps" à s'exécuter, et dans un ordre aussi variable qu'approximatif... (Ces éclairages sont commandés par trois prises Fibaro et un contrôleur RGBW Qubino)

[stef31]

Si tu as beaucoup d'actionneurs avec des pollings, tu peux commencer par supprimer les pollings. Cela va faire en sorte que ton réseau Z-WAVE soit moins encombré et donc que les communications soient un peu plus rapides.

[ericl]

J'ai l'impression que l'eedomus traite les commandes séquentiellement et avec pour chaque commande l'attente du retour du module (c'est le principe du zwave).
Du coup je ne pense pas que ce temps de latence puisse être supprimé (sauf si bien sûr le soucis vient du maillage zwave) ?

[rover820i]

J'ai l'impression que l'eedomus traite les commandes séquentiellement et avec pour chaque commande l'attente du retour du module (c'est le principe du zwave).
Du coup je ne pense pas que ce temps de latence puisse être supprimé (sauf si bien sûr le soucis vient du maillage zwave) ?

Il faudrait peut-être faire l'essai en dupliquant chaque règle en fonction du nombre d'actions à effectuer... les actions se feraient peut-être en parallèle et non en séquentiel... à tester, sans garantie. Mais ça risque de surcharger la box sur les règles avec un grand nombre d'actions.

[stef31]

Le protocole Z-WAVE fonctionne avec un acquittement donc chaque émetteur attend la réponse du récepteur avant d'émettre. Mais les échanges sont quand même rapide, moins d'une seconde. Par contre, s'il y a trop de traffic, il y a des collisions dans les échanges et cela fait un peu du n'importe quoi. Comme un actionneur qui va s'activer alors qu'aucune instruction ne lui a été envoyé.
C'est d'ailleurs curieux de rencontrer ce type de problème avec un tel protocole.