système avec latences aléatoires , quelles solutions ?

[jluc2808]

bonjour,

 

j'ai une HC3 ( avec une HC3L indépendante juste pour la partie du côté piscine  elle est donc anecdotique, puisque avec 3 modules isolés sur la HC3L, donc dans mon propos je vais volontairement oublier cette partie) avec 110 dispositifs et 195 scénarios.

la maison est à 3 niveaux de environs 120m² chacun.

 

Tous les modules installés sont des fibaro.

 

L'installation est composée :

- des interrupteurs walli controller en filaire 24v alimentés par un transformateur 24v répartis sur toute la maison (pas de 230v dans les interrupteurs, mais un ancien 2 fils BUS SCS legrand)

- les modules actionneurs FGS223 pour les lumières, FGR223 pour les BSO et FGD212 pour les lumières variables regroupés dans le tableau électrique au sous-sol (tous les anciens retours lampes et anciens BSO arrivent là)

- les walli shutter + walli dimmer + walli switch sont regroupés au niveau R+1 dans 1 seule pièce. 
- la box fibaro HC3 est dans le même local au R+1 que les walli shutter/switch/dimmer (parce que c'est l'endroit qui a été créé et dédié aux raccordements technique -  tableau secondaire, arrivée des prises Ethernet, onduleur, modules directement sur HomeAssistant, .... -  au moment des travaux de rénovation) 

 

Lorsque cela a été possible (1 seul interrupteur pour 1 seule lumière) j'ai privilégié l'association directe zwave plutôt que les scènes.

 

j'ai aussi énormément de scénarios pour mettre à jour les walli controller en fonction de la lumière qu'ils commandes (vert quand allumé et blanc quand éteint).

 

j'en arrive à mon propos :

 

- tous les modules fonctionnent individuellement et tous les interrupteurs actionnent les lampes ou BSO individuellement , lors de mes différents tests sans problèmes particuliers, s'ils sont testés unitairement ou après plusieurs actions sur les même dispositifs 

- par contre de manière aléatoire et significative, dans l'usage quotidien on se retrouve avec des latences significatives relativement importantes pour perturber les utilisateurs. ceci sur les BSO ou sur les lumières ON/OFF ou sur les lumières variables, principalement lorsque l'on utilise les interrupteurs.

- Cette situation peut aller jusqu'à bloquer une action (mouvement d'un BSO ou allumage / extinction d'une lumière pendant plus de 30 secondes voire 1 minutes) même en utilisant Yubii ou directement l'application HC3.

 

comme actuellement tout ce monde est piloté par la même HC3 et que je n'arrive pas à stabiliser le système pour supprimer les latences je me posais la question d'une évolution de la configuration pour remédier à cela ?

 

solution ?  :

1 -  ajouter plusieurs HC3 ou HC3L pour répartir les charges sur plusieurs réseaux zwave en mettant les HC3(L) par étage.  (HC3L ou HC3 si plus de 40 dispositifs)

 

ce qui me retient ou me fait poster pour avoir votre avis c'est que tous les modules actionneurs sont actuellement au sous-sol R-1 dans un tableau dédié (modules montés en rail DIN avec eufix) parce tous les retours lampes arrivent là et il est inenvisageable de les déplacer pour les mettre ailleurs. 

De ce fait tous les interrupteurs du R+1 (ou RDC dans une moindre mesure) ne seraient plus relayés par le maillage zwave du RDC pour discuter avec les actionneurs qui resteront au R-1.

Idem pour actionneurs des lumières externes qui sont aussi au R-1 et sont relayés par maillage divers sur la HC3 du R+1.

 

2 - mettre les HC3L en esclave ou les laisser chaque box indépendantes sachant que si je dois mettre en place des scénarios qui mobilisent plusieurs HC3(L) ceux-ci peuvent être mis dans mon HomeAssistant qui me sert d'hyperviseur et interface utilisateur. Sachant que ma dernière expérience avec une HC3L esclave m'a causé pas mal de souci - blocage complet de la HC3L et impossible à solutionner sans un reset usine et des modules fantômes qui trainent toujours dans ma  HC3 ex-maitre sans pouvoir les supprimer.

 

merci de vos avis et commentaires sur l'existant et les solutions pour le faire évoluer

ci-jointe la couverture zwave

 

 

 

Modifié le 13 septembre 2023 par jluc2808

[Lazer]

J'ai lu en diagonale... désolé, trop long 

 

On ne va pas se plaindre que tu as bien pris le temps de détailler, ça change des questions qu'on voit parfois genre "ça marche pas" sans info.

Mais ton titre est parlant en fait.
Des latences sur un réseau Z-Wave, surtout avec beaucoup de modules comme le tiens, ça ressemble à un réseau surchargé.

Il faudrait faire une analyses des trames pour voir le nombre de messages à la seconde...

Sur HC2 il y avait une super scène, mais elle n'a pas été portée sur HC3 (voire forum officiel)... du coup si tu as motivé il faut utiliser Zsniffer avec une clé Aeotec... voir forum officiel, je crois bien qu'il y a un topic ou 2 à ce sujet ici même aussi.

 

Quelques pistes :

- augmenter l'intervalle de polling, voire le désactiver complètement => facile

- identifier le ou les quelques modules trop bavard et les calmer (exemple : augmenter l'intervalle de relevé de conso des Wall Plugs, etc) => mais pour ça il te faudra un outil d'analyse.

[jluc2808]

Merci @lazer pour ces pistes, pour l'instant mon interval de polling est de 440s (ce qui est préconisé par la plateforme avec 110 modules) ==> à quelle valeur faut-il que je le mette ?

je n'ai qu'un seul wall Plug dans la plateforme , donc je ne pense pas que ce soit lui qui genère le traffic , d'autant que ces latences existaient avant que je ne le rajoute

 

la quasi totalité de mes modules et inter ont dans avancé :  appareil exclu exclus de l'interrogation

 

je vais voir pour la clé aeotec ? quand tu dis le forum officiel tu parles de quel forum ?

 

et la solution de mettre d'autres box ?

Modifié le 13 septembre 2023 par jluc2808

[Lazer]

Je ne sais pas quelle valeur de polling mettre, car je ne suis jamais allé au delà de tant de modules.
Mais si la quasi totalité de tes modules sont exclus du polling, alors cela n'aura aucun impact, donc fausse piste.

 

J'ai pris le Wall Plug pour exemple car c'est ce qui m'est arrivé chez moi, mais ça peut être n'importe quel module.
Et même si ce n'est pas un module en particulier, ça peut aussi être l'ensemble des modules qui sont juste un peu trop bavards.... car mine de rien, 110 modules sur le même réseau Z-Wave, ça commence à faire du monde.

 

Il va te falloir creuser la question...

 

Voir ici pour Zniffer :

https://forum.fibaro.com/topic/29923-tutorial-z-wave-diagnostics-with-pc-controller-and-zniffer/

 

Ou ici :

 

 

 

Quant à mettre une autre box, si les box Fibaro n'arrivent pas à gérer ton réseau, je vois pas bien quelle autre box pourrait y arriver.... à part toutes les tester et choisir la meilleure.

[jluc2808]

Quand je parle de mettre une autre box, c'est pas remplacer celle existante, mais ajouter 1 hc3l et 1 hc3 pour couper le réseau en 3 et alléger chaque box avec 1/3 des composants. 

 

Sachant que les scénarios interbox se feront via mon ha ou en utilisant la fonction esclave des box ajoutées (solution maître esclave dont je ne suis pas fan) 

[Lazer]

Ah oui d'accord.... donc tu as le choix du faignant d'ajouter une box, ou bien le choix du courageux d'essayer de comprendre ce qui se passe sur ton réseau pour l'optimiser

 

[jluc2808]

alors prenons le point du vue courageux, plusieurs choses me tracassent : 

1 - j'ai commencé à regarder la solution sniffer zwave et je t'avoue être un peu perdu , parce que je n'ai pas compris si la solution étaient materiel (avec zwave.me)  ou logiciel avec un pc ou même les 2 et comment tout cela communique avec la HC3 , sur ce point je ne suis pas à l'aise 

2 - imaginons que je passe un peu plus de temps et que le point 1 soit maitrisé, ce que j'ai vu c'est que le sniffer te donne une tétrachiée de trame / log et du détail qui doit être interprété, la aussi je ne me sens pas à l'aise pour me plonger dans les trame et protocoles zwave 

3 - imaginons que j'y arrive et que le point 2 soit acquis, il va falloir que je cherche une aiguille dans une botte de foin, je ne suis pas sur place pour voir ce qui se passe, constater les moments ou actions qui provoquent des latences, donc savoir dans la masse de trame ou, quoi, et quand chercher et je ne peux rester chez les clients en permanence, sachant que quand je teste, le fait même de tester provoque un comportement qui n'est plus aléatoire et ne me permet pas de constater ces problèmes diffus, présents, aléatoires dans le temps et dans l'espace. 

4 - je réfléchis déjà à la suite: 

- déplacer les modules actionneurs du tableau pour les répartir ailleurs me sera impossible 

- déplacer les interrupteurs , la aussi impossible ou relier les inter aux modules actionneurs impossible 

- me reste simplifier les actions sur appuis interrupteurs

1. enlever les changements de couleur par exemple ==> j'ai déjà discuté avec le client, là j'ai un refus de Mme qui est encore plus problématique que le déplacement des modules 
2. simplifier le fonctionnement des BSO ==> la réponse de fibaro pour lequel j'avais ouvert un ticket a été strictement la même plusieurs fois - seule la gestion par scénario est possible avec ma config (bouton en 24v et actionneur en 230v sans lien physique entre eux) 
3. transposer tous les automatismes de groupe sur les lumières et BSO dans home assistant plutôt que dans Home center ==> c'est déjà partiellement fait, mais je peux aller plus avant 

 

donc pour reprendre ton propos,  la solution fainéante, si toutefois elle peut régler le problème des latences, ce dont je ne suis pas certains et qui fait l'objet de mes interrogations

1. le démaillage va t il être pire que mieux 
2. mettre les box en slave ou les laisser indépendante 
3. le boulot de tout défaire et tout reprendre

 

 

 

[Lazer]

Oui en effet, on n'est pas certain qu'ajouter une autre box sollutionne le problème.... tout comme tu n'es pas certain d'arriver à quelque chose avec Zniffer.

Pour te répondre simplement, de ce que j'ai compris du principe (puisque jamais mis en place) : c'est hard + soft

Il faut inclure une clé USB en mode contrôleur secondaire dans le même réseau, ce qui lui permet de voir tout ce qui se passe.

Le soft installé sur le PC où est branché la clé permet d'analyser les trames.
Avant de se lancer dans une analyse des trames, peut être que tu arriveras à identifier un (ou plusieurs) device particulièrement bavard.... c'est en tout cas ce que je soupçonne, car c'est le problème que j'avais rencontré avec un WP.

Mais peut être que ton problème est tout autre, et alors l'analyse sera plus complexe...

 

Y'a pas de solution miracle à ce stade :/

[Nico]

C'est étonnant tout de même, sur ma HC2 principale j'ai 116 modules en ce moment et sur la HC2 en slave dans le pool house 21 modules. Je n'ai aucune latence hormis au boot, il faut 1-2 minutes pour que tout se remette en route proprement. Mais sinon après, c'est ultra fluide.

Juste pour essayer, tu as coupé tous ces scénarios et regardé le résultat ? Si cela règle le souci, cela pousserai plus vers cette partie, et là peut être une simple mise en place d'une scène unique type GEA réglerai le souci ?

[Lazer]

J'avais pas fait gaffe du coup, mais effectivement 195 scènes ça fait un peu beaucoup je trouve...

 

EDIT : si tu as DomoCharts, ça serait intéressant de regarder la courbe d'utilisation du CPU de la box.

 

Modifié le 15 septembre 2023 par Lazer

[jluc2808]

Il y a 13 heures, Nico a dit :

C'est étonnant tout de même, sur ma HC2 principale j'ai 116 modules en ce moment et sur la HC2 en slave dans le pool house 21 modules. Je n'ai aucune latence hormis au boot, il faut 1-2 minutes pour que tout se remette en route proprement. Mais sinon après, c'est ultra fluide.

Juste pour essayer, tu as coupé tous ces scénarios et regardé le résultat ? Si cela règle le souci, cela pousserai plus vers cette partie, et là peut être une simple mise en place d'une scène unique type GEA réglerai le souci ?

 

 

j'ai 4 catégories de scénarios

1 - ceux dont malheureusement je ne vais pas pouvoir couper tous les scénarios, nombre d'entre eux sont absolument nécessaires au fonctionnement basique des modules, par exemple pour chaque BSO (il y a 15 BSO) j'ai 8 scénarios obligatoires (montée, descente, stop, positionnement lame ouverte, positionnement lame fermée, position favorite lame, repositionnement lame après fermeture, repositionnement lame après ouverture) et pour les inter qui sont impliqués dans des va-et-vient j'ai 2 scénarios obligatoires par lampe (16 inter dans ce cas) .  ==> 152 scénarios

 

2 - ceux utilisés pour ajuster les couleurs des inter (walli controller), 2 scénarios par lampe dont les inter sont identifiés pour avoir cette fonction. (15 inter dans ce cas) ==> 30 scénarios

 

3 - les scénarios d'actions groupés  (ferme/ouvre tous les BSO, allume / eteint plusieurs lampes, ... ) ==> 8 scénarios

 

4 - les scénarios de régulation ou d'action système (allume/éteint si détection de mouvement, surveillance croisée de plusieurs capteurs, action externe sur trigger, .....) ==> 5 scénarios

 

la latence est aléatoire dans le temps et dans l'espace, si je veux couper, comme les usagers/clients habitent dans la maison je ne pourrais pas les invalider les type 1, pour les types 2 unitairement quand je teste ça fonctionne, les latences ne constatent que sur un temps suffisamment long. pour les type 3 la aussi en test unitaire pas de souci, mais dans le temps certaines fois on a des loupés (pas toujours les même et pas reproductible), pour les type 4  une invalidation sur au moins 1 mois sera nécessaire parce imprédictible et les tests unitaires ne posent pas de problème. 

 

Par ailleurs j'ai tenté de mettre une partie des scénarios de type 2 sous GEA, sans succès pour tout ce concerne l'ajustement des couleurs des inter.

Il y a 13 heures, Lazer a dit :

J'avais pas fait gaffe du coup, mais effectivement 195 scènes ça fait un peu beaucoup je trouve...

 

EDIT : si tu as DomoCharts, ça serait intéressant de regarder la courbe d'utilisation du CPU de la box.

 

Je n'ai pas DomoCharts, ça se trouve ou (edit j'ai touvé) ? est-ce que c'est simple à mettre en place (édit:  je me répond  - suivre le tuto) ?

 

ça reste une vraie question : puis-je le faire à distance sans mettre en cause le fonctionnement du système ?

Modifié le 16 septembre 2023 par jluc2808

[jluc2808]

je reviens après quelques temps et du travail au milieu, pour comprendre.

- avec les devs que j'ai fait sur la trace des routes z-wave, j'ai pu éliminer toutes les routes qui dépassaient 2 rebonds (en tout cas je n'ai plus aucun module qui a au moins 1 accès avec plus de 2 rebonds et la plupart ce sont des détecteurs)

- après installation de domocharts et fonctionnement pendant plus d'1 mois, ma charge CPU ne dépasse jamais 8% et est en moyenne proche de 3 à 5%, idem pour la mémoire qui n'est jamais saturée.

- j'ai fait un peu de spéléo dans les historiques et les traces consoles, je me suis aperçu que certains modules (notamment les inter et les scénarios de mise en couleur) avaient un comportement bizarre (que j'ai signalé via ticket au support fibaro)

par exemple :  pour un module inter walli controller simple en association directe z-wave avec la lampe cellier, j'ai un scénario qui met en vert les 2 parties de l'anneau lumineux lorsque la lampe cellier est allumée et en blanc lorsque éteinte, je vois les ordres à la console, mais avec un ordre fantôme (aléatoire) qui dit passe l'anneau supérieur en blanc au milieu des 2 passages en vert (anneau supérieur et inférieur)

==> là visiblement ça met la pagaille  (malheureusement le support répond peu ou pas, mon ticket est ouvert depuis 1 mois et j'ai des réponses pour prendre la main tous les 15 jours, mais sans prises de main)

 

ce qui m'embête c'est que c'est aléatoire, si c'était systématique alors j'aurais regardé tous les scénarios pour voir si paramètre ou un autre scénario mettait cette valeur, mais avec du aléatoire ??????

 

 

 

[Lazer]

Ah que c'est pénible les bugs aléatoires.... désolé ça ne t'aide pas, je compatis

 

[Achille85]

Hello, j'ai plusieurs walli controller (pas le choix dans ma maison je vous passe les détails électriques qui vous feront faire des cauchemars). 

J'ai également une latence sur chaque interrupteur qui doit activer un FGS-213 (ou deux suivant la scène).

Si j'ai bien compris, ces modules non alimenté en 230 (vu qu'ils sont sur pile les miens) ne font pas de relais donc pas de communication entre eux ?

Bon, j'avais pour idée du coup de faire ce qu'on m'a conseillé mais bon je n'y arrive pas, à savoir faire une association direct entre les interrupteurs et les modules.

1. comment faire ce genre de lien car malgré des vidéos.... ca fonctionne pas (les groupes, les associations directs)

2. est-ce une bonne idée ? limitation ?

pour estimer la chose :

il y a dans la maison (plein pied, donc pas d'étage) 8 walli controller et des FGS-213 il en a 10

 

merci de votre aide

[jojo]

les FGS sont alimentés en 230V, donc font relais.

Je ne connais pas les Wali, maos s'ils commande de l'éclairage ou des prises, ils devraient également être alimenté en 230V. Es-tu sûr de tes batteries ?

[Lazer]

Jojo : c'est le Walli Controller, il ne commande aucune charge, c'est juste une télécommande, il peut bien fonctionner sur piles uniquement.
 

Achille85 : tu peux faire une association directe depuis un module à batterie vers un module sur secteur, ça ne pose aucun souci, vu que l'appareil qui reçoit l'ordre (le FGS) est toujours alimenté, donc en écoute du réseau.

 

Ce qui n'est pas possible, c'est de faire une association directe vers un module sur batterie, car comme il est endormi, il n'écoute pas le réseau et ne peux recevoir aucun ordre (sauf s'il fonctionne en mode FLIRS, mais c'est rare car seuls certains modules le permettent, type thermostat par ex)

 

EDIT : pour la procédure d'association d'un Walli Controller avec un autre module, désolé je n'ai pas ce module, donc je ne peux pas reproduire. Fait peut être un tour sur le topic unique de ce module :

 

 

 

Modifié le 25 janvier par Lazer

[jluc2808]

Il y a 5 heures, Achille85 a dit :

Hello, j'ai plusieurs walli controller (pas le choix dans ma maison je vous passe les détails électriques qui vous feront faire des cauchemars). 

J'ai également une latence sur chaque interrupteur qui doit activer un FGS-213 (ou deux suivant la scène).

Si j'ai bien compris, ces modules non alimenté en 230 (vu qu'ils sont sur pile les miens) ne font pas de relais donc pas de communication entre eux ?

Bon, j'avais pour idée du coup de faire ce qu'on m'a conseillé mais bon je n'y arrive pas, à savoir faire une association direct entre les interrupteurs et les modules.

1. comment faire ce genre de lien car malgré des vidéos.... ca fonctionne pas (les groupes, les associations directs)

2. est-ce une bonne idée ? limitation ?

pour estimer la chose :

il y a dans la maison (plein pied, donc pas d'étage) 8 walli controller et des FGS-213 il en a 10

 

merci de votre aide

bonjour @Achille85, j'ai a peu près la même config des walli controller pour commander des FGS223, les walli sont dans les plots d'encastrement mais sans le 230v, ils ne sont plus sur pile car je les ai mis sur du 24v DC.

 

1- je constate, même avec des walli sur courant qu'il y a des fonctionnements aléatoirement avec latence, lorsque j'appui sur les walli pour allumer ou éteindre les lampes derrière les FGS223, c'est encore plus vrai (le phénomène de latence) avec des lampes dimmables derrière des FGD212.

2 - j'ai repris toute ma config pour m'assurer que tous les modules avaient au moins un route avec au maximum 1 rebond (il peut y avoir plusieurs routes avec 3 ou 4 rebonds, mais là on ne contrôle pas)

3 - mes walli sont maintenant tous alimentés et ça n'a pas changé grand chose (donc ils sont routeurs)

4 - si tu utilisent les walli en "va et vient" alors la seule solution est de passer en mode scène, le mode association dans ce cas ne convient pas , parce que pas de retour d'état de la lampe vers le walli 

 

 

plusieurs remarques : 

- que les walli soient alimentés ou sur pile cela ne change rien sur le fait qu'on puisse faire une association directe entre le walli controller et le FGS213 , la seule chose qui change c'est que le walli controller sur pile doit être réveillé pour prendre en charge un changement de paramètre ou d'association (sinon ce n'est pas effectif tant qu'on a fait le réveil)

voir la procédure de réveil https://tutoriels.domotique-store.fr/content/253/531/fr/manuel-en-français-du-fibaro-walli-controller-fgwceu_201-_-bouton-mural-emetteur-z_wave-plus-v2.html

- l'association avec les FGS(223 ou 213) doivent se faire via le paramétrage d'association multi-channel et pas en association du module, avec les groupe 2 et / ou 4 pour les FGS213, attention en mode association ne pas mettre en mode scene paramètre 20 à 0 mais en mode actionneur 20 = 1 , 2 ou 3 (en fonction de ce que l'on veut faire)  sinon ça ne fonctionne pas le module reste en mode scène et ne fonctionne pas en mode association

 

 

 

 

Modifié le 25 janvier par jluc2808

[ROBBEJP]

Bonjour à tous,

 

Très intéressants cet échange.

Je rencontre le même soucis chez moi... soucis purement aléatoire.

 

Pour exemple, inter connecté sur un FGBS-222 pour commander des projecteurs extérieurs, ou encore une télécommande Keyfob qui pilote d'autres projecteurs et pour finir des capteurs de mouvements qui démarrent des lumières.

Tous subissent des latences aléatoires au point même que certain capteur de mouvement restent en l'état "mouvement" a tors me posant de fait les soucis d'extinction des lumières.

 

Bref, ça s'est calmé un peu en mode "tombé en marche" mais j'en ai toujours. Je ne sais pas l'expliquer.

Jamais eu ce comportement avec mon ancienne HC2.

 

A noter, et je penche sur les suppositions évoquées par @Lazer sur le pooling ou autres module verbeux... je suis pour ma part obligé de l'activer pour mes modules AEOTEC HEM GEM5 qui ne fonctionne en retour d'état qu'à partir du moment où le pooling est activé... et pour surveiller une production photovoltaïque (activation du ballon d'eau chaude en fonction de la revente par exemple), la fréquence doit être élevée... d'ailleurs Si qqun connait une autre solution je suis preneur !

le plus frustrant dans tout ça c'est que sans ces latences aléatoires, ça marche plutôt en général de manière assez performante je trouve...

 

Bref, Je pense que la communication zwave n'est pas aussi stable qu'en HC2 ... et compte tenu du fait que leur version zwave est annoncé obsolète (version beta de leur V3 qui ne marche pas mieux pour le moment) je pense que nous somme tous au milieu d'un gué ... 

ça ne va pas aider Fibaro à avancer, adossé au fait de l'absence de ZWAVE au CES ... je me pose de sincère questions

 

 

 

[Lazer]

il y a 6 minutes, ROBBEJP a dit :

pour surveiller une production photovoltaïque (activation du ballon d'eau chaude en fonction de la revente par exemple), la fréquence doit être élevée... d'ailleurs Si qqun connait une autre solution je suis preneur 

Cherche "routeur solaire" sur Google, il y a plein de modèles à tous les prix et niveaux de simplicité/complexité.

 

il y a 7 minutes, ROBBEJP a dit :

Bref, Je pense que la communication zwave n'est pas aussi stable qu'en HC2 

Au contraire chez moi, je trouve mon réseau parfaitement stable sur HC3, alors que j'avais parfois quelques latences (mineures heureusement) sur mon HC2.
Et c'est d'autant plus remarquable que j'ai dépassé les 100 modules Z-Wave sur HC3.

Et je suis toujours avec le moteur v2 sur HC3, qui est le même que sur HC2 avec quelques évolutions mineures.

 

il y a 11 minutes, ROBBEJP a dit :

ça ne va pas aider Fibaro à avancer, adossé au fait de l'absence de ZWAVE au CES ... je me pose de sincère questions

Pour Fibaro, ou plutôt Nice, je ne sais pas bien quelle est la stratégie...

Quant au Z-Wave, article du jour de @cedriclocqueneux : https://www.maison-et-domotique.com/145737-mort-du-protocole-domotique-z-wave/

 

[ROBBEJP]

il y a 7 minutes, Lazer a dit :

Cherche "routeur solaire" sur Google, il y a plein de modèles à tous les prix et niveaux de simplicité/complexité.

Je connais bien !! je m'en suis même fabriqué un maison avec un module ESP32 et quelques autres pièces trouvés sur ALI express

Je voulais juste le faire avec ma HC3 afin de centraliser en 1 seul point toute l'intelligence de la maison.

En fait, la demande est simple, je cherche juste un module pince ampermétrique qui marche sur HC3 sans avoir recours au pooling ... et ça ... bai pas trouvé sans compter sur le fait d'avoir ouvert des ticket au support fibaro pour mon module AEOTEC, avec prise de main, de log et trace en tous genre ... j'en suis à l'épisode 10 de l'autruche 

 

Quant à la stabilité sur HC3, je reconnais être un peu dur sur mes propos, mais rejoint ce post ... qui justement partagent mes mêmes déboires et je ne sais que penser si ce n'est que ta supposition intéressante qu'un pooling passent au même moment que la latence constatée ... ça se tient !

 

 

 

 

[ROBBEJP]

il y a 19 minutes, Lazer a dit :

Quant au Z-Wave, article du jour de @cedriclocqueneux : https://www.maison-et-domotique.com/145737-mort-du-protocole-domotique-z-wave/

 

Et merci @cedriclocqueneux pour ton article très intéressant !!

Donc si je comprends bien ...wait and see.

 

 

[Lazer]

Il y a 1 heure, ROBBEJP a dit :

Je connais bien !! je m'en suis même fabriqué un maison avec un module ESP32 et quelques autres pièces trouvés sur ALI express

Je voulais juste le faire avec ma HC3 afin de centraliser en 1 seul point toute l'intelligence de la maison.

En fait, la demande est simple, je cherche juste un module pince ampermétrique qui marche sur HC3 sans avoir recours au pooling ... et ça ... bai pas trouvé sans compter sur le fait d'avoir ouvert des ticket au support fibaro pour mon module AEOTEC, avec prise de main, de log et trace en tous genre ... j'en suis à l'épisode 10 de l'autruche 

 

 

 

Hum OK... mais bon... un routeur solaire, c'est avant tout un appareil autonome, composé de 3 éléments principaux : un capteur de courant (pince sur l'arrivée Enedis), un triac de hachage du courant injecté dans les résistances du CE, et une électrique de pilotage de tout le bazar (Arduino, ESP, etc)

 

Si je comprends bien, tu cherches à déporter l'électronique de contrôle dans la HC3... ça ne peut pas bien fonctionner, dit autrement, ça ne peut que mal se passer

 

Pour être efficace dans sa récupération de l'énergie avant qu'elle ne reparte vers le réseau, sans pour autant soutirer de l'énergie depuis le réseau, le routeur solaire doit analyser plusieurs dizaines de fois par seconde ce qui se passe : la mesure du courant Enedis d'une part, et le hachage du courant vers les résistances.

Au minimum 100 fois par seconde (50 Hz c'est la fréquence du secteur, donc pour hacher chaque demi-période, alternance négative puis positive, il faut le faire 100x par seconde)

Si tu déportes ce boulot dans la box domotique, forcément, c'est impossible d'aller à cette vitesse.
Donc d'une part tu as un routage beaucoup moins efficace (comme dit, une partie repart vers le réseau, et/ou tu soutires une partie depuis le réseau en fonction des passages nuageux, des autres consommateurs de la maison, etc)

 

Et même si tu te satisfait de cette imperfection, tu vas au devant d'un autre problème.
Car tu vas tout de même chercher à aller le plus vite possible, donc collecter le plus rapidement possible les données depuis la pince, qui est en Z-Wave dans ton cas, puis d'envoyer des ordres au hacheur (en Z-wave aussi ? Je ne sais pas ce que tu as prévu là...)

Donc là tu vas complètement saturer le réseau Z-Wave, qui va littéralement s'effondrer.

Je rappelle (enfin, c'est tellement méconnu par les utilisateurs que c'est une découverte à ce niveau là) que le protocole Z-Wave, contrairement au Wi-Fi, de par ses spécifications, doit être en "silence" au minimum 99% du temps.

Le "temps de parole" accordé aux échanges entre les modules et le contrôleur doit être inférieur à 1%.... la raison, c'est justement de permettre une bonne réactivité lorsqu'un module veut envoyer une trame, et éviter les collisions de paquets, donc réémission, et donc latence voire perte de paquets.

Et là on en revient au sujet du topic... si latence sur le réseau, il y a 2 hypothèses :

- mauvais maillage, donc réémissions de trame, puis recherche de route alternative, et ultimement paquets perdus => solution : améliorer le maillage du réseau

- réseau surchargé => solution : rendre les modules moins bavard

 

Et dans un réseau Z-Wave, les modules les plus bavards, ce sont souvent ceux qui remontent des métriques de consommation électrique, car ça varie sans cesse, et parfois très rapidement.

Je disais plus haut dans le topic que j'ai eu le cas avec des Wall Plugs, donc commencer par faire un tour dans les paramètres pour alléger la charge réseau.

Maintenant sur la HC3 on a enfin le retour du panneau de diagnostique, ce qui permet d'identifier rapidement les modules les plus bavard, afin de les calmer.

[jluc2808]

j'ai toujours, mais malheureusement pas chez moi donc avec des difficultés à mettre en place du monitoring ou de la corrélation, sur le réseau que j'ai installé des latences,

- pour ce qui concerne le polling je l'ai passé comme préconisé à 440s,

- je suis en V2 sur HC3,

- 108 modules sur les 112 équipements sont en filaire alimenté et paramétrés comme hors polling, sont donc des routeurs Zwave

- les seules qui sont avec polling sont les 4 détecteurs de fumée et CO qui sont sur alarme,

- j'ai mis sur un réseau zwave / HC3L distinct les 4 modules de la piscine qui pouvaient poser problème

- j'ai repris tous les modules qui avaient plus de 3 rebonds pour refaire une reconfiguration du maillage et maintenant je n'ai plus aucun modules qui a au moins 1 route avec plus de 2 rebonds

- j'ai dans la mesure du possible fait des associations directes Zwave dans tous les cas ou c'étaient possible (entre les inter et les modules actionneurs)

- tous les modules actionneurs (FGS223, FGR223, FGD212) sont au même endroit dans 1 tableau dédié

 

ce qui m'agace le plus c'est que

2 inter (walli controller) juste à côté l'un de l'autre n'ont pas le même comportement en terme de latence  (bien entendu j'ai refait le maillage pour tous les modules inter avec latence)

que je n'ai strictement jamais de latence si je passe par l'application fibaro ou même sur homeassistant qui donne les ordres à la HC3 via le plugin Fibaro de HA (donc les ordres entre la HC3 et les actionneurs de lampes et de volets sont fluides)

 que si je moniteur la HC3 j'ai jamais plus de 8% de CPU , 75% de mémoire (dont 30% de cache) , 26% de stockage utilisé,

 

et dans les modules les plus bavards, ce sont des walli controller (donc pas bavard qui ne sont pas dans le polling et sont en fliaires) j'en ai 4  avec 68 communication frame / hour et 25% de failed communication

Modifié le 25 janvier par jluc2808

[ROBBEJP]

Bonsoir à tous,

 

@jluc2808 any news ?

Je rencontre vraiment le même soucis chez moi.

Des modules type FGD-212 que je possède en majorité, éparpillé un peu partout dans la maison dans les pot d'encastrement de mes inter.

Ceux-ci mettent parfois quelques secondes à réagir puis nickel juste après... incompréhensible.

Je me suis amusé à lancer manuellement tous les modules que je possède et tous répondent bien mis à par quelques exceptions de latences de certain modules ... pas forcément toujours les mêmes.

Je possède en parallèle une HC2 qui vivotte au même endroit (donc sur un maillage ZWAVE à part) ce n'est pas lui qui pourrait m'embêter ? je pose la question innocemment.

 

Je me posait la question, mais j'ose pas le lancer, dites moi si celà ne risque rien ? c'est le Reconfigurer le réseau maillé (mesh)

est-ce selon vous une bonne idée ?

ça sert à quoi concrètement ?

 

Merci !

bonne soirée à tous.

 

 

[TitiXsi]

il y a 20 minutes, ROBBEJP a dit :

Je me posait la question, mais j'ose pas le lancer, dites moi si celà ne risque rien ? c'est le Reconfigurer le réseau maillé (mesh)

est-ce selon vous une bonne idée ?

ça sert à quoi concrètement ?

 

Lazer me l'a déconseillé à posteriori mais l'ayant utilisé plusieurs fois quand j'ai eu à bouger des modules d'un côté à l'autre de la maison... Et je n'ai jamais rencontré plus de problème que ça.

J'ai monté une qa qui viens du forum officiel (je l'ai mise en français, elle était en allemand et j'ai rajouté du coloring pour les routes sans voisins ou autre... ). Je peux la partager, même si celà ne vaudra jamais le graph sous Synology (je crois)

Modifié le 15 février par TitiXsi