Lazer

Je ne connais pas ces panneaux en particulier, mais si tu as des coupures de courant / chute de tension, alors c'est normal que les MO arrêtent de produire, c'est dans la norme pour des raisons de sécurité. A noter que même sans coupure de courant secteur, tu peux aussi avoir une coupure des MO si la tension à leur borne dépasse 253V, ce qui peut arriver si le câble trop long / de trop faible section provoque une chute de tension importante. 23h c'est l'heure à laquelle mon Envoy est indisponible, mais ça ne dure que quelques minutes chez moi.

Tu peux utiliser les balises de code, ce n'est pas très lisible sans cela : Essaye sans les guillemets, ça ira mieux, il faut un booléen, pas une string : checkCertificate = false ça c'est très fort Tu as quels modèles de MO et quels panneaux ? C'est peut être normal, tu sais qu'il y a une tension minimale pour que les MO fonctionnent. C'est un des avantages des IQ7+ sur les IQ7A d'ailleurs, ils sont limités en puissance, mais produisent plus tôt/tard, donc c'est aussi valable en cas de temps très couvert quand la prod s'approche de 0W.

La liste des devices : /api/devices Qu'on peut récupérer en LUA avec api.get(), et qu'on peut également filtrer. Quelques exemples (liste non exhaustive) : /api/devices?visible=true returns devices with visible equal to 'true' /api/devices?property=[batteryLevel,100] returns devices with property batteryLevel equal to 100 /api/devices?property=[unit,%CE%BCg/m3] returns devices with unit equal to µg/m3 /api/devices?interface=light returns devices with light interface /api/devices?type=com.fibaro.netatmoWeatherStation returns Netatmo Weather Station /api/devices?baseType=com.fibaro.weather returns Weather plugins /api/devices/?property=isLight /api/devices?interface=zwave&parentId=1 Pour les child devices, voir la doc officielle : https://manuals.fibaro.com/knowledge-base-browse/hc3-quick-apps-managing-child-devices/ Et il y a un topic qui en parle sur le forum... la difficulté est de gérer la table de mapping des différents modules enfants. Pour le reste, vu que c'est de la bidouille, il faudra être imaginatif ! Et expérimenter ce qui marche / ne marche pas...

Ouais y'a du monde en effet ! Si c'est juste un tableau, à ta place je ferai un script en LUA directement, qui parcoure tous les modules parents de type Z-Wave, et affiche la liste dans le log du QA. Pas sûr GEA soit le meilleur outil pour ce besoin... d'ailleurs perso j'ai pas compris à quoi sert cette fonction, m'enfin dans GEA quand on ne sait pas à quoi sert une fonction, c'est sûrement qu'on n'en a pas besoin

Regarde dans le JSON de ton module si la propriété LastWorkingRoute existe bien, car c'est elle que va chercher GEA. A priori elle est présente sur le module parent, mais pas sûr que ça soit systématique. Normalement GEA est censé aller chercher tout seul le parent... mais cette fonction date de la HC2, je en sais pas si elle fonctionne encore depuis le portage de GEA sur HC3. Pour voir la cartographie de ton réseau Z-Wave, il y a un tuto quelque part sur le forum avec un script PHP à faire tourner sur un serveur Web, qui présente tout cela de façon bien plus visuelle que GEA.

Oui je pense que c'est techniquement faisable.

C'est vrai.... mais déformation professionnelle aidant, je ne fais jamais les dernières mises à jour logicielles, car par expérience ça casse souvent quelque chose qui marchait bien. Idéalement il faut 2 environnements, 1 de test, et 1 de prod. Bon chez moi c'est plus compliqué, puisque j'ai dissocié la DB (qui est hébergée sur le NAS) des pages Web (qui sont dans une VM). Du coup je maitrise mieux les processus de mise à jour, et de retour arrière le cas échéant. La DB sur le NAS c'est juste du MariaDB, donc aucun risque de casser quoi que ce soit, la seule difficulté ça a été lors de la migration vers MariaDB 10 il y a quelques années.... avec le changement de port sur le Syno, rien de si méchant que ça au final ! On est plus embêté avec le serveur Web ou la version de PHP... mais vu que je suis dans une VM dédiée à cet usage, je sais quel paquet je met à jour, et la version de PHP ne change jamais toute seule. Mais surtout, je l'ai évoqué, l'essentiel c'est d'avoir des sauvegardes pour pouvoir faire un retour arrière. Quant à l'exposition à l'extérieur, j'ai solutionné le problème avec un double reverse proxy filtrant. De plus, la DB est sur le NAS en coeur de réseau, les pages Web sur la VM isolée dans une DMZ, avec filtrage firewall, du coup le NAS n'est jamais exposé sur Internet. Un peu lourd à mettre en place, mais bien sécurisé. Il y a longtemps, je n'avais pas encore mis en place toute cette infrastructure, et ma base DomoCharts était hébergée en ligne chez OVH. J'ai pu tout rapatrier sans perte de données et en conservant l'historique, c'est aussi ça la force de la solution maison comparée à un stockage dans la box. Tu parles de Yubii, c'est pareil, je passe par le reverse proxy pour accéder à ma box sans passer par le cloud Fibaro tout en conservant un haut niveau de sécurité, la HC3 n'était pas accessible en direct depuis Internet. Tu ne peux pas forcer un capteur lambda à être de type température... et de toute façon ça casserait la bonne intégration de ce capteur, donc quel intérêt ? Tu peux le faire avec un QA puisque tu peux choisir le type, mais là encore à quoi bon, puisque ça casserait l'intégration. La force des QA, c'est justement de pouvoir choisir le type de module qui va bien en fonction de sa finalité. Il faut te faire une raison : la box Fibaro ne permet pas, en natif, d'historiser toutes les données (comparé à d'autres solutions domotiques) Raison pour laquelle j'ai développé DomoCharts, afin d'historiser les données des capteurs sur une base de données externe. D'autres ici sont même allés encore plus loin, par exemple pour historiser tous les événements, ou tous les logs, sur une plateforme externe. Après quand je vois ce que proposent les autres concurrents, j'aime autant DomoCharts. 2 exemples : - eedomus : sur le cloud, avec abonnement - Home Assistant : dans InfluxDB, que je n'aime pas du tout, j'ai pas réussi à gérer correctement l'historisation comme je voulais Une bonne base SQL, à l'ancienne, ça me parle mieux, je maitrise ce qui est stocké dedans, je peux faire toutes les requêtes qui m'intéressent pour exploiter les données Si un jour je change de solution domotique (ce qui est déjà arrivé quand j'ai fait HC2 => HC3), je conserverai DomoCharts, c'est bien plus pérenne pour mon usage en tout cas.

Non pas possible malheureusement, Fibaro n'a implémenté l'historique que pour certains types de capteurs (température, consommation, ...) Et de surcroit, cet historique est limité dans le temps, afin de ne pas saturer la mémoire interne, il est purgé au bout d'un certain temps (variable selon la quantité de données stockée) Du coup, perso je préfère tout conserver dans une base externe, sur mon NAS, que je maitrise, et qui survit au changement de box. Raison d'être du projet DomoCharts.

Bienvenue sur le forum

Oui c'est tout à fait ça. Pour le plugin Hue, je ne sais pas te répondre, je n'en utilise pas. Mais peut être aussi que le plugin n'est plus nécessaire si on peut inclure les Hue directement dans la HC3, vue qu'elle communique en Zigbee. A creuser, fait une recherche sur le forum, beaucoup d'utilisateurs ont des ampoules de la marque.

Rien du tout, si tu utilises des ampoules connectées (Wi-Fi, Zigbee, Z-Wave, ou autre technologie du futur), alors tu dois laisser l'interrupteur tout le temps en position fermée (= le courant passe), sinon les ampoules ne sont plus alimentées et tu ne peux plus les piloter... ce qui enlève tout l'intérêt des ampoules connectées. Généralement on conserve une ampoule normale pour le plafonnier, ce qui permet de la domotiser avec un Dimmer FGD-212, et on utilise les ampoules connectées (ou ruban RGB) sur un autre circuit tout le temps alimenter, qui ne sert pour l'éclairage d'ambiance. Après on peut aussi imaginer ajouter une télécommande, ou un 2nd interrupteur mural, qui n'est connecté sur aucune charge, mais qui sert juste à déclencher des scénarios pour allumer/éteindre les ampoules connectées. PS : le neutre avec des fils violets, au secours, installation électrique hors-norme et dangereuse, il faut redoubler de méfiance quand tu touches à ton installation !

Oui c'est bien à cet endroit.

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.