Lazer

Fibaro dit qu'ils ajouteront le support du TLS 1.3 au premier trimestre 2024. ça c'est positif Mais... en prenant en compte la temporalité polonaise... c'est pas demain la veille https://forum.fibaro.com/topic/68420-http-request-tls-error/

Oui je crois bien. Je n'ai plus le nom en tête, c'est sur le forum officiel.

Ah oui si on juge par la "stabilité" des mises à jour, je dirais qu'il y a eu 4 grandes phases : - HC2 v3 : stable - HC2 v4 pendant 2 ans : instable - HC2 v4 après 2 ans : stable - HC3 pendant 1 an : instable - HC3 après 1 an : stable Moi je vois différentes phases : stable => instable => stable => instable => stable Là ça va quand même faire 2 ans que la HC3 est super stable, et même plus que la HC2 ne l'a jamais été, même avec ses derniers firmwares. Tu noteras que je mets la HCL de coté c'est c'est un produit de merde qui n'aurait jamais dû exister. Ressources matérielles bien trop limitées, elle n'a jamais été stable, quelque soit le firmware. Elle a fait plus de mal aux clients de Fibaro, et donc à Fibaro eux-même, qu'autre chose. Je pense que tu as tendance à mélanger les produits (je le redis, la HCL est un produit qui n'aurais jamais dû exister), la stabilité des firmwares publiés, et la fréquence des firmwares publiés. Sur ce tout dernier point, on dirait bien que Fibaro a réduit la cadence de publication des firmwares, depuis 6 mois environ. Mais ils sont toujours aussi stables. Précision : je parle des versions labellisées "stables", pas des versions "betas" bien sûr. En tout cas, si tu veux une dynamique de nouvelles fonctionnalités, de nouveautés et d'évolutions en tout genre, ça n'a jamais été vers Fibaro qu'il fallait se tourner. A l'heure actuelle, Home Assistant est le roi incontesté sur ce critère là.

Ton schéma est faux, mais avant de tenter de le corriger, je m'interroger sur l'utilité même de la présence de ce module. Si tu souhaites directement allumer ta lumière avec le module Diagral, alors quel intérêt d'ajouter un module domotique Fibaro ? Tu peux directement réaliser un des schéma présenté dans la doc officielle, ça fera le travail.

Beaucoup d'approximations dans ton message. Je ne trouve pas de trace du RP780X, tu es certain de la référence ? Surement une confusion avec le RP580X. Doc : https://www.diagral.fr/wp-content/uploads/2018/02/Recepteur_exterieur_RP570X_RP580X.pdf Ton schéma montre le RP580X avec du 230V, qui a bien une sortie contact sec libre de potentiel, donc cette partie du schéma entre le RP580X et le FGBS-222 est correcte (identique à mon schéma en première page) En revanche, je ne sais pas quel module "31840" tu as connecté en parallèle.... mais ça ne présage rien de bon vu qu'il est connecté au 230V de l'autre coté. Je te suggère de t'équiper d'une caméra lorsque tu réaliseras le branchement, car je suis curieux de la couleur des flammes. Penses bien à te mettre à l'abri pendant l'opération, ça serait dommage que tu finisses électrocuté. Bref, surement pas une bonne idée de câbler ainsi. Il te faut un module relai type FGS-214 pour piloter ta lumière (ou un FGD-212) Et c'est ta box domotique Homey qui allumera la lumière lorsque le FGBS détectera le changement d'état. Je ne peux pas te décrire cette étape, car la suite de mon tuto porte sur la HC2, je ne connais pas la Homey.

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.