Lazer

Le support du Zigbee est en beta, pas sûr que les volets soient supportés pour l'instant... Fibaro s'est concentré sur les lumières pour commencer, mais pas mal de capteurs fonctionnent également très bien. Mais pour les autres actionneurs, c'est la loterie. Il y a un topic sur le forum qui en parle, et aussi un autre (plus complet) sur le forum officiel qui liste tous les modules Zigbee testés par les utilisateurs.

Bienvenue sur le forum

En Z-Wave, on ne peut pas forcer un autre maillage. Tout au plus, peut-on demander au module de recalculer la meilleure route en prenant en compte ses voisins, mais il peut décider de reprendre la même route qu'avant. Plus de détails : Z Wave Routing Basics Z Wave Routing Basics: Retry Strategies Z Wave Routing Basics: Application/Binding Retries, Heal and Explorer

Oui c'est normal. Et tu as plus de sensors que de devices car un device peut embarquer plusieurs sensors. Exemples : un Wall Plug = power + energy, ou bien un FGMS = light + temperature, etc...

Les pics de CPU ne sont pas liés qu'à l'activité des modules Z-Wave, cela peut aussi provenir du code LUA d'un QuickApp, d'une scène, ou bien encore de nous-même quand on manipule l'interface Web de la box. En effet, la génération des pages Web est l'activité la plus consommatrice de CPU. Raison pour laquelle je préfère utiliser le suivi du CPU dans DomoCharts (donc hébergé sur un autre serveur/NAS) plutôt que d'utiliser la page de diagnostiques intégrée dans la box qui n'est pas du tout représentative de l'activité normale de la box. Il faudra monitorer sur une plus longue période, mais 4 à 6% de CPU, avec une pointe à 10%, ça n'a rien d'alarmant pour l'instant. Pour comparaison, sur ma box pas mal chargée, mais sans latence perceptible, le CPU ne descend jamais en dessous de 6,9%, et dépasse légèrement les 20% quand j'ai plusieurs onglets ouverts (interface principale, QuickApp en cours d'édition, fenêtre de log, etc). Les pics ne dépassent pas 10% en usage normal (donc sans page web ouverte) J'ai un pic 1 fois par semaine lors du backup auto la nuit, vers 40%, mais ce n'est pas représentatif car tous les QA redémarrent à ce moment précis. J'ai pour habitude, dans tous mes QuickApps, de calculer et d'afficher la consommation mémoire et CPU (en ms et en %) afin d'identifier un QA qui occuperait un peu trop de ressource. Ironie du sort, DomoCharts est l'un de mes QuickApps les plus consommateurs, il faut dire qu'il a 277 mesures à envoyer vers la base de données chaque minute, ce qui fait des tables d'une certaine taille à manipuler.

Bravo Tu peux cliquer dès maintenant sur le bouton "Devices" du QuickApp, ça permettra d'alimenter la base de données et donc de voir le début des graph sans attendre demain, et également de pouvoir utiliser la page admin.php (ce bouton est automatiquement "cliqué" tous les jours à minuit)

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.

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 :/

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

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.

Nom de variable trop long je pense. Sinon, 1s, tu m'étonnes que la passerelle saturait

Ouh là là, c'est bizarre ça. C'est bien le paramètre RefreshInterval que tu as mis à 60 ? Sinon il faut relancer le QA avec la variable debug à true pour voir le détail de ce qui se passe. (il faut l'ajouter au QA si elle n'existe pas déjà dans l'onglet dédié)

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.

Ah ben oui tient, bien vu Je n'avais pas percuté quand tu as parlé de Wi-Fi, mais effectivement, clairement les requêtes trop rapprochées sollicitent trop ta passerelle, surtout si tu as mis 5 ou 10 secondes d'intervalle. Repasse à 60s et ça ira mieux je pense.

Les API locales, c'était une fonctionnalité qui n'était même pas documentées, donc bon courage... j'espère que tu as une armée de très bons avocats

Le week-end dernier c'est leur cloud qui avait des souci, ils ont même mis une bannière sur leur site... résultat plusieurs heures de retard dans la mise à jour des stats. Forcément ça se répercute sur l'appli vu qu'elle va chercher les données au même endroit. C'est "marrant", il y a quelques temps je disais que ce firmware D7 avait été poussé à la va vite chez les clients sans prendre le temps de le tester à fond, Nico n'était pas d'accord et disait que tout était maitrisé. Visiblement pas, avec du recul.

C"est tout de même très étrange tous les problèmes que tu as.... si tu n'es pas le seul sur Facebook, ce n'est pas vraiment rassurant cela dit... De mon coté, Enphase, ça fonctionnement tellement bien, aucun souci à déclarer (si on met de coté la politique de gestion des firmwares / cloud...) Je n'en dirais pas autant d'APsystems dont la passerelle est une grosse bouse fumante, et j'ai aussi quelques doutes sur les micro-onduleurs... pas sûr, mais je soupçonne quelques micro-coupures, sans incidence sur l'énergie produite quotidiennement cela dit.

J'ai vu, mais ça te sert à quoi de savoir combien de QRelay et de MO fonctionnement ? Normalement il fait jour et ils fonctionnent tous, sinon il fait nuit et tous les MO arrêtés, ou bien le courant est coupé et dans ce cas ce sont tous les MO + les QRelays qui sont arrêtés. En ce qui concerne le token, je pense qu'il est vérifié en local, je doute fort qu'il soit vérifié en ligne à chaque connexion sur l'API locale. C'est facile à savoir, il suffit de couper l'accès Internet pendant qu'on fait les essais... ce qui ne m'est pas arrivé récemment (pas de coupure fibre depuis que je suis passé à l'auth avec le token... enfin j'ai pas souvenir)

En Z-Wave, je dirais Aeotec ou Qubino. Enfin, Qubino, attention, ils ne sont plus fabriqués, depuis le rachat par Shelly ils sont en train de resortir les modèles remis au gout du jour... seulement 3 pour l'instant, et pas encore de pince de mesure.... sinon pour rester chez Shelly le fameux 1 PM qui est si populaire, mais il faudra l'interroger via l'API en Wi-Fi. Sinon pour ta passerelle Envoy.... depuis le début tu étais en Wi-Fi ? Cherche pas plus loin, le problème est là, ça ira mieux en RJ45. La fibre n'a aucun impact, puisque tu l'interroge en local, donc sans passer par Internet. Tout au plus un accès Interner trop lent et saturé pourrait retarder l'envoi des données vers le cloud Enphase, m'enfin ça ne doit pas représenter une grosse quantité d'info.

Oui justement, c'est pour ça que je recommande les Somfy. Ce ne sont pas les seuls, il y a d'autres marques, et aussi du noname.... mais pas les Bubendorf, donc attention car c'est une marque qu'on retrouve chez beaucoup d'installateurs.

OK, donc en 1/2h tu as eu le temps de remplir la mémoire du QA, c'est cohérent du coup.

Perso je resterais en filaire... moins cher, plus fiable, et surtout plus pérenne. Dans 10 ans, 20 ans, 50 ans, il y aura encore des fils, alors que tous les protocoles radios actuels auront été remplacé par des nouveaux... Et même avant ça, les HC3 sera remplacée par autre chose, donc la comptabilité Nice Bidi est plutôt un point faible qu'un point fort à mon avis. Attention aux moteurs Bubendorf qui ont un mode de fonctionnent très particulier et qui ne permet pas la calibration correcte. Donc rester sur du classique Neutre + Phase Montée + Phase Descente comme suggéré par @flacon030 Les moteurs Somfy sont parfaits pour ça. A noter que cela peut être en 3 fils, mais aussi en 4 fils (avec la terre en plus, tout dépend de la classe d'isolation du moteur)

C'est étonnant, car on n'a pas la même erreur. Toi tu as une erreur "max_allowed_packet" qui semble indiquer que tu peux augmenter la taille de ce paramètre dans la configuration de ton serveur SQL. De mon coté c'est une autre erreur, au moment d'insérer les données (nombreuses) dans la table qui échoue... sans que je ne trouve de solution pour le moment. Bref, dans les 2 cas réduire la taille de la mémoire du QA permet de contourner le problème, mais ça diminue l'intérêt de la mémoire... EDIT : autre chose, mais je suis surpris que la mémoire se remplisse si vite... ton NAS met 1h à rebooter ? Parce que juste un reboot, ça dure quelques minutes, et normalement ça passe sans saturer la mémoire. Chez moi l'erreur apparait quand le NAS est indisponible pendant un long moment, par exemple que je fait des manips dessus, et qu'il est éteint pendant tout ce temps là.

Ah j'ai le même problème depuis un certain temps (sans que je ne puisse déterminer à quel moment ça a commencé...) Tu n'es pas obligé de rebooter la HC3, il suffit de forcer le redémarrage du QuickApp. Pour corriger le problème, il faut réduire la mémoire du QA.... perso je suis descendu de 10000 à 5000 mesures, et ça a suffit (pour l'instant ?)

Je vois dans le code page précédente qu'il y a une fonction QuickApp:sendpush(), donc c'est elle qu'il faut appeler depuis un autre QuickApp ou Scène. C'est comme d'habitude, avec fibaro.call(), ou bien dans GEA avec "QuickApp" (voir la doc de syntaxe) (précision : je n'utilise pas Pushover)