Aujourd’hui il faisait beau et ça faisait un moment que j’avais prévu de le faire… Bref, écrire l’explication ici est plus long qu’à réaliser l’installation 
A priori ça marche et ça donne ça cette après-midi
c’est pas cher, mais possiblement ça marche pas si mal… phase de test en cours
n’hésitez pas à ajouter votre grain de sel (l’idée n’étant pas de commander un nouveau matériel, mais d’améliorer le truc au besoin)
Sommaire
1. C’est quoi ça ?
2. on se lance (15min d’installation, 15 min de config)
3. résultats
4. ça marche comment ?
1. Pourquoi un pyranomètre (mesure de l’ensoleillement) ?
- C’est l’énergie solaire E_solaire [W/m²] qui me permettra d’automatiser l’ouverture/fermeture des volets en mon absence pour l’hiver (ouvrir pour gagner du solaire) et l’été (fermer au contraire), sachant que les données météo sont complètement erronées comme signalé ici ou là
- Contrairement à un capteur de luminosité, c’est beaucoup plus fiable car ça dit si ça chauffe vraiment (il peut y avoir une bonne luminosité sans soleil)
→ donc j’éviterai d’acheter une sonde de luminosité bas de gamme et plus chère qui me donnerait des valeurs inutilisables - un vrai pyranomètre ça coûte très cher… mais on veut juste ouvrir/fermer les volets, pas faire des mesures de compétition !
2. Installation [Facile et rapide]
2A. Matos nécessaire (15 min)
2 sondes de température extérieures
(je n’en compte qu’une si on considère qu’on a déjà une sonde extérieure à l’ombre)
→ le principe repose sur l’utilisation d’une sonde de température dans un bocal en plein soleil comme sur la photo
- une sonde de température (j’en avais commandé un peu trop des sondes LYWSD03MMC zigbee à 5€ )
- un pot de crème dessert en verre retourné scotché à un fond en plastique pour l’étanchéité (le plus long c’est le scotch)
- on fixe bien dans le pot de fleur pour pas que ça s’envole avec le vent
on appelera ce capteur
sensor.solar_temperature
- Il faut aussi une 2ème sonde température extérieure à l’ombre pas trop loin (j’en avais déjà 2)
on appelera ce capteur
sensor.ext_temperature
à propos du risque de surchauffe
de l’électronique du capteur et/ou de décharge accélérée de la pile… le plus sûr c’est de passer avec une sonde déportée (p. ex. prêt à l’emploi ou en diy)
Sinon, si comme moi vous utilisez le capteur basique et pour plus d’info sur ce à quoi on s’expose cliquer ci-dessous
(ou demander @WarC0zes avec ses sondes dans son congélo)
Conseils et données supplémentaires
-
La première chose à faire c’est d’espacer le temps de remonter des mesures (ça consomme de la batterie… perso je reste sur 5 min)
-
piste d’amélioration (à tester) pour mieux protéger l’électronique sans altérer la mesure pour les plus prudents→ emballer le capteur dans du papier à bulle ou mousse isolante (pour l’hiver) + papier d’aluminium (pour l’été)
→ tout en laissant bien ouvert la circulation d’air du côté du capteur de température (pour la précision de mesure) -
diminution de la durée de vie des batteries (piles bouton CR2032) en fonction de la température
d’après https://www.bestartech.com/wp-content/uploads/2020/09/SCR2032_726-BTI.pdf -
Et vitesse de décharge
d’après https://www.murata.com/en-eu/products/en-gb/products/productdata/8801520320542/CR2032W.pdf
2B. Config Home Assistant (15 min)
Il suffit de créer 3 sensors templates = capteurs virtuels (5 min / sensor)
→ 
> appareils et services > Entrées > Créer une entrée > Template > Modéliser un capteur
dt_solaire°C- unité de mesure: °C
- Classe d’app: Température
- Classe d’état: Mesure
- Modèle d’état:
{{ states('sensor.solar_temperature')|float-
states('sensor.ext_temperature')|float }}
-
wind_speedm/s
Pour la vitesse du vent, en bon utilisateur lambda je n’ai pas une station météo de compet à dispo, donc j’ai fait un sensor virtuel tout bête… par exemple en recopiant celui de mon package chauffage si vous ne l’avez pas, je remets le code ici- unité de mesure: m/s
- Classe d’app: wind_speed
- Classe d’état: Mesure
- Modèle d’état:
{% set weather_entities = states.weather | selectattr('attributes.wind_speed', 'defined') | list %} {% if weather_entities | length > 0 %} {{ (weather_entities[0].attributes.wind_speed | float) / 3.6 }} {% else %} {{ 0 }} {% endif %} -
EsolaireW/m²- unité de mesure: W/m²
- Classe d’app: Irradiance (éclairement en bon français…anglicisime trop souvent utilisé
) - Classe d’état: Mesure
- Modèle d’état:
{% set Esol= states('sensor.dt_solaire')| float*(4+4*states('sensor.wind_speed')|float) %} {% if Esol < 0 %} {{ 0 }} {% else %} {{ Esol }} {% endif %}
C’est fini !
3. On obtient quoi comme mesures
Quelque chose comme ça
On peut utiliser au choix la surchauffe dans le bocal (DT_solaire), mais je préfère largement E_solaire, même si ce n’est pas complètement précis (cf. partie suivante)
4. Pourquoi ça (devrait) marche(r)
Le bocal est en quelque sorte une maquette de l’habitation volets ouverts… on voit l’évolution de température liée à l’ensoleillement (par soustraction de la température de l’air)- ça correspond à peu près à ce qu’on appelle la température sol-air (pas les missiles), cf ici → Sol-air temperature - Wikipedia
- la formule étant Tsol,air = Text + αEsol / h
- Et même si ce n’est pas complètement juste, j’assume que l’absorption solaire α = 1
et que h = 4 + 4 x Vwind en W/(m²°C) (norme européenne)
quid du temps de réponse
- l’habitation ne va pas chauffer en 5 minutes au moindre rayon de soleil… donc si le capteur répond en 5 minutes environ c’est plutôt bien
- de plus l’inertie thermique du capteur est plutôt faible
- par contre il ne faut pas s’attendre à une réponse en quelques secondes… mais comme ce n’est pas nécessaire on va le prendre comme un avantage en réglant l’intervalle d’envoi des données zigbee à 5min pour économiser la batterie (le capteur étant à l’extérieur, j’imagine que ça consomme un peu plus de batteries l’envoi de données… une bonne raison d’économiser les batteries)
Cas d’usage pour gérer les stores/volets roulants
- s’il y a du vent ou s’il fait froid ça devrait bien se passer, la température T_solar devrait rapidement s’équilibrer → la chute de Tsol,air en hiver sera rapide pour fermer les volets dès le coucher du soleil sans attendre
- dès qu’il y a un brin de rayon de soleil ça chauffe vite! → parfait pour fermer en été ou ouvrir en hiver
- seule la baisse en été le soir peut être plus lente en l’absence de vent, mais le terme 4+4Vwind force la baisse si Vwind est faible, et en plus c’est le cas le moins utile (pas nécessaire d’ouvrir les volets si la température extérieure est encore trop élevée, ça ne va pas rafraîchir)
est-ce que j’ai oublié les infrarouges (IR) dans la formule T_sol,air ? (à partir de laquelle je calcule l’énergie solaire en W/m²)
A priori non car ma sonde ext est sous abri, et que le pot de verre sur Tsolar coupe les IR aussi…
Phase de test en cours…
On voit que la nuit T_solar est à peu près égale à T_ext (logique), bien que ce ne soit pas garantie à 100% : précision des capteurs, effets de la pluie, etc… mais en gros ça devrait marcher… on espère 
Bonus
Si on avait du temps à perdre 
, on pourrait faire une maquette de notre habitation avec un capteur dans chaque pièce (en isolant chaque pièce les unes par rapport aux autres) et des mini-fenêtres équivalentes aux vraies, ça donnerait le vrai ensoleillement des baies vitrées selon chaque orientation, avec la vraie surchauffe théorique permettant de piloter les stores en plus d’être amusant pour les (grands) enfants
. Je cherche qqchose comme çà pour intégrer la variable ensoleillement dans un moteur de régulation production solaire-injection réseau. Mais je suis débutant HA , je vais donc creuser la partie création des éléments . J’attends vos résultats d’essai. Cdlmt, JP
, normalement ce que je viens de donner comme explication ce n’est vraiment pas difficile pour se lancer : il faut juste 2 sondes de température et tout se fait via l’interface graphique