Lazer

Et sur le forum officiel, il y a un QuickApp qui permet de "voir" sur la HC3 tous les modules de la HC2... pratique si tu comptes conserver durablement les 2 box en parallèle. Ce QA permet de faire un peu ce que le mode passerelle permet (sauf que le mode passerelle n'est pas possible entre HC2 et HC3)

Oui pareil, même erreur "tlsv1 alert protocol version" depuis 2 ou 3 jours, je voulais en parler ici. A priori, PSA a changé la version de sa suite de chiffrement sur le serveur Web, si j'ai bien compris ils sont passés en TLS 1.3 et ce n'est pas supporté par le client HTTP de la HC3. Du coup on est complètement bloqués, je ne vois pas comment s'en sortir, à part attendre que Fibaro mette à jour la librairie OpenSSL embarquée dans la HC3.

Bravo, bien joué

Pourquoi tu dis "aussi" ? Tu es bien le seul à parle de perte de dynamique.... car il n'y en a jamais vraiment eu avec Fibaro. Enfin je veux dire, coté développement logiciel, ils ont toujours été à la ramasse, les longues années laborieuses avec la HC2, puis la HC3 qui a mis au moins 1 an avant d'être à peu près stable, les évolutions qui arrivent au compte goute, avec plusieurs années de retard, y compris celle annoncées au lacement de la box (mise à jour du firmware des modules RGBW pour la HC2, support du Zigbee pour la HC3, ne sont que 2 exemples flagrants). Donc moi j'y vois une certaine stabilité, depuis 10 ans que j'utilise l'écosystème Fibaro. Si tu veux un truc qui bouge, faut aller vers les produits Open Source. Tour à tour, on a vu Domoticz, puis Jeedom, puis enfin Home Assistant, fédérer une communauté toujours grandissante d'utilisateurs et développeurs, et donc là oui, clairement, on peut parler de dynamique. Peut être même un peu trop à mon avis, quand tu vois certaines mises à jour qui cassent tout le fonctionnement précédent... bah oui parce quand ça avance (trop ?) vite, forcément ça laisse quelques traces derrière. Après c'est un choix à faire en fonction de tes besoins et attentes envers la domotique, c'est ni mieux, ni moins bien.

Alors oui, mais non !!! Le zero crossing, ça permet effectivement de faire commuter le relai quand la tension passe par 0. Mais pas le courant ! Et c'est bien là le problème. Dans le cas d'une charge résistive pure (le radiateur électrique, la lampe halogène), pas de souci, le courant et la tension sont en phase et traversent le 0 en même temps, donc le zéro crossing va permettre d'allonger la durée de vie du relai. Si on regarde un datasheet de relai, il est indiqué la durée de vie (nombre de cycles de commutations) en fonction de la charge : à vide (courant nul) et en charge (pour un courant nominal, qui est inférieur au courant max toléré). Faire du zero crossing permet d'allonger la durée de vie du relai, car c'est presque comme si il commutait à vide, donc arc électrique hyper réduit voire nul, pas d'échauffement localisé de la lamelle, donc pas de soudure. Il ne reste plus que l'usure mécanique naturelle du relai.... très lente, donc durée de vie élevée. MAIS dans le cas d'un appareil capacitif (alimentation électronique, LED, etc) ou inductif (moteur, tube néon, lampe fluocompacte), cela implique un décalage du courant par rapport à la tension, on parle alors de déphasage (mesuré par le Cos Phi) Donc le zéro crossing ne sert plus à rien, car quand la tension est à 0, le courant passe encore... et c'est le courant qui est responsable de l'arc électrique tiré au niveau des lamelles du relai. Par ailleurs, l'autre problème dont je parlais, ce sont les appels de courant au démarrage de ce type d'appareils capacitifs/inductifs. Appel de courant qui est 10, 100, 1000 fois supérieur au courant nominal, pendant un très bref instant (on parle de millisecondes). On en revient au problème de base, courant hyper important au moment de la commutation du relai => arc électrique => échauffement => soudure. Voilà pour quoi on n'a que 2 solutions, déjà évoquées plus haut : - un contacteur de puissance qui a une construction différente d'un relai, et va mieux supporter l'appel de courant (avec certaines limites, sa durée de vie ne sera pas infinie non plus...) - limiteur de courant, mais utilisable seulement avec les faibles puissances de type éclairage. A noter que certaines alimentations électronique intègrent des correcteurs actifs du facteur de forme, et une limitation intégrée du courant d'appel. Avantages, on réduit le courant d'appel, ainsi que le déphasage, donc la sinusoïde du courant se rapproche de celle de la tension.... enfin c'est loin d'être parfait, mais moins catastrophique qu'une alim basique. Autant dire que tous les produits low cost (LED, alimentations diverses) n'intègrent pas ce circuit PFC. Si on prend une marque qualitative et reconnue, Meanwell, dont les produits d'entrées de gamme sont déjà plus cher que les produits "noname", on ne trouve pas ce circuit. On va le trouver dans leurs modèles les plus évolués, dont le prix fait x2 voire plus. Pareil pour les LED, une marque reconnue comme Osram a 2 gammes : une grand public, et une pro. La gamme pro a une étiquette énergétique plus mauvaise que la gamme grand public, car un circuit PFC ça consomme plus d'énergie. La plupart des gens n'achètent que des LED sans circuit PFC, de toute façon il n'y a que ça de vendu en magasin, les gammes pros se trouvent sur Internet. Dans l'industrie et le tertiaire, à partir d'une certaine puissance, les alimentations électriques ont obligation d'intégrer un circuit PFC. Pour une bonne raison : l'énergie induite et réactive est facturée par le fournisseur, tandis qu'en résidentiel, on ne paye pas cette énergie (Enedis, via le Linky, ne compte que l'énergie active) Du coup, pas besoin de PFC en résidentiel, et la loi n'impose rien... et les appareils qu'on achètent ont des bonnes grosses alimentations de merde, qui posent pas tant de souci que ça en temps normal, mais ça devient un vrai problème dès qu'on commence à les domotiser avec nos micro-modules domtiques dont les relais embarqués ne sont pas du tout prévu pour. Et le zéro-crossing ne peut rien y faire. Morale de l'histoire : arrêter de croire les promesses du marketing des fabricants, les lois de la physique sont les mêmes pour tout le monde, qu'on soit français, polonais, ou chinois. Il faut creuser la question pour le comprendre. Et pour finir, j'en profite pour vous rediriger sur ce topic où on a eu une discussion récemment au sujet des borniers des micro-modules, et du courant max admissible par les modules Fibaro versus les autres marques (différence entre la promesse marketing et la réalité), ce sont les mêmes phénomènes physiques qui entrent en jeu (un courant qui passe ça génère un échauffement), mais là on touche non plus à la sécurité du relai, mais à la sécurité de la maison toute entière :

En fait une lecture TCP ne doit pas rester en attente, sinon effectivement vu vas bloquer le thread (et donc les boutons et autres traitements) La logique, c'est d'ouvrir la socket, puis de faire des enchainements de write suivis de read. Normalement si tu fais ton read juste après ton write, tu vas recevoir la réponse de l'équipement en face, et donc le read va rendre la main au bouts de quelques millisecondes, ainsi le thread ne sera pas resté bloqué longtemps. Ce que tu ne fois pas faire, c'est lancer des read en aveugle, en attente infinie d'octets envoyés par l'équipement, car dans ce cas tu te retrouves dans des situations de blocage. Si vraiment ton programme ne peut pas faire des séquences de write/read, mais que tu doit attendre en "aveugle" des octets en maintenant un read, je te suggères ceci : définir un timeout très court, par exemple de 1s Alors si le read n'a rien reçu au bout de 1s, il va tomber en timeout, tu gères l'erreur pour relancer un read, etc en boucle... C'est pas hyper propre, mais ça devrait fonctionner. Ce qui manque pour pouvoir travailler proprement, ça serait de pouvoir définir une fonction de callback sur octets reçus par la socket, mais ça n'est pas possible avec la librairie mise à disposition par Fibaro. (en revanche ça l'est pour la librairie de gestion des WebSockets avec les Event Listenners)

Je ne comprends pas bien ta question concernant les appels asynchrones des boutons / TCP. Je t'ai indiqué plus haut quelques noms de QA qui utilisent les requêtes TCP, tu peux regarder sur le forum... ou dans la doc Fibaro car il y a un exemple : https://manuals.fibaro.com/home-center-3-quick-apps/ Idem, mon QA EDRT2 est déjà partagé sur le forum et prêt à l'emploi. Pour les types de modules : /api/quickApp/availableTypes /api/devices/hierarchy Et en complément, sur le forum officiel, @tinman a fait un gros travail d'identification des interfaces, propriétés, etc, présents sur les QA en fonction de leur type : https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/page/58/#comment-227370

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.