Cage d'escalier : cohabitation va et vient et détection

[ThierryStrad]

Je suis d'accord avec toi. Surtout qu'une telle latence peut cacher un pb de configuration pouvant avoir d'autres conséquences. Ma charge CPU oscille entre 12 et 16%.

Je ne sais pas quelle est la charge chez les autres possesseurs. Mais, à moins de 80%, ça ne devrait pas expliquer de tels temps de réponses.

Je n'ai constaté aucune différence après l'arrêt redémarrage (avec coupure alimentation) : fait hier APM. J'ai toujours ce temps de latence de 3 secondes (en mode programmation automatique, allumage sur détection de présence).

Mon eedomus pilote :

6 volets roulants.
14 éclairages
8 vannes de radiateur (POPP)
VMC
Un système d'alarme avec plusieurs capteurs de présence, une sirène, capteur ouverture
Un peu moins de 35 règles
Détecte les présents par ping IP smartphone
Envoie requêtes HTTP pour mémoriser les données sur mon NAS.
Est reliée Alexa pour exécuter les consignes vocales

J'ai supprimé la quazi totalité des pollings
J'ai fait une optimisation réseau nocturne.
Je surveille le nombre exécutions de règles et utilise l'option "Autoriser le redéclenchement" afin de ne pas charger le réseau/CPU.

Je ne sais pas comment investiguer, tant sur le réseau que sur la BOX.

Pour moi, c'est soit la BOX soit le réseau qui merdouille : en changeant d'actionneur de lampe ou de capteur de mouvement, le pb reste.

Je ne connais pas d'outils d'investigation sur la box.

=========EDIT =============
Sur la matrice radio, une vanne est en défaut. Je vais l'exclure et la ré-inclure, pour voir ce que ça donne.

[SKL]

Tout a l'air ok en effet...

le plus étrange c'est que ça fonctionne sans latence dans un seul cas.

[ThierryStrad]

Oui, en liaison directe (association), sans passer par l'eedomus.

Ça accable l'eedomus, ou plutôt le paramétrage que j'ai pu faire.

Je ne peux pas repartir de 0 : plein de périphériques sont derrière les mécanismes dans les boitiers encastrés (quand ce n'est pas au plafond)

[SKL]

Non je parlais via la box, portail mobile, sans latence.

[ThierryStrad]

Exact ; pas de latence si :

Association
Accès par appli Android

[SKL]

Tu as monitoré ce qu'il se passe dans le log ? je connais pas assez pour bien interpréter mais il peut y avoir quelque chose d'interessant.

ip_locale-box/log/

[ThierryStrad]

Voici ce que le capture lors d'un allumage par détection de mouvement :
Node 70 => FGS213
Node 71 => Aeotec 6in1

18:12:17.458] <= [01][09][00][04][00][46][03][25][03][FF][6E]
[18:12:17.459] -> [06]
[18:12:17.460] FUNC_ID_APPLICATION_COMMAND_HANDLER on node #70 / COMMAND_CLASS_SWITCH_BINARY (assimilated as a COMMAND_CLASS_BASIC) / BASIC_REPORT
[18:12:17.480] Value=100 for node #70

[18:12:19.802] <= [01][0E][00][04][00][46][08][32][02][21][32][00][00][00][00][98]
[18:12:19.802] -> [06]
[18:12:19.803] FUNC_ID_APPLICATION_COMMAND_HANDLER on node #70 / COMMAND_CLASS_METER / METER_REPORT
[18:12:19.804] Precision is 1, Scale is 2, Size is 2 byte(s), Meter Type is [1], rate is [1], scale is [2], scale2 is [0]
[18:12:19.804] Measured 0 W on node #70
[18:12:19.816] ## DEBUG: Not updating meter, delta: [0]<[5]

[18:12:22.829] <= [01][0C][00][04][00][47][06][31][05][03][0A][00][16][9D]
[18:12:22.837] -> [06]
[18:12:22.838] FUNC_ID_APPLICATION_COMMAND_HANDLER on node #71 / COMMAND_CLASS_SENSOR_MULTILEVEL / SENSOR_MULTILEVEL_REPORT (Type=0x3 / Luminance (v1))
[18:12:22.839] Sensor Type: 3 found on channel #4 for node #71 / SENSOR_MULTILEVEL_REPORT_LUMINANCE_VERSION_1
[18:12:22.839] Size is 2 byte(s)
[18:12:22.839] Value=22 Lux for node #71 channel #4

[18:12:29.759] <= [01][0E][00][04][00][46][08][32][02][21][32][00][91][00][00][09]
[18:12:29.760] -> [06]
[18:12:29.760] FUNC_ID_APPLICATION_COMMAND_HANDLER on node #70 / COMMAND_CLASS_METER / METER_REPORT
[18:12:29.761] Precision is 1, Scale is 2, Size is 2 byte(s), Meter Type is [1], rate is [1], scale is [2], scale2 is [0]
[18:12:29.761] Measured 14.5 W on node #70
[18:12:29.775] Creating request from 'putInOutboxes' [/mnt/flash/puch/outbox/2020.04.18_18.12.29_774079_um1912859.req]

Je ne sais pas trop exploiter ceci

[SKL]

malheureusement moi non plus.

y a-t-il un expert qui pourrait donner une méthode pour faire une mesure précise de latence via le log ?

et voir par la si un élément permettrait d'accélérer le processus.

ce qu'il serait également interessant de faire c'est regarder le log pour un allumage via l'interface web et via le portail mobile.

mais je ne sais pas dans quelle case se trouvent les actions utilisateur...

[ThierryStrad]

Je ferme ce post pour en ouvrir un autre plus abouti sur ce sujet. Merci à toi, SKL, pour ton soutien.

[krystyan]

une autre possibilité serait peut être d'utiliser en association directe un FGS222
canal 1 pour le détecteur canal 2 pour les va et vient
Ainsi les va & vient seraient prioritaires sur le détecteur

[ThierryStrad]

Je ne comprends pas. Le 222 est bien pour 2 charges ? Hors, ici, il n'y a qu'une charge.

Tu veux peut-être parler du 212 (aujourd'hui en concurrence avec le plus récent 213) ?

Je vais explorer cette voie. Comment associer avecl e va et vient ? Les association sont entre périphériques ZWave. Le V&V est filaire.

Je ne comprends pas tout.
=========== EDIT ===============
Ce que j'ai compris :
L'association doit-être faite par le "commandeur" vers le "commandé". Donc on paramètre l'association zwave par le capteur (dans mon cas Aeotec 6in1) pour l'associer au switch (dans mon cas FGS213).

Proposes tu d'associer canal 2 de FGS à canal 1 FGS, afin que le V&V devienne prioritaire ?

[krystyan]

Il s'agit bien du FGS222 utilisé en inverse le IN est raccordé à la lampe O1 et O2 à la phase
S2 à l'arrivée de la phase en provenance du va & vient

[ThierryStrad]

OK => le V&V commande S2. Q2 est rebouclé sur S1. Q1 pilote la lampe ?

Ai-je bien compris ?

[krystyan]

je vais faire un schéma

[ThierryStrad]

Super !! Merci pour le temps consacré ...

Je ne connais pas les priorités entre associations. J'ai compris que c'est cette caractéristique que tu utilises ?

[krystyan]

Il faut associer le détecteur au canal 1

Capture.JPG (25.21 Kio) Consulté 6007 fois

[ThierryStrad]

Bien vu !!
Sur le schéma constructeur du FGS222, IN et L sont reliés :

FGS222.jpg (30.34 Kio) Consulté 6003 fois

Donc, cette liaison est à effectuer par le client par pontage (shunt) ?

Confirmes-tu ?

[ThierryStrad]

Et la génération "2" switch 213 et 223, n'offrent pas cette option. Il n'y a plus IN et L, mais L et L. Je viens de sonner un FGS213. Les deux L sont en court circuit.

Les schémas ne sont pas les mêmes entre switch et switch 2

[krystyan]

Non il n'y a pas d'autre pontage que ceux de mon schéma.
le schéma constructeur est une autre façon d'utiliser le FGS pour gérer distinctement deux charges (ou deux lampes) en connectant celles-ci respectivement sur Q1 et Q2
Dans mon schéma il n'y a qu'une seule charge (ou lampe) qui est connecté sur IN

Il faut bien prendre un FGS222 et pas un FGS223

[ThierryStrad]

Vraiment bien vu !

Je pense que tu m'as donné la solution.

Cela fait des jours que je galère. Je vais acheter un 222 de ce pas.

Merci !!