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
latitudeetlongitude. Pourtodd_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_weatherl'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¤t_weather=true&timezone=Europe%2FParis
Les paramètres clés :
| Paramètre | Utilité |
|---|---|
latitude / longitude | Point géographique précis (obligatoire). |
current_weather | Retourne les conditions actuelles (température, vitesse du vent, code météo). |
daily | Permet de demander des prévisions (ex: daily=temperature_2m_max,uv_index). |
timezone | Crucial 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 :
- Installation : Un
install.phpqui enregistre le moduletodd_weatherdans la tabletodd_modules. - Configuration : Un champ
payloadcontenantcity,lat,long, etunits(Celsius/Fahrenheit). - Rendu Public : Une vue
public_complete.phpqui 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
)
)