Lazer

Dans tous les appareils modernes d'aujourd'hui, on trouve des alimentations à découpage : dans les chargeurs de tous les appareils à batterie, les lampes LED, et les différentes alimentations des différents appareils qu'on utilise au quotidien. Le problème de toutes ces alimentations à découpage, c'est qu'elles comportent des condensateurs et inductances, et ce sont elles qui font ce (plus ou moins) gros appel de courant au démarrage... et qui colle les petits relais de nos micro-modules domotiques. Bref, tu le choix, chargeur de téléphone ou lampe LED, ça ne change rien, le problème est le même, bien que la puissance ne soit que de 5W. Et c'est d'autant plus étonnant qu'on n'a pas de problème à commuter une grosse charge résistive, comme un radiateur électrique de 15000W. La différence entre les 2, c'est que le radiateur consomme 15000W tout le temps, du début à la fin, tandis que la lampe LED / chargeur consomme certes 5W pendant 99,99% du temps, mais plusieurs milliers de Watts pendant quelques millisecondes... dépassant largement les caractéristiques du relai. On peut s'en apercevoir quand on branche un simple chargeur USB sur une multiprise électrique, si on regarde bien (et qu'on écoute aussi), on voit un petit éclair au niveau de la fiche électrique. Cet éclair, ce sont les milliers de watts qui passent pendant un bref instant.

Ne raisonne pas multithread, car que ça soit VD/Scene/QA sur HC2 ou HC3, ça ne change rien, il n'y a jamais eu de multithread. Sur HC2 quand tu cliquais sur un bouton ça déclenchait carrément un nouveau processus au niveau de l'OS, et ça explique d'ailleurs pourquoi on n'a jamais pu échanger d'information entre la Main Loop et les boutons d'un même VD : processus étanches, mémoire cloisonnée. Bref, dans un QA, tu as un seul process monothreadé. A toi de gérer "intelligemment" le temps afin de laisser la possibilité aux appels asynchrones de pouvoir s'exécuter. Et pour cela... il faut rendre la main au système. Chaque chaque appel de bouton, retour d'une fonction http, tcp, timeout etc ne sont que des appels asynchrones. En conséquence, tu dois bannir toute commande sleep() qui bloque le thread. Bon à la limite on peut s'autoriser un tout petit sleep de quelques millisecondes voire secondes, mais jamais au delà. Donc tu dois écrire l'équivalent de la Main loop des VD à la main avec du code LUA qui s'appelle lui-même en asynchrone avec une commande setTimeout() Pendant ce temps, ça permettra aux autres appels asynchrones (boutons, retours de requêtes http/tcp etc) de pouvoir s'exécuter. C'est une gymnastique qui n'est vraiment pas simple au début... mais terriblement puissance quand on a compris le truc, car ça permet de faire un faux multi-thread en quelque sort, mais sans les difficultés induites par le vrai multi-thread (je pense notamment à la gestion des Mutex) Pour ton autre question, je gère la gestion des compteurs différemment avec mon QA EDRT2, surtout qu'il ne faut pas te limiter à 2 tarifs horaires... penses à TEMPO et ses 6 tarifs ! Et c'est rien à coté de ce que nous réserve l'avenir (les tarifs qui varient plusieurs fois dans la journée...) Donc dans la HC3, je stocke le nom du tarif en cours (BASE, HC, HP, HPJB, HCJB, etc...) dans une variable globale, tout simplement, car un module de type binarySensor ne convient pas. Et j'ai un seul module de type energyMetter qui porte la somme des index des différents tarifs horaires. En alternative, tu peux imaginer avoir un module energyMetter pour chaque compteur remonté par le Linky (jusqu'à 6 en Tempo donc), chacun s'incrémentant à tout de rôle selon la tranche horaire.

Tu veux dire les données d'historique d'énergie (puissance électrique consommée) ? Je ne pense pas que ça soit possible, car les données d'énergies qu'on injecte (lors de la mise à jour des propriétés power/energy/value des modules) se fait avec le timestamp courant. Je ne vois pas comment on pourrait forcer un timestamp précédent... et puis même si on y arrivait, c'est un coup à faire complètement planter le panneau d'énergie de la HC3, qui agrège les données au fur et à mesure qu'elles arrivent, il ne pourra pas travailler rétroactivement. ça ne répond pas à ta question, mais je n'utilise pas la HC3 pour gérer l'historique des consommations, j'utilise pour ça une base de données externes (voir DomoCharts), ce qui m'a permis de faire ma migration de HC2 vers HC3 en conservant mon historique, et même d'agréger des données venant d'autres sources.

De mémoire la limitation des bornes min/max ne fonctionnait pas dans les anciens firmwares de la HC3. Tant mieux si ça fonctionne maintenant.

Si Matter fini par décoller un jour, tu peux faire une croix sur Zigbee, ça sera le premier protocole à disparaitre. Matter, enfin plus exactement Thread, c'est l'évolution directe de Zigbee. Z-Wave n'est pas mort et ne mourra pas de sitôt, car il a des caractéristiques techniques supérieures qui lui donnent un avantage certain, mais avec un cout supérieur... du coup réservé à une clientèle de niche (dont on est quelques un à faire partie ici...) La HC3 a la puce Zigbee, donc elle peut faire du Zigbee (elle le fait déjà, le problème c'est que ce protocole est un vrai foutoir, donc très compliqué de supporter tous les modules existants... Fibaro a même annoncé qu'ils ne supporteraient jamais tous les modules du marché) Cette puce peut être mise à jour (firmware embarqué) pour supporter Thread (comme dit plut haut, Thread est l'évolution, et donc remplace, Zibgee) Et Matter c'est que du logiciel (protocole de communication sur la pile réseau TCP/IP standard) donc Fibaro peut l'ajouter sur la box. Comme tu le vois, aucun besoin de matériel supplémentaire, la HC4 n'a aucune raison d'être, d'autant plus que la HC3 est sous utilisée en termes de ressources matérielles CPU/RAM. Du coup on en revient toujours au même problème avec Fibaro, c'est le développement et les évolutions logicielles, point limitant de leur offre par excellence.

Alors ça c'est vraiment très inattendu (ou pas) : la prochaine mise à jour est décalée d'au moins 1 semaine : https://forum.fibaro.com/topic/67998-new-version/?do=findComment&comment=269930 Avec Fibaro, on pourrait faire des titres à la James Bond : "Update another day". Notez que "The update is not enough", "Tomorrow never updates" et "No time to update" sont tout aussi valables

Peut être.... après même à la retraite, la box continue de fonctionner. Ce sont des années de vie en plus comme dirait l'autre... Mais c'est marrant parce qu'on se disait à peu près la même chose lorsqu'on était sur HC2, finalement Fibaro a sorti la HC3 et a redonné un second souffle à son écosystème. Même si en parallèle le marché a explosé, et bien que la base client de Fibaro n'ait pas franchement augmenté, celle des autres solutions a augmentée de façon exponentielle (Home Assistant principalement)

Bienvenue sur le forum

Pour les scènes, voir la doc officielle pour écrire les conditions (trigger) de déclenchement des scènes, effectivement c'est très différent de la HC2 : https://manuals.fibaro.com/home-center-3-lua-scenes/ Pour les QuickApps, c'est beaucoup plus compliqué que ça... Effectivement, ils ne sont pas multithreads (pas plus que les VD), mais plusieurs requêtes sont asynchrones (et ça c'est nouveau), donc un fonctionnement très différent. J'ai écris un mini-tuto pour la gestion des retours asynchrones d'une requête HTTP : Pour du TCP c'est le même principe, mais encore plus compliqué, car il faut enchainer les appels de fonctions asynchrones : connecte, write, read, close... Il y a quelques exemples de QA utilisant ce principe sur le forum. Il me vient à l'esprit les QA onduleurs Eaton et APsystems que tu retrouveras facilement. Si ça peut t'aider...

Ah en effet, ce n'est pas une beta, officiellement c'est une stable. En revanche... un peu ancienne.... je ne me souviens plus bien des bugs de cette version à l'époque... que tu pourras retrouver sur le topic unique de cette version de firmware : Si tu veux absolument faire une sauvegarde avant la mise à jour, je te conseille de contacter le support Fibaro, généralement ils peuvent débloquer la situation à distance. Et ensuite pour faire la mise à jour, c'est directement depuis l'interface WeB de ta box, en cliquant sur la notification de mise à jour qui apparait en haut, puis tu te laisses guider.

Tu ne précises pas ta version de firmware.... je suppose que c'est la dernière beta ? Car dans ce cas je crois qu'il s'agit d'un bug connu dont on a parlé sur le forum, mais j'ai vu également des discussions à ce sujet sur le forum officiel. Et pour rappel, toujours si c'est bien le cas, une beta, c'est une beta Donc pas stable... (même si avec Fibaro, dans le passé on n'a pas toujours bien su la différence entre beta et stable ...)

étonnant, je n'ai pas ce souci... ce ne serait pas plutôt lié à un paramètre de configuration particulier dans ton Syno ? Au niveau du contrôle d'accès utilisateur ou un truc dans le genre. Sinon pour redémarrer un QA automatiquement, il faudrait que je ressorte mon Watchdog du fond de tiroir dans lequel il est rangé...

Non.... la HC2 ne peut pas servir de répéteur. Et puis de toute façon, les répéteurs ça n'existe pas en Z-Wave, qui est un réseau au fonctionnement assez différent du Wi-Fi, pour lequel les répéteurs existent (mais c'est de la maÿrde quand même) Le réseau Z-Wave est un réseau maillé, les noeuds alimentés par le secteur participent activement au maillage du réseau, en transférant les paquets, uniquement si nécessaire, vers un module voisin (et c'est là tout la différence avec un répéteur). En fait, on peut faire un parallèle entre le réseau Z-Wave et les routeurs d'un réseau IP, un routeur ne transmet le paquet que si nécessaire, vers son voisin, afin que de proche en proche, le paquet atteigne sa cible. Du coup, la grande question, c'est de quoi est constitué ton réseau ? Si tu as des problèmes de maillage, il faut ajouter des modules alimentés sur secteur afin de renforcer ton réseau. Des micromodules (FGR, FGD, FGS), des Wall Plugs, etc. Plus tu auras de modules, plus ton réseau sera stable (tiens, c'est l'inverse du Wi-Fi) Les modules sur batterie ne comptent pas, ils sont endormis et ne participent pas au maillage.

Je viens seulement de remarquer que le 16 septembre, j'ai encore eu le compteur d'énergie cumulée des IQ7+ qui s'est réinitialisé à 0. C'est la seconde fois que ça le fait, la dernière fois je crois que c'était au moment de la mise à jour du firmware D7 en juillet 2023. Je n'ai pas noté le firmware que j'avais eu à cette époque.... mais là je suis en D7.6.175, du coup je ne sais pas dire si Enphase a forcé une nouvelle mise à jour ou non... Bref, plus que jamais il ne fait pas fair trop confiance aux infos remontées par les IQ7. Restons sur les mesures de l'Envoy (via les pinces)

En revanche à partir du moment où c'est un fichier PHP, ça ne permettra pas l'écriture simplifiée comme dans l'exemple qu'avait partagé Jojo en page précédente. Il faut respecter la syntaxe du PHP, avec les guillemets, points virgules, etc. Donc un peu moins ergonomique.

Juste pour être sûr : c'est l'un ou l'autre, tu n'as pas besoin des 2 en même temps. Contacteur ou limiteur.

Ben ce que je dis c'est qu'une fois renommé entre chose que PHP, alors on crée une brèche de sécurité.... Quand je parlais de serveur Web, je ne parlais pas de celui du forum, mais de celui chez vous sur lequel vous allez héberger le script.

Juste pour info, ce n'est pas une bonne idée de laisser un fichier INI sur un serveur Web, surtout si celui-ci est exposé sur Internet. En effet, il suffit de taper le nom du fichier INI dans l'URL de son navigateur pour voir apparaitre le contenu du fichier, car sans configuration particulière du serveur Web (Apache, etc), celui-ci va le considérer comme un simple fichier texte et afficher son contenu.... révélant ainsi les paramètres de configuration et notamment le mot de passe ! Il faut mieux conserver une extension PHP, au moins le contenu sera interprété par le moteur PHP appelé par Apache, et on ne verra pas en clair les infos contenues dedans. Ensuite on peut inclure le fichier de config dans le script php principal à l'aide d'une directive include. C'est ce que j'ai fait pour DomoCharts par exemple.

Non, ce n'est pas un télérupteur qu'il faut utiliser, mais un contacteur. Un télérupteur, c'est un appareil électrique qui conserve son état : à chaque impulsion, que ça soit un interrupteur (bouton physique) ou un module domotique, il change d'état jusqu'à l'impulsion suivante. Dans ces conditions, la domotique ne peut pas savoir quel est l'état du télérupteur, sauf à compter les impulsions... et encore, y'a forcément un moment où ça va buguer. Un contacteur, c'est un relai de puissance, donc un appareil électrique qui va "recopier" la consigne donnée en entrée sur la sortie. Donc à chaque fois que le module domotique va s'ouvrir ou se fermer, l'état du contacteur reflètera parfaitement celui du module domotique. Donc la domotique sait à tout instant l'état du contacteur, forcément. Chez Legrand, j'utilise les contacteurs références 4 125 23 ou 4 125 58 qui fonctionnent très bien. Pour info, sur le forum, il y a pas mal de discussions autour des télérupteurs dès qu'on parle éclairage, car ils sont souvent déjà présents dans les maisons quand on commence à installer la domotique. Et le 1er conseil qu'on donne, c'est de supprimer le télérupteur, car on se retrouve avec les problèmes d'état décrit plus haut. En fait, le module domotique, il agit comme un télérupteur, donc le télérupteur peut/doit être supprimé. Dans le cas qui nous intéresse ici, on rajoute un contacteur pour protéger le micro-relai du module domotique contre les appels de courants du néon. C'est juste tout simple, il n'y pas de complication particulière. EDIT : le plus simple à installer, c'est quand même le limiteur de courant H-Tronic.

Quand on découvre que Shelly c'est de la conception low-cost "à la chinoise" : https://forum.gce-electronics.com/t/le-prix-de-lelectronique/17515 Le premier post montre que l'alimentation n'est pas isolée et qu'en cas de défaut du 230V pourrait se retrouver sur la prise réseau RJ45, avec les dégats qui vont avec Un peu plus bas un post montre plusieurs photos de modules ayant surchauffés. Alors bien que nous ne connaissions pas leur conditions d'emploi, le résultat correspond à ce que j'ai décrit plus haut. Je met ça sur ce topic car on a justement comparé les modules de cette marque avec ceux de Fibaro. A prendre en compte. Perso je reste sur mes préconisations : à partir du moment où il y a de la puissance à faire passer, et plus encore en mode soutenu (plusieurs heures), il faut avoir recours à un contacteur / relai de puissance. Fibaro ne s'y est pas trompé en réduisant la puissance max supportée à chaque génération de ses micro-module. Encore une fois, aucun constructeur n'est au dessus des lois de la physique, il y a des limites infranchissables si on veut une installation qui fonctionne en sécurité.

Tu sais que même en chauffant à l'électricité les jours rouges, sans aucun effort particulier, tu seras quand même gagnant financièrement, globalement sur l'année. Aller s'embêter avec un chauffage d'appoint au gaz, je ne suis pas convaincu... bon sauf si tu l'as déjà, mais si tu dois l'acheter ça sera difficilement rentable. Surtout si c'est temporaire en attendant le poêle à bois.

ça se précise, maintenant on est passé à "very soon", avec même un pronostique pour la semaine prochaine (sauf si un bug est découvert ) https://forum.fibaro.com/topic/67998-new-version/?do=findComment&comment=269682

Celui que j'ai ouvert, je l'ai mis en court circuit par erreur. Il a complètement grillé et surchauffé, la moitié du circuit électronique est carbonisé, et le plastique du boitier a fondu et fusionné avec le PCB. Donc irréparable. Celui qui a grillé naturellement, je suppose que c'est le triac qui est en court-circuit, donc à changer, Peut être aussi d'autres composants autour, mais je ne suis pas allé voir vu que je ne l'ai pas ouvert.

Ah super ça, tu nous tiendras au courant, ça m'intéresse J'ai 2 FGD-211 hors-service, un que j'ai ouvert pour voir, et un autre intact physiquement (le triac est en court-circuit, donc il reste passant et la lumière ne s'éteint plus jamais)

Hors garantie, j'ai peur que la réparation coute plus cher qu'un module neuf (qui sera forcément un 212 vu que le 211 n'est plus fabriqué...)