Lazer

Bonne nouvelle, les QuickApps refonctionnent depuis ce matin. Surement un retour arrière sur les serveurs Web de Stellantis. Espérons que ça dure

Effectivement, je confirme pour le CPU, même comportement sur ma box de test

Qubino c'est pas la première fois que Fibaro ajoute le support de leurs produits, ça s'est déjà produit plusieurs fois depuis que la HC3 est sortie. Mais clairement, j'ai la même réaction que toi Jojo, à chaque fois que je lis ça, ça me fait tout drôle connaissant l'historique entre les 2 marques En tout cas pas mal de nouveautés intéressantes, c'est une très bonne mise à jour je trouve ! Et Fibaro semble avoir renforcé ses tests internes avant publication, donc on va dire que c'est une beta presque stable

Je me suis permis de déplacer ton message qui a plus sa place ici.

Tout vient à point à qui sait attendre Également une nouvelle version de l'application mobile disponible sur les stores/markets.

Firmware HC3 & HC3L Version 5.142.83 Beta Thank you for using our gateway! Be sure to update to the latest version to enjoy new features and improvements. Main features: 1. Added Auto and Manual Mode support for Elero devices. From now on, for devices that support mode switching, you can exclude specific devices from automation (such as scenes or profiles) by changing a single option in the sidebar. 2. Added Z-Wave Network Diagnostics tab. Now, for both versions of the Z-Wave engine, the system allows for the analysis of traffic and network issues for diagnostic purposes. 3. Added Support for Nice and Elero devices in Gateway connection. As part of expanding the system's capabilities, support for Nice and Elero protocols has been added in Gateway Connection feature, improving connectivity between hubs. What's new: Update Minor translations fixes. Dashboard Added the ability for the administrator account to hide "Add Device" and "Add Scene" tiles on the dashboard in general hub settings. FTI Added the ability to restore user backups saved in the Cloud during the FTI process. Improved Z-Wave engine selection during FTI for hubs no longer connected to the Master gateway. Garden Added the ability to perform a sequence test and manually start irrigation from the Garden Panel. Elero Improvements for waking up Elero devices. Energy Improved tooltip readability for tariffs in the Energy Panel. Power measurements for hidden devices are now excluded by default. Nice Improvements in handling dead devices. Added support for partial opening state for gates. Added support for battery-operated devices synchronization. Users Improvements for user management - simplifications in Remote Access sharing. Other Improvements in user password validation. Refreshed modal appearance in the interface. Increased character limit for variables in the hub. Database optimizations. Quick Apps Added switch support. Added dropdown list support. Changes for control identifiers. Scenes Added the ability to manually start watering sequences from a scene. In block scenes, added new blocks related to the energy panel: Current Production, Current Consumption, and Current Balance. Added automatic authorization for API of system elements in Lua. Devices Organized roles for blinds in Linked Devices. Organized the list of roles and categories for devices. Added hysteresis settings for humidity controller and thermostats in Linked Devices. Zigbee Added support for smoke, pressure, gas, volatile organic compounds, vibration, and presence sensors. Added support for device role settings. Added support for device's temperature sensors. Z-Wave Added support for Qubino Flush Shutter DC devices. Changed the default wake-up interval value for known old-generation devices. Updated support for Aeon Multisensor 6. Added pin support for Danalock V3 lock. Introduced fixes for removing damaged Z-Wave nodes.** Added support for old-generation FGFS-101 and FGK-101. Bug Fixes: Climate Resolved an issue with thermostat handling from the climate panel for Fahrenheit units. Gateway Connection Fixed the inability to configure Lifeline association for devices from Slave hub in some cases. Backups Fixed behavior for local backup limit. Fixed occasional backup execution issues. Nice Fixes for handling parameters for BiDi-Multisensor. Resolved issues with Nice ON4E remotes. Partial opening button missing for Nice gates. Missing waiting icon for pending actions when changing parameters for sleeping devices. Improved handling of low battery notifications for BiDi-Multisensor. Fixed Nice device handling after backup restoration. Fixes for device parameter configuration mechanism. Users Fixed granting permissions for empty rooms. Stylistic fixes for dark theme in access management. Plugins Incorrect reporting of Tedee lock status during temporary loss of cloud services. Fixed handling of latch retraction for Tedee lock. Fixed generating a new authorization code for Tedee lock. Minor fixes in Dahua camera plugin configuration. Fixes for CoolAutomation plugin. Other Occasional issue with web interface content not loading. Overwriting room categories to "Other" during editing in the modal. Minor UX fixes for Devices and Network tabs. Quick Apps Fixed assigning QuickApps to rooms when adding a new integration from the Dashboard. Fixed Fahrenheit handling for thermostat-type QuickApps. Fixed handling of special characters for secret-type variables. Scenes Filled out missing translations for thermostat actions in block scenes. Fixed renaming scenes from the editor. Fixed action handling for thermostats (temporary schedule override). Devices Fixed color controller handling in Linked Devices. Fixes for Linked Device support for blinds. Fixed linked devices entities list after opening the "General" tab in devices settings. Zigbee Fixes for forcing device removal. Improved ZigBee device counter in the configuration tab. Z-Wave Fixed temperature conversion for the first Fahrenheit reading. Fixed estimated next device wakeup time display. Improved communication performance. Added support for new versions of MCO devices - MH-S412, MH-DT411. Eliminated issues with zeroing wakeup time for FGD-002. * - Does not apply to HC3L (Home Center 3 Lite). ** - Applies only to Z-Wave 3.0 engine.

Bienvenue sur le forum

Oui.

En fait tu peux également tout faire tourner le serveur Web et la base de données sur Windows, avec LAMP c'est facile à mettre en place. Mais je ne suis pas très fan de Windows sur un serveur, trop lourd à mon gout. Disons que c'est plus adapté à d'autres types d'usage, type serveur Active Directory, Excange, etc, bref tout ce qui fait partie de l'écosystème Microsoft.

Ah, je viens de réaliser que ce fameux module " 31840 " dont je me demandais plus haut ce que c'était, est en réalité une alimentation 12V destinée à alimenter le FGBS. Donc oui effectivement vu comme ça, c'est fonctionnel, et finalement très similaire au montage que j'ai fait.

Certainement pas la Freebox, qui est en location, donc ne t'appartient pas. Quand tu changeras de box et/ou de fournisseurs, est-ce que tu pourras facilement récupérer les données pour les conserver ? Tout l'intérêt de DomoCharts c'est de conserver les données sur le long terme, donc ce point me parait essentiel. (au delà de la migration futur d'équipement matériel, il faut également penser aux sauvegardes, idéalement quotidiennes, pour se prémunir en cas de crash) Je ne connais pas le CuBox, mais je suppose que tu peux y installer l'OS de ton choix... un Linux me parait tout adapté pour cet usage. Après selon ton niveau de compétences ou ton appétence pour l’apprentissage, tu peux probablement le virtualiser avec Proxmox par exemple, pour créer différentes VM. Perso je suis dans une config hybride : - la base de données de DomoCharts est gérée par MariaDB sur le Synology (qui est en fait une VM Xpenology de mon serveur) - sur ce même serveur (virtualisé avec ESXi), j'ai une VM sous Linux dédiée pour le serveur Web, dans lequel j'y ai mis les pages PHP de DomoCharts - entre les 2, j'ai un firewall pour filtrer tous les flux (pour la sécurité) Un peu tordu à mettre en place, mais efficace. Ainsi j'ai la visualisation des graphs DomoCharts qui est accessible aussi bien en local qu'à distance, mais la DB SQL reste bien protégée dans le LAN.

OK, donc à la fois déclencher la lumière sur intrusion, et aussi l'allumer à la demande. Dans ton schéma, tu as branché le module Diagral sur la sortie Q du FGS, ça ne peut pas fonctionner. La sortie Q, elle va vers la lampe (la lampe, elle, est branchée entre Q et le neutre) Donc le contact sec de ton module Diagral, il va agir comme un interrupteur du FGS, donc il faut le câbler comme tel (voir la doc du FGS) - Le Commun sur la Phase - Le Travail sur l'entée S1 du FGS A noter que je te conseille le FGS-213 plutôt que le FGS-214, car tu auras la mesure de consommation, et pas besoin de câbler le IN. Oui parce que sur le FGS-214, il faut câbler le IN sur la Phase comme indiqué dans la doc. Enfin, si ta lampe est dimable (halogène ou LED dimable) tu peux utiliser un FGD ce qui est encore plus sympa à l'usage : soft start & stop, c'est plus agréable.

OK, mais ça ne t'avancera pas à grand chose... c'est une grosse requête SQL bien balèze qui va chercher l'information dans différentes tables de ma propre base de données.... il y a du DomoCharts, mais pas uniquement. Ce qui m'a donné du fil à retordre, c'est la prise en compte de la couleur des jours TEMPO. SELECT DATE_FORMAT(Jour, $myPeriode) AS "Période", SUM(Production) AS Production, SUM(Soutirage) AS Soutirage, SUM(Injection) AS Injection, SUM(Production) - SUM(Injection) AS "Autoconsommé", CAST((SUM(Production) - SUM(Injection)) / SUM(Production) * 100 AS DECIMAL(5,2)) AS "Taux", SUM((Production - Injection) * Tarif_kWh_soutirage) AS "Économie", SUM(Injection * Tarif_kWh_injection) AS "Vente" FROM ( SELECT energy_day.date AS "Jour", SUM(energy_day.sum_value) AS "Production", CAST((COALESCE(teleinfo.BASE, 0) + COALESCE(teleinfo.HCHP, 0) + COALESCE(teleinfo.HCHC, 0) + COALESCE(teleinfo.HCJB, 0) + COALESCE(teleinfo.HPJB, 0) + COALESCE(teleinfo.HCJW, 0) + COALESCE(teleinfo.HPJW, 0) + COALESCE(teleinfo.HCJR, 0) + COALESCE(teleinfo.HPJR, 0)) / 1000 AS DECIMAL(6,3)) AS "Soutirage", CAST(COALESCE(EAIT, 0) / 1000 AS DECIMAL(6,3)) AS "Injection", CASE WHEN x.Tarif_Jour = "TH" THEN tarif.kWh_Base WHEN x.Tarif_Jour = "BASE" THEN tarif.kWh_Base WHEN x.Tarif_Jour = "HP" THEN tarif.kWh_HP WHEN x.Tarif_Jour = "HPJB" THEN tarif.kWh_HPJB WHEN x.Tarif_Jour = "HPJW" THEN tarif.kWh_HPJW WHEN x.Tarif_Jour = "HPJR" THEN tarif.kWh_HPJR ELSE 0 END AS "Tarif_kWh_soutirage", tarif.kWh_EAIT AS "Tarif_kWh_injection" FROM domocharts_energy_day energy_day LEFT JOIN domocharts_device device ON energy_day.device_id = device.id LEFT JOIN teleinfo_day teleinfo ON energy_day.date = teleinfo.rec_date LEFT JOIN teleinfo_tarif tarif ON teleinfo.tarif_id = tarif.id LEFT JOIN ( SELECT a.rec_date AS "rec_date", a.PTEC AS "Tarif_Jour" FROM (SELECT rec_date, PTEC, COUNT(PTEC) as "Compte" FROM teleinfo WHERE $__timeFilter(rec_date) GROUP BY rec_date, PTEC) a LEFT OUTER JOIN (SELECT rec_date, COUNT(PTEC) as "Compte" FROM teleinfo WHERE $__timeFilter(rec_date) GROUP BY rec_date, PTEC) b ON a.rec_date = b.rec_date AND a.Compte < b.Compte WHERE b.rec_date IS NULL ORDER BY a.rec_date ) x ON energy_day.date = x.rec_date WHERE $__timeFilter(energy_day.date) AND energy_day.device_id IN (669, 658) GROUP BY Jour ) t GROUP BY Période ORDER BY Période Elle permet de générer les données présentées dans le tableau de gauche. Puis tous les graphiques sont affichées à partir de ce tableau, afin de ne pas multiplier les requêtes inutilement (cette seule requête prend 1 à 2 secondes pour s'exécuter, ce qui est déjà assez long) Car c'est ça qui est bien dans Grafana, on peut réutiliser des données déjà présentes sur le dashboard sans avoir besoin d'aller les rechercher à la source. Un autre truc sympa, on le voit tout en haut à gauche, un petit sélecteur permet de choisir la période de regroupement des données, je peux ainsi afficher par jour, semaine, mois, année, et même total : Par exemple avec le détail par jour, ça produit un tableau avec des centaines de lignes, et un graph très (trop ?) détaillé : Tout cela grace à la variable $myPeriode et au GROUP BY qu'on voit dans la requête SQL. Si ça peut te donner des idées...

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