Recherches pour un module de prévision météo

Fonctionnement de l'API Open-Meteo

Open-Meteo se distingue par sa simplicité et sa philosophie "Open Data". Contrairement à OpenWeatherMap ou Météo France, l'API est stateless (pas de données utilisateurs récupérées ou nécessaires) et basée sur les coordonnées. On peut distinguer plusieurs avantages :

  • Approche par Coordonnées : L'API ne cherche pas par "Nom de ville", mais par latitude et longitude. Pour todd_weather, je poourrais donc soit stocker ces coordonnées en dur, soit utiliser leur API de Géocodage (gratuite aussi) pour transformer "Paris" en coordonnées.
  • Pas de Clé API : Pour moins de 10 000 requêtes par jour, je peux appeler l'URL directement. C'est idéal pour ma situation où le module todd_weather l'interrogera une dizxaine de fois par jour.
  • Données à la carte : Je ne récupère que ce dont j'ai besoin (current_weather, hourly, daily). Le JSON retourné est donc très léger.

Principes d'interrogation

L'interrogation se fait via des requêtes HTTP GET. La structure de l'URL ressemble à ceci :

https://api.open-meteo.com/v1/forecast?latitude=43.60&longitude=1.44&current_weather=true&timezone=Europe%2FParis

Les paramètres clés :

ParamètreUtilité
latitude / longitudePoint géographique précis (obligatoire).
current_weatherRetourne les conditions actuelles (température, vitesse du vent, code météo).
dailyPermet de demander des prévisions (ex: daily=temperature_2m_max,uv_index).
timezoneCrucial pour avoir l'heure locale correcte (ex: auto).

Implémentation dans TODD : PHP ou JS ?

Dans le cadre du framework MMI v3 que j'utilise, je me pose la question sur une utilisation en back-end ou en front-end. En réalité, le développement s'opèrera sur les deux parties.

La partie Backend (PHP) :

Comme je l'ai déjà fait pour la classe ToddMosaic, il me semble préférable de gérer l'appel API en PHP dans la classe ToddWeather.

  • Pourquoi ? Pour le Caching : si le module météo est appelé sur plusieurs écrans gérés par la même extention TODD, je n'aurais pas à faire appel à Open-Meteo.
  • Stockage : Je pourrais utiliser le getDefaultPayload() pour stocker la ville cible et les coordonnées.
  • Logique : Le PHP récupère le JSON, le décode, et peut même formater les données avant de les envoyer à la vue.

La partie Frontend (JS)

Le JavaScript interviendra surtout dans l'interface d'administration :

  • Rôle : Permettre à l'utilisateur de taper une ville, appeler l'API de géocodage en direct, et afficher une petite preview de la météo avant d'enregistrer.
  • Update : Sur l'écran de Digital Signage, un petit script JS pour rafraîchir les données toutes les 15 minutes si besoin sans recharger nécessairement la page.

L'architecture pour TODD

Pour rester cohérent avec ce que j'ai fait jusqu'à présent, notamment pour la vue mosaïque :

  1. Installation : Un install.php qui enregistre le module todd_weather dans la table todd_modules.
  2. Configuration : Un champ payload contenant city, lat, long, et units (Celsius/Fahrenheit).
  3. Rendu Public : Une vue public_complete.php qui utilise une méthode PHP pour récupérer (et mettre en cache) les données Open-Meteo.

Procédure d'utilisation de l'API Open-Meteo

Puisque l'API Open-Meteo est publique, gratuite (sans clé) et fonctionne en GET, je peux utiliser une fonction PHP native très simple : file_get_contents(). Pas besoin de librairie complexe !

Concrètement, voici les 3 étapes pour modifier ton fichier test_geo.php et afficher les données météo brutes.

Étape 1 : Construire l'URL de l'API

L'API d'Open-Meteo attend une URL avec des paramètres précis. Pour faire propre en PHP et éviter les erreurs de formatage (comme les virgules dans les coordonnées), on utilise la fonction http_build_query(). Je vais demander simplement les conditions actuelles (current_weather=true) et forcer le fuseau horaire local (timezone=auto).

Étape 2 : Faire la requête HTTP

Je vais utiliser @file_get_contents($url) pour aller chercher le texte JSON brut sur les serveurs d'Open-Meteo. (Le @ permet de rendre silencieuse l'erreur PHP si le serveur de météo est temporairement indisponible, ce qui me permet de gérer l'erreur proprement moi-même).

Étape 3 : Décodage

J'utilise json_decode($json, true) pour transformer cette chaîne de texte en un tableau associatif PHP facile à lire.


Le code

// 1. Préparation des paramètres de l'URL
$apiParams = [
    'latitude' => $latitude,
    'longitude' => $longitude,
    'current_weather' => 'true', // On demande la météo à l'instant T
    'timezone' => 'auto'         // Ajuste l'heure selon la position GPS
];

$apiUrl = "https://api.open-meteo.com/v1/forecast?" . http_build_query($apiParams);

// 2. Récupération des données (timeout basique implicite)
$apiResponse = @file_get_contents($apiUrl);

// 3. Décodage du JSON
if ($apiResponse !== false) {
    $weatherData = json_decode($apiResponse, true);
} else {
    $weatherData = ['error' => "Impossible de joindre l'API Open-Meteo."];
}

Dans le code HTML

<div style='background:#f8f9fa; border:1px solid #ddd; padding:15px; border-radius:5px;'>
    <h4>Données renvoyées par Open-Meteo :</h4>
    <pre style="white-space: pre-wrap; word-wrap: break-word;">
        <?php print_r($weatherData); ?>
    </pre>
</div>

Exemple de sortie

Array(
  [latitude] => 43.62
  [longitude] => 0.87999964
  [generationtime_ms] => 189.64314460754
  [utc_offset_seconds] => 7200
  [timezone] => Europe/Paris
  [timezone_abbreviation] => GMT+2
  [elevation] => 194
  [current_weather_units] => Array
    (
      [time] => iso8601
      [interval] => seconds
      [temperature] => °C
      [windspeed] => km/h
      [winddirection] => °
      [is_day] => 
      [weathercode] => wmo code
    )

  [current_weather] => Array
    (
      [time] => 2026-04-10T16:45
      [interval] => 900
      [temperature] => 22.1
      [windspeed] => 12
      [winddirection] => 69
      [is_day] => 1
      [weathercode] => 2
    )
)