Bonjour,

Je travaille sur un petit projet perso et j'aurais besoin de vos lumières (sans mauvais jeu de mots). J'aimerais monter un système de détection de fuites de fluide frigorigène avec des LED UV. Le principe c'est d'ajouter un traceur fluorescent dans le circuit et de balayer avec de la lumière noire pour repérer les micro-fuites.

J'ai trouvé des LED UV 395nm à pas cher mais je me demande si c'est suffisant ou s'il faut du 365nm pour une bonne fluorescence. Pour ceux qui voudraient en savoir plus sur les différences entre longueurs d'onde UV, il y a pas mal de documentation technique disponible.

Est-ce que certains d'entre vous ont déjà utilisé de la lumière noire dans un contexte technique comme celui-là ? Quelle longueur d'onde vous recommanderiez ?

Merci d'avance !

Bonjour,
Mon routeur va récupérer les mesures de puissance dans mon système photovoltaïque Enphase triphasé (équipé de pinces ampèremétrique sur chaque phase).
Venant tout juste de passer le routeur en V17 (V17.17 exactement), je m'attendais à voir dans la page de données brutes du routeur des données des trois phases (puissances et/ou intensités) mais rien ne remontent de plus que d'habitude.
Ai-je mal compris cette nouveauté de la v17 ?  cela ne fonctionne t-il pas dans le cas où l'on mesure les puissances via Enphase ?

Quel est votre retour d'expérience ?

Pour info, j'ai besoin de ces données pour mieux piloter ma batterie Zendure branchée sur une des phases.

Cordialement
Eric

Bonjour,

Je vous contacte au sujet d'un bug présent dans le firmware 17.17 de votre Routeur RMS ECS (ESP32 - CCB:A7:68:A5:74).

J'ai constaté que depuis la mise à jour de Home Assistant en version 2026.4, une erreur apparaît dans les journaux lors du traitement du message MQTT discovery de l'entité 'Linky_ECS_Code_Tarifaire' : On vous l'a peut-être déjà signalé mais je suis nouveau sur le forum.

Ci-dessous ce que remonte le journal de HA.

Enregistreur: homeassistant.components.mqtt.entity
Source: components/mqtt/entity.py:159
intégration: MQTT (documentation, problèmes)
S'est produit pour la première fois: 15:33:57 (1 occurrence)
Dernier enregistrement: 15:33:57

Error 'expected SensorDeviceClass or one of 'date', 'enum', 'timestamp', 'absolute_humidity', 'apparent_power', 'aqi', 'area', 'atmospheric_pressure', 'battery', 'blood_glucose_concentration', 'carbon_monoxide', 'carbon_dioxide', 'conductivity', 'current', 'data_rate', 'data_size', 'distance', 'duration', 'energy', 'energy_distance', 'energy_storage', 'frequency', 'gas', 'humidity', 'illuminance', 'irradiance', 'moisture', 'monetary', 'nitrogen_dioxide', 'nitrogen_monoxide', 'nitrous_oxide', 'ozone', 'ph', 'pm1', 'pm10', 'pm25', 'pm4', 'power_factor', 'power', 'precipitation', 'precipitation_intensity', 'pressure', 'reactive_energy', 'reactive_power', 'signal_strength', 'sound_pressure', 'speed', 'sulphur_dioxide', 'temperature', 'temperature_delta', 'volatile_organic_compounds', 'volatile_organic_compounds_parts', 'voltage', 'volume', 'volume_storage', 'volume_flow_rate', 'water', 'weight', 'wind_direction', 'wind_speed' for dictionary value @ data['device_class']' when processing MQTT discovery message topic: 'homeassistant/sensor/Linky_ECS_Code_Tarifaire/config', message: '{'device_class': '', 'device': {'sw_version': '6.01_RMS', 'configuration_url': 'http://196.165.0.183', 'hw_version': 'ESP32-D0WD-V3 rev.3', 'model': 'ESP32 - CCB:A7:68:A5:74', 'identifiers': ['CCB:A7:68:A5:74'], 'manufacturer': 'F1ATB - https://f1atb.fr', 'name': 'Routeur - RMS - ECS'}, 'state_topic': 'homeassistant/Linky_ECS_state', 'unique_id': 'Linky_ECS_Code_Tarifaire', 'value_template': '{{ value_json.Code_Tarifaire|default(0)| round(0) }}', 'unit_of_measurement': '', 'name': 'Linky_ECS Code_Tarifaire'}'


L'erreur remonte a chaque redémarrage de HA mais ne génère pas de disfonctionnement.

Cordialement

Bonjour,
J'ai enfin mis en place mon premier routeur solaire f1tb, merci andré pour ton travail incroyable.

Tout semble fonctionner à merveille hormis un petit bug pour la marche forcée de nuit.
Je pense que je ne sais pas faire, par conséquent ça ne fonctionne pas comme attendu.

J'ai conditionné la marche forcée entre minuit et 6h00 à condition qu'il y ait eu moins de 1h20 de chauffe en journée.
Cette condition semble fonctionner.

Le problème:
- sur une journée nuageuse , le CE s'enclenche bien en marche forcée à minuit mais il ne chauffe que 1h20.

Je fonctionne avec un relais ssr.
Je vous met ici les captures d'écran.

Une idée du probleme ?
Merci

Pièces jointes

Miniature(s)
           

Bonjour André,
Encore une fois merci pour cet outil, je l'utilise depuis quelques jours et toute la famille adore.
L'age de la glycémie qui est affiché en dessous de l'heure est une information très importante car si celui ci est élevé la glycémie affichée est peu significative.

A l'heure actuelle si l'age de la glycémie est supérieur à 20 minutes l'age s'affiche en rouge, ce qui est bien mais la dernière glycémie et la tendance associée restent affichées au centre de l’écran.
Quelqu'un qui ne ferait pas attention à l'age en rouge pourrait penser que la glycémie affichée est actuelle ce qui n'est pas le cas.

Je propose de masquer les informations de la glycémie si son age est supérieur à 20 minutes est d'afficher à la place le message "Attente glycémie".
Le changement est très simple, à la ligne 35 de pageAccueil.cpp il faut remplacer ce if : 

Pièces jointes

Miniature(s)
   

Bonjour
J'ai fini mon installe comprenant 
Routeur maitre vers 17.07
esclave esc vers 17.06
esclave chauffage vers 17.17
 cela fonctionne j'attends juste mes 2003 pour ma carte 3 relais  et 1 SSR41 

J’essaie de tester pour le cumulus l'action >57  <=60 ( si juste <60 marche bien avec rajout >57 marche pas donc  je re teste.
j’essaie aussi de trouver pour faire une action : exemple active de 11h à 20h par exemple sur mon relais cumulus ou xx
Je voudrais savoir pour la mise à jour sur pc vu que j'ai 3 versions différentes sauf si cela gêne pas le fonctionnement car toutes en vers 17.xx,
mais si je dois y passer.
 Cette mise à jour si je comprends bien doit être un formatage et une nouvelle  reprogrammation , les paramètres et  actions  sont conservé. ou pas! (cela sur installation rapide du logiciel ) comme la 1er foi
sinon j'ai mes sauvegardes sur fichier copie collé sur .ods déjà bien 
mais  mes sauvegardes en  .CSV comment les lire et Json.
J’espère être lisible pour vous.
Merci de votre aide

Ps: Merci  à Sgb31 pour Wireguard sur Free, tuto super et résultat génial, testé a 300km, Merci

Bonjour,

j'ai comme projet de faire un routeur solaire pour mon cumulus.

Je suis donc en triphasé, avec une installation solaire également en triphasé.

Mon cumulus en mono est sur la phase n°3 j'ai un Shelly qui me donne les infos dans mon tableau électrique via wifi.


Ma question, Est-ce que le routeur F1atb peut m'aider à injecter dans le cumulus en gérant uniquement la phase 3 en mesure ?pour ensuite remplir son role d'injection du trop produit.


Cordialement

Bonjour André,


Je vois que le fichier Solar_Router change de nom à chaque version:
Solar_Router_V17_16.ino,
Solar_Router_V17_17.ino

Serait il possible de garder le nom unique Solar_Router.ino, de cette facon les modifications effectuees seraient plus facilement tracable en faisant le diff entre 2 versions du repo, le 'rebasing' de ma branche sur la derniere version se ferait de facon automatique.

De plus avec Arduino IDE, je suis obligé de changer le nom du repertoire à chaque version pour qu'il corresponde au nom du fichier   Solar_Router_VX_Y

Merci, et beau travail sur F1ATB !

Laurent

Bonjour,

J'ai voulu tester le boost CACSI mais je ne voyais pas d'effet

En debuggant par telnet, j'ai vu que le calcul :
Ki = Ki * GainCACSI;
n'était jamais effectué

En regardant de plus pres le code, j'ai vu qu'en fait la variable Ki n'etait pas initialisée au bon endroit

J'ai mis une issue sur le repo Gitlab, je donne le patch a appliquer:

https://github.com/F1ATB/Solar-Router-F1ATB/issues/9

Bon week end
Laurent

Je réouvre le sujet des temporisations parce que ça ne me donne pas ce que je veux.
Je simule le courant sur une entrée UxI ce qui me permet de bien voir comment ça réagit. Mes réglages sont ON si <150, OFF si >500, tempo de 60 secondes.

C'est bien comme j'avais dit dans un post précédent, l'état de la sortie se met à jour à période fixe (la tempo) en ne prenant pas en compte ce qui se passe au milieu de cette période. Ça ne me permet pas, par exemple, d'éviter les variations de mon four. L'action qui a une temporisation va marcher au hasard (en apparence) plutôt que sur la condition "si la puissance est supérieure à x pendant 1 minute", faire ci ou ça.
Sur mon premier graphe, la période commence à peu près toutes les minutes entières de la courbe orange (avec un léger drift qui va en augmentant).

En faisant ces tests, j'ai aussi remarqué que si je laisse l'écran défiler, sur la courbe des ouvertures, je vois bien ce qu'il se passe en réalité. La courbe montre bien l'état de la sortie telle qu'elle apparaît aussi dans le cadre " Etat actions".
Par contre, si je fais un refresh de la page, la courbe des ouvertures ne montre plus l'état réel de la sortie mais celui des changements d'état avant la temporisation (pas l'état de la gpio).

Deux captures d'écrans 1 et 2 sont attachées pour montrer ça. Visiblement le signal enregistré dans le tableau de mémoire pour la courbe n'est pas le même que celui affiché en direct. Je n'ai pas encore trouvé où ça se trouve dans le code. C'est aussi la valeur qui est envoyée si c'est utilisée comme condition pour une action sur un autre ESP externe (cad, pas la valeur après la temporisation).
       


J'ai testé une petite modification de code qui me donne ce que je pense être une bonne temporisation. Capture d'écran 3. Il faut x secondes dans un état pour la sortie change.
   

Toujours le même "problème" sur la courbe après refresh.
   

Quel est l'avis de la communauté sur les temporisations (modifiée ou ok comme c'est?), l'affichage (à corriger ou pas?) et l'envoi de l'état sur un autre ESP (envoi devrait être de l'état temporisé ou pas?)