Prévisions météo en open data, détaillées, dont certaines avec un pas de 15'

Home Assistant - Tutoriels & Partages Automatisation / Scène / Script / BluePrint
1

Salut à tou(te)s,

J’ai pour projet d’avoir une automatisation qui en hiver ferme les différents volets roulants à la bonne heure l’après-midi (quand il n’y a personne à la maison), c’est-à-dire à partir du moment où les garder ouvert fait plus perdre de chaleur par déperdition, que ça n’en fait gagner grâce au rayonnement solaire.

Pour cela, il faut donc une prévision de ce rayonnement, qui varie bien sûr selon :

  • l’heure
  • l’orientation de chaque fenêtre (azimuth)
  • la latitude
  • la date dans l’année
  • l’inclinaison de chaque fenêtre : fenêtre classique (verticale***), ou fenêtre de toit plus ou moins incliné…
  • et la nébulosité.

(*** En appliquant éventuellement à l’inclinaison de chaque fenêtre verticale, une correction manuelle pour tenir compte de la nature du sol devant la fenêtre : car à rayonnement solaire égal, une porte-fenêtre orientée Sud sur une grosse surface ensoleillée et minérale (bitume, pavés…), chauffe probablement plus que la même porte-fenêtre avec la même orientation, mais donnant sur du gazon lui-même ombragé par des arbres situés plus loin…
Au lieu de l’inclinaison réelle de 90°, peut-être qu’il convient de saisir 84° ou 87° dans le premier cas, et 89° ou 90° dans le second cas…
(pour les surfaces vitrées situées au rez-de-chaussée, ou donnant sur grand balcon.)

Je commence par partager ici que j’ai pense avoir trouvé une source pour cette prévision :

Reste plus qu’à scrapper et traiter cette page :

https://api.open-meteo.com/v1/forecast?latitude=47&longitude=2&models=meteofrance_seamless&minutely_15=global_tilted_irradiance_instant&timezone=auto&forecast_days=1&tilt=88

Je pense que je vais essayer de la scrapper et traiter en PHP ou Javascript, pour en tirer la prévision de rayonnement à T+15’/30’/45’, puis scrapper ces 3 valeurs avec HA, et combiner cela avec l’évolution de la température intérieure de la pièce (chauffage coupé quand la maison est inoccupée), afin d’en déduire s’il est pertinent de fermer maintenant, pour les différents volets de la maison…

2

Salut,

Tu entends quoi par scrapper? C’est du JSON les données sont exploitables directement, scrapper c’est quand tu extrait des infos sur une page web pas prévue pour ça..
Alors c’est sûr avec les options que tu as choisi c’est plus compliqué.

Mais en changeant un peu tu peux demander uniquement les valeurs pour la prochaine heure, avec le parametre &forecast_minutely_15=4 :

https://api.open-meteo.com/v1/forecast?latitude=47&longitude=2&models=meteofrance_seamless&minutely_15=global_tilted_irradiance_instant&timezone=auto&forecast_days=1&tilt=88&forecast_minutely_15=4

Et du coup avec cette réponse, tu peux accéder aux prévisions directement en fonction de l’heure. T’as juste à coller ça dans un appel REST et dans le résultat tu peux directement utiliser :
json_value.minutely_15.global_tilted_irradiance_instant[0] pour la valeur dans le 1/4h en cours ou
json_value.minutely_15.global_tilted_irradiance_instant[1] et ainsi de suite pour les 1/4h suivants…

{
  "latitude": 47,
  "longitude": 2,
  "generationtime_ms": 0.0450611114501953,
  "utc_offset_seconds": 3600,
  "timezone": "Europe/Paris",
  "timezone_abbreviation": "GMT+1",
  "elevation": 137,
  "minutely_15_units": {
    "time": "iso8601",
    "global_tilted_irradiance_instant": "W/m²"
  },
  "minutely_15": {
    "time": [
      "2026-03-10T22:30",
      "2026-03-10T22:45",
      "2026-03-10T23:00",
      "2026-03-10T23:15"
    ],
    "global_tilted_irradiance_instant": [0, 0, 0, 0]
  }
}
1 « J'aime »
3

Salut

A mon avis se baser sur des prévisions qui du coup ne sont faites sur ton terrain pour adapter a ton cas particulier, n’est pas une bonne idée pour avoir un truc efficace.

Regarde plutôt a te faire un capteur d’irradiance ou de luminosité dont tu adapteras les résultats à chacune de tes fenêtres.

4

Le résultat dépendra effectivement de la fiabilité de ces prévisions.

Je vais effectivement mettre un capteur de luminosité justement pour comparer ses mesures à ces prévisions, et ainsi voir si ces dernières sont généralement bonnes ou pas.

Par contre fermer les volets sur la base d’un capteur ça ne serait pas satisfaisant, car la luminosité peut baisser pendant quelques demi-douzaine de minutes (passage de nuages), et pourtant après il peut encore rester ensuite une ou plusieurs période(s) « exploitable(s) » de forte luminosité (après départ(s) des nuages), et je ne veux pas que les volets roulants fassent trop souvent le yo-yo l’après-midi, sinon le risque est que ça finisse par coûter plus cher en renouvellement de moteurs, qu’en chauffage économisé… C’est pour ça que l’idéal serait de pouvoir utiliser cette prévision météo… à condition qu’elle soit fiable. On verra… La météo est une science qui n’a pas fini de progresser; peut-être qu’en 2026 cette fiabilité n’est pas encore suffisante, et peut-être que dans quelques années elle le sera…

5

Oui « scrapper » n’est peut-être pas le bon terme, je voulais dire « extraire les infos qui m’intéressent ».

Il faut que je vois si je peux faire un appel REST avec HA ou bien si je dois passer par un traitement extérieur.

7

Pour récupérer ces prévisions de rayonnement reçu du soleil, et pouvoir les utiliser dans des templates (de type sensor) qui seront des conditions pour déclencher les fermetures de volets, il faut que j’installe cette intégration : RESTful Sensor - Home Assistant, c’est bien cela?

8

Il n’y a rien à installer, là c’est plus des choses à ajouter dans le fichier configuration.yaml

Je vois 2 méthodes plutôt faciles.

  1. Le RESTful Sensor
    C’est le lien que tu as partagé.
    En gros tu configures ta commande (ton appel à l’api) elle se lancera à intervalle régulier et enregistrera dans un sensor la valeur d’irradiance.
    Donc tu auras quelque chose comme sensor.irradiance que tu pourras utiliser comme déclencheur de ton automatisation suivant la valeur.
    Defaut : ca va faire un appel très souvent 24/24 à l’api pour rien…

  2. La RESTfull command
    La tu peux configurer ton appel d’API, mais elle ne se lancera pas automatiquement.
    Tu pourra ensuite dans une automatisation appeler ta commande et lire le résultat.
    Suivant le résultat faire ton action.
    Ca permet de faire un automatisation qui ne se lance que pendant les heures où elle est utile… Par exemple tu peux la lancer toutes les 15 min, mais seulement 4h avant le coucher du soleil..

Exemple de RESTful sensor avec un truc qui va chercher la couleur tempo de demain toutes les 2h:

sensor:
  - platform: rest
    name: 'Tempo Demain'
    resource_template: https://www.api-couleur-tempo.fr/api/jourTempo/tomorrow
    value_template: '{{ value_json.codeJour }}'
    scan_interval: 7200
    headers:
      Accept: application/json
      Content-Type: application/json
      User-Agent: Wget/1.20.3 (linux-gnu)

Exemple de commande RESTfull qui va appeler une URL:

rest_command:
  uptime_kuma_heartbeat:
    url: "https://kuma.maison.org/api/push/Rdfdfsdfsdtatus=up&msg=OK&ping="
    method: GET
1 « J'aime »
9

Effectivement, merci, j’ai confondu « intégration » (= déjà intégré, comme le nom l’indique) et « apps » (qu’il faut installer pour pouvoir ensuite les utiliser).

Et merci pour les exemples de YAML, je vais tenter!

1 « J'aime »
10

Nope, il existe les intégrations custom qui sont … à installer et les intégrations core … qui sont déjà intégrées à HA.

Les apps … ce sont les ex-addons qui sont des applications installables via HA … mais qui sont indépendantes. Ces dernières ne fonctionnent que sous HAOS.

(aucune idée comment cela se nomme en français par contre)

1 « J'aime »
11

Merci bastgau, c’est donc encore plus subtil! :wink:

Et en plus des intégrations core, des intégrations custom, et des apps, il faut encore ajouter les add-ons disponibles sur HACS!

Un peu complexe quand on débute, après avec l’habitude je pense que cette « diversité d’accès à des fonctionnalités plus ou moins avancées » devient naturelle…

12

C’est quoi ça ? Sur HACS tu as des intégrations, des « Dashboards » (le cards), des Python Scripts, des templates et des Themes … pas de addon-ons.

13

Alors je corrige encore mon vocabulaire :wink: : il y a donc :

  • les intégrations core
  • les intégrations custom
  • les apps
  • les intégrations HACS
  • et comme tu l’ajoutes :
    • des cards HACS
    • des Python Scripts HACS
    • des templates HACS
    • et des themes HACS.

Un peu complexe quand on débute, mais ensuite ça semble permettre à HA d’être très riche en fonctionnalités!

15

Une intégration HACS, c’est la même chose qu’une intégration Custom.

HACS c’est juste un catalogue permettant le suivi des mises à jour mais tu peux tout installer manuellement.

16

Merci AlexHass

Je parviens bien à interroger Open-Meteo.com avec une Restful command.

Du coup en attendant d’avoir mes futurs volets roulants pour réaliser l’automatisation liée à l’irradiance solaire,
j’ai commencé par récupérer les prévisions de pluie au quart d’heure (notamment pour choisir l’heure de certains déplacements en vélo, quand j’ai de la flexibilité sur leur horaire).

Comme tu le dis, une Restful command, c’est mieux qu’un Rest sensor, car ça permet de ne pas interroger la source en permanence inutilement.

Du coup je me suis dit, pour les prévisions de pluie : ce qui serait encore mieux, c’est de n’interroger la source (Open-Meteo) que quand j’accède à mon tableau de bord qui affiche ces infos!

Est-ce que ça c’est possible avec HA?
C’est-à-dire, est-il possible d’utiliser comme déclencheur d’une automatisation, le fait d’ouvrir telle ou telle vue du tableau de bord?

Si ce n’est pas possible, je crois que le pourrais ajouter un bouton « Mettre à jour les données affichées », sur chaque vue du tableau de bord qui affiche des données provenant de commandes Restful.

Mais ce serait encore mieux s’il n’y a pas de bouton à cliquer, c’est-à-dire si le simple fait d’accéder à cette vue du tableau de bord, pourrait déclencher l’automatisation qui lance les commandes Restful et met en forme les données reçues pour leur affichage…

17

Un sensor REST (et les autres), tu peux leur indiquer à quelle fréquence se rafraîchir exactement comme une commande RESTFull.

Il n’existe pas de trigger sur l’action « afficher un dash oard ». Tu peux bidouiller avec des webhooks mais cela ne fonctionne pas parfaitement et dans tous les cas.

18

OK mais une fréquence ce n’est pas la même chose qu’une condition, là le but est d’interroger la source (open-meteo) quand dans certaines conditions, plutôt qu’à une fréquence définie.

OK merci.

Je vais donc tenter de mettre des « boutons déclencheurs ».

Éventuellement, je vais voir si je peux mettre des boutons « deux-en-un » sur la vue d’accueil de mon dashboard, c’est-à-dire des boutons qui mettent à jour les données qui dépendent de Restful (et les mettent en forme), et basculent vers la vue de dashboard qui affiche ces données.
Si j’y parviens, ça économisera un clic, au prix d’une répétition sur l’écran (puisque ça fera un nouveau lien pour basculer entre les vues, a priori en plus des liens déjà affichés par HA…)

19

Tu peux également rafraîchir tes sensors à la demande en désactivant le rafraîchissement automatique.

20

Intéressant ça! Comment est-ce qu’on fait pour désactiver le rafraichissement automatique d’un (seul) capteur?

Et ensuite comment les rafraîchir à la demande? (en particulier avec une automatisation)

21

pour un sensor restfull, tu mets scan_interval: 0.

Dans une automatisation, tu utilises l’action homeassistant.update_entity :

action: homeassistant.update_entity
metadata: {}
data:
  entity_id:
    - sensor.adguard_version
22

OK merci.

Et pour un sensor non restful, c’est possible aussi de désactiver l’update automatique?
(Dans quel fichier? Puisque un sensor restful, c’est dans configuration.yaml, puisque c’est là qu’il faut le créer, mais où sont les autres sensors, ceux qui ont été créés avec l’UI?)