Lazer

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é...)

En effet, probablement un appel de courant trop fort de la LED qui crame le FGD. Tu dis bien 211, donc première génération ? As-tu essayé avec des 212, la seconde génération, qui est censée être mieux protégée contre les surcharges ? J'ai remplacé quasiment tous mes 211 par des 212 chez moi, et de temps en temps (c'est rare, disons une fois tous les 3 mois) j'ai une alerte de surcharge dans les événements systèmes de la box. Et comme par hasard, cette surcharge n'apparait que là où j'ai des LED, jamais avec des ampoules incandescentes/halogènes. Comme quoi, le faible courant consommé par une LED est bien trompeur, comme je l'expliquais hier, c'est le courant d'appel à l'allumage qui fout le bazar.

ça commande à devenir un vrai beau petit projet Prochaine étape, une vue 3D de la maison avec les modules géolocalisés

Il n'y a aucun "bon" module pour piloter des néons, à cause justement de leur courant de démarrage qu'aucun module domotique ne peut supporter. Donc il faut utiliser le FGS avec soit un limiteur de courant, soit un contacteur de puissance. Perso je choisis l'un ou l'autre selon la configuration des lieux : est-ce que j'ai le tableau électrique à proximité, ou uniquement une boite d'encastrement derrière un interrupteur.

C'est un phénomène physique, électrique, ce n'est pas lié à un bug (sous entendu logiciel) du module. Les néons, c'est encore pire que les LED (encore que... ça dépend des LED...), ça provoque un appel de courant monstrueux, qui peut être 10, 100, voire 1000 fois plus intense que leur courant nominal, pendant un très court instant. Ce courant important crée un arc électrique au moment où le relai se ferme, et par échauffement colle les 2 lamelles métalliques. Par la suite, lorsque tu veux éteindre la lumière, c'est à dire ouvrir le relai, les lamelles restent collées et le relai ne s'ouvre donc pas... le courant continue de passer et la lumière reste allumée. Alors je vais pas vous dire que les lampes halogènes c'était mieux (ah zut je viens de le faire ), mais perso, dès que j'utilise n'importe quoi d'autre avec un relai (LED, néon, transformateur, etc) je protège systématiquement le relai avec soit un contacteur de puissance (Legrand) au format DIN dans le tableau, ou bien avec le micro limiteur de courant dont le lien a été donné sur le topic : https://www.amazon.fr/H-TRONIC-Marche-de-strombegrenzer/dp/B01DUHKQQ2/ Par ailleurs, 16 néons c'est juste énorme, c'est quoi la consommation totale ? Je ne serais pas surpris que tu t'approches dangereusement de la limite de puissance supportée par le module, qui est de seulement 6A, soit 1400 W pour une charge purement résistive (une lampe halogène donc), ce que n'est pas du tout, mais alors pas du tout, un néon, qui comme dit, peut avoir un courant d'appel de facilement 100x plus que son courant nominal. Bref, tu joues avec le feu, tu as même de la chance de n'avoir seulement collé la lamelle du relai, car à la longue, cet échauffement localisé pourrait avoir de plus graves conséquences.

Effectivement, on peut mettre plusieurs valeurs numériques pour la variable ProdThresUp, séparées par des virgules. Et normalement ça fonctionne, et ta syntaxe est correcte... en tout cas la dernière fois que j'ai essayé, car actuellement en production, je n'exploite plus cette possibilité (j'ai une seule valeur)

"Soon" ils ont dit sur le forum officiel. Et chacun sait que "soon" dans l'espace-temps polonais, qui est un univers parallèle du grand multivers intergalactique, est une notion très relative... Einstein lui-même disait que le temps est relatif, voilà qui donne toute crédibilité à Fibaro.

Je crois me souvenir que certains modèles de Freebox étaient bridés à 800 Mbit/s en mode bridge, certainement lié à une limitation matérielle. Je n'ai pas de souci, mon débit dépasse régulièrement les 900 Mbit/s, en fait c'est le disque dur de mon NAS qui sature avant pendant les grosses sessions de téléchargement, donc c'est tout bon. Note au passage, je ne comprends pas l'intérêt des offres à plusieurs gigabits actuellement commercialisées... à part télécharger des ISO de Linux à longueur de journée directement sur un SSD NVMe, et se pignoler devant des SpeedTests, j'ai pas encore trouvé. Peut être pour certains besoins très particuliers, mais dans ce cas améliorer l'upload serait plus utile, pour de l'hébergement notamment.

Quand on avait l'ONT (le petit boitier avec le convertisseur optique) séparé de la Livebox. Mais ça restait complexe, il fallait certains routeurs (Ubiquiti Edgerouter par exemple) qui permettaient de patcher le client DHCP pour forcer certaines options non standards sur le réseau Orange.... qu'Orange avait la fâcheuse habitude de modifier de temps en temps, donc fallait suivre les forums spécialisés... Avec la Livebox récente, je ne pense pas que ça soit encore possible. C'est une des raisons pour lesquelles je reste chez Free, même si le réseau est un peu moins bon que chez Orange (parfois des chutes de débits), au moins on peut mettre la Freebox en mode bridge ce qui simplifie beaucoup l'utilisation d'un routeur tiers, sans se taper du double NAT.

Oui chez moi le QuickApp fonctionne toujours.

Le swagger c'est avant tout une doc de syntaxe en ligne de l'API. Il y a la possibilité d'effectuer des petites requêtes basiques pour tester l'API en question, mais c'est limité. Sur la HC3, on peut exécuter de vrais programmes écris en LUA dans des QuickApps, ou des Scènes. J'ai pas testé l'écriture de programme RGBW personnalisé pour ce module, peut être que le Swagger suffit, mais je ne sais pas.

Vu le support très limité du Zigbee sur HC3, j'ai des gros doutes sur la comptabilité de ce module. Le seul topic qui en parle sur le forum traite en réalité d'un autre module, sans réponse également... :

Ce n'est pas une URL valide, c'est pour ça que curl la rejette. Tu utilises un raccourci qui est implémenté dans les navigateurs uniquement, et encore, c'est en suris, car cette syntaxe est dépréciée et ne devrait plus être utilisée depuis quelques années. Donc il faut que tu utilises l'URL normale (sans le user/password) et que tu donnes le user et le password en argument de ta commande curl. Tu as de nombreux exemples de curl en ligne, selon si tu veux donner le user et le password en clair dans la ligne de commande, ou bien encodé en base64, etc

Non, ça n'arrivera pas. Le détecteur de fumée est un appareil sur batterie, endormi, qui n'écoute pas le réseau Z-Wave, tu ne peux pas le contrôler à distance. C'est un fantasme lu sur de nombreux blogs et forums, mais non, il n'a jamais été possible de faire sonner un détecteur de fumée Fibaro à distance, contrairement à ce que j'ai parfois lu... les rumeurs sont tenaces. Dans ces conditions, modifier la valeur du device (qui n'est que la représentation du device dans la base de données de la box) n'a plus aucun intérêt. Sinon pour info, tu peux aussi le faire en requête de type GET avec callAction et la méthode updateProperty, c'est ce qu'on a appris à faire pour les QuickApps, et ça fonctionne (à priori) pour tous les modules. Avantage d'une requête GET, on peut le faire directement depuis la barre d'URL du navigateur, sans plugin complémentaire. Et donc en LUA aussi, forcément. /api/callAction?deviceID=123&name=updateProperty&arg1=value&arg2=true