Lazer

Ah oui gros bug là. Tu as quel navigateur ? Tu as bien vidé le cache (réflexe à avoir, surtout après chaque mise à jour Fibaro)

Je crois que le firmware 2.8 est le dernier pour les FGMS de première génération (Z-Wave de série 300), et le firmware 3.2 est le dernier pour les FGMS de seconde génération (Z-Wave+ de série 500)

Oui, et tu peux aussi utiliser un FGD-212, c'est encore mieux car tu peux faire varier la luminosité, enfin pour cela il faut utiliser des ampoules LED dimmables. Attention avec le FGS, les ampoules LED ont souvent un courant d'appel au démarrage très important, à la longue la languette du relai va coller et ton module sera bon pour la poubelle. Il faut utiliser une résistance thermique pour limiter le courant d'appel et ainsi protéger le relai. ça : https://www.amazon.fr/gp/product/B01DUHKQQ2/ Vu son prix, qu'il faudra ajouter au prix du FGS, autant acheter une ampoule LED dimmable et l'utiliser directement avec un FGD. MAIS Je te rappelle que ta demande initiale ne concernait pas une simple ampoule LED, mais une ampoule LED connectée. J'ai expliqué pourquoi tu ne peux pas la domotiser avec un simple module domotique. Enfin si tu peux, mais elle ne sera plus connectée à rien du tout une fois qu'elle ne sera plus alimentée... donc aucun intérêt.

@jluc2808 intéressant, et bravo pour le résultat. Tu devrais poster sur le topic du script PHP en question, ça serait plus utile, ton message ne serait pas perdu parmi presque 500 pages de syntaxe GEA, et aussi partager le PHP modifié Petite erreur de syntaxe sur la 2nde condition. Tu as 2 façons de l'écrire, au choix, avec la syntaxe abrégée ou la syntaxe complète : GEA.add({{"Profile", 1}, id["VEILLEUSE_ENA"]}, 60*60, "", {"TurnOff", id["VEILLEUSE_ENA"]}) GEA.add({{"Profile", 1}, {"Value", id["VEILLEUSE_ENA"], true}}, 60*60, "", {"TurnOff", id["VEILLEUSE_ENA"]})

En pratique je suis à 5s d'intervalle de rafraichissement, mais comme la requête se prend 10s de timeout, en conséquence ça fait 15s entre chaque message d'erreur.

Tiens, comme tous les soirs à 23h, sauf que cette fois-ci j'étais devant le PC quand j'ai reçu la notification, donc j'ai fait une capture d'écran du log. La passerelle est indisponible pendant moins de 2 minutes.

Ah désolé j'avais pas compris ça comme ça Oui effectivement mes QA sont découpés en plusieurs "fichiers", ce qui permet de structurer le code un peu plus proprement... enfin j'essaye La finalité, c'est de faciliter la réutilisation de bouts de codes entiers, sous forme de fichier, et qui s'apparente à des librairies comme il est de coutume en programmation. Les premiers développements sont plus long, mais le temps gagné par la suite est considérable : création des nouveaux QA, mise à jour d'une partie d'un QA, et ça m'a même aidé dans ma migration HC2=>HC3.

30m en 2.5mm² derrière un disjoncteur de 20A, ça fait 11V de chute de tension, soit 4.80%, ça fait beaucoup je trouve. https://schema-electrique.net/calcul-chute-de-tension-electrique-formule-calcul-section-cable-triphase-monophase.html Après ça dépend aussi de la puissance sur chaque circuit (donc du nombre de MO), c'est peut être moins que ça, j'ai pris le pire cas de figure. Bon c'est pas le sujet mais quand même un peu important. Il est probable en effet que la passerelle Envoy essaye de se connecter au cloud Enphase. Non pas pour envoyer des infos (ce qu'elle fait tout au long de la journée tant que les MO produisent), mais peut être pour chercher ne dernière version de firmware ou autre truc dans le même genre... donc si elle n'arrive pas à se reconnecter au serveur, peut être qu'elle reste bloquée. Si c'est ça c'est quand même bien merdique comme fonctionnement... m'enfin si elle produit dès le matin, à la limite c'est sans impact réel. Non pas essayé ton code, mon QA me convient

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.