ForHosting KIT · Sciences

Calculateur d'heures de froid

Q: Puis-je vérifier l'exigence de froid d'une culture ?

Oui. Envoyez requirement comme heures non négatives requises. Omettez requirement pour ignorer ces champs.

Q: Puis-je utiliser des moyennes journalières au lieu de relevés horaires ?

Mieux vaut éviter. Chaque relevé compte pour une heure : des moyennes journalières sous-estiment ou surestiment le froid réel. Utilisez des données horaires d'un enregistreur ou d'une station météo quand la décision compte.

Sur huit relevés horaires, cinq sont passés sous 7,2 °C : le verger a cumulé 5 heures de froid. Collez vos températures horaires, choisissez le seuil et vérifiez si la saison couvre le besoin de vos pommiers, pêchers ou cerisiers. Gratuit dans votre navigateur.

Gratuit
Fonctionne dans votre navigateur
Sans inscription
Vos données restent sur votre appareil

Lancer gratuitement Voir l’API

Utilisez-le depuis WebAPIE-mailTelegramApp bientôt

Exemple résolu

Si vous saisissez

Seuil: 7,2

Vous obtenez

Nombre de températures: 8 C
Heures de froid: 5
Heures supérieures ou égales: 3
Fraction inférieure: 0,625

L'accumulation de froid hivernal décide si les arbres fruitiers de climat tempéré—pommier, pêcher, cerisier, prunier, amandier et bien d'autres—sortent proprement de la dormance au printemps. Producteurs et agents de vulgarisation se posent encore une première question simple : combien d'heures de la saison sont restées sous le seuil de froid ? Ce calculateur d'heures de froid accepte une série ordonnée de relevés horaires de température, compare chaque relevé à un seuil (classiquement 7.2 °C ou 45 °F) et renvoie le nombre d'heures strictement inférieures à cette base. Vous pouvez joindre une exigence culturale en heures pour voir si la série couvre les besoins de dormance et quelle est l'ampleur du déficit ou du surplus. Pas d'appels réseau, pas de graines aléatoires et pas d'horloges calendaires—uniquement les températures que vous fournissez.

Ce que mesurent les heures de froid et pourquoi le modèle simple compte encore

Les heures de froid sont un indicateur pratique de l'exposition au froid requise pour achever l'endodormance chez de nombreuses espèces fruitières et à coque caducifoliées. Pépinières et catalogues de cultivars publient souvent une exigence de froid en nombre d'heures, couramment référencée à une base voisine de 7.2 degrés Celsius (environ 45 degrés Fahrenheit). Le modèle simple utilisé ici suit cette tradition : chaque observation horaire strictement sous le seuil choisi contribue une heure de froid ; les observations au seuil ou au-dessus contribuent zéro.

Cette règle est volontairement transparente. Des schémas plus élaborés comme le modèle Utah pondèrent des bandes de température et peuvent annuler du froid après des épisodes doux, et le modèle Dynamic suit des portions intermédiaires de froid—tous deux sont des outils de recherche utiles—, mais les producteurs ont souvent besoin d'un premier décompte qui épouse le langage d'une fiche catalogue « nécessite 800 heures de froid ».

En ne comptant que les heures sous le seuil, vous obtenez un chiffre que vous pouvez expliquer en une phrase à une équipe de terrain ou à un étudiant. Le calculateur n'invente pas d'heures manquantes ni n'interpole entre stations ; il traite votre série comme déjà horaire et complète pour la période qui vous intéresse. Si vous fournissez des moyennes journalières, vous sous-compterez ou surcompterez par rapport à l'exposition horaire réelle ; préférez donc des séries de enregistreur ou de réanalyse à résolution d'une heure lorsque la décision compte.

L'unité est une étiquette partagée par températures et seuil : choisissez Celsius ou Fahrenheit et gardez tous les nombres sur cette échelle. Le point de terminaison ne convertit pas entre échelles, ce qui évite une double conversion silencieuse lorsque vous travaillez déjà en données de station Fahrenheit.

Cas d’usage

Suivi du froid hivernal au verger

Intégrez chaque semaine des températures horaires de enregistreur ou de station météo, comptez les heures sous 7.2 °C et comparez-les à l'exigence de froid du cultivar avant de figer pulvérisations et tailles de printemps.

Travaux pratiques d'horticulture

Donnez aux étudiants de courtes séries horaires synthétiques et laissez-les vérifier à la main que seules les lectures strictement sous le seuil ajoutent des heures de froid, y compris le cas d'égalité.

Questions fréquentes

Comment compte-t-on les heures de froid ?

Chaque température horaire strictement sous le seuil ajoute une heure de froid. Les lectures au seuil ou au-dessus ajoutent zéro. Les défauts sont 7.2 °C ou 45 °F selon l'unité.

Le calculateur utilise-t-il le modèle Utah ou Dynamic ?

Non. Cette capacité implémente le simple décompte d'heures sous seuil utilisé dans de nombreuses fiches catalogue. Unités pondérées Utah et portions Dynamic sont hors périmètre ici.

Que se passe-t-il si la température égale exactement le seuil ?

L'égalité ne compte pas. Seul t < threshold contribue. Par exemple, 7.2 avec seuil 7.2 ajoute zéro heure de froid.

Puis-je vérifier l'exigence de froid d'une culture ?

Oui. Envoyez requirement comme heures non négatives requises. Omettez requirement pour ignorer ces champs.

Puis-je utiliser des moyennes journalières au lieu de relevés horaires ?

Mieux vaut éviter. Chaque relevé compte pour une heure : des moyennes journalières sous-estiment ou surestiment le froid réel. Utilisez des données horaires d'un enregistreur ou d'une station météo quand la décision compte.

Outils associés

Pour les développeurs — accès API

Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.

Endpoint

POSThttps://api.kit.forhosting.com/bio/chilling-hours

Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.

Appeler depuis votre stack

curl -X POST https://api.kit.forhosting.com/bio/chilling-hours \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"temperatures":[8,6.5,5,4.2,7.2,9,3.5,6]}'

const res = await fetch("https://api.kit.forhosting.com/bio/chilling-hours", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "temperatures": [
      8,
      6.5,
      5,
      4.2,
      7.2,
      9,
      3.5,
      6
    ]
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/bio/chilling-hours",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "temperatures": [
        8,
        6.5,
        5,
        4.2,
        7.2,
        9,
        3.5,
        6
    ]
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/bio/chilling-hours", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"temperatures":[8,6.5,5,4.2,7.2,9,3.5,6]}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"temperatures":[8,6.5,5,4.2,7.2,9,3.5,6]}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/bio/chilling-hours", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Exemple de requête

{
  "temperatures": [
    8,
    6.5,
    5,
    4.2,
    7.2,
    9,
    3.5,
    6
  ]
}

Exemple de réponse

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "bio.chilling_hours",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.

Tarifs

par requête$0.002

Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.

Erreurs

HTTP	Code	Signification
`401`	`unauthorized`	Clé API absente ou invalide : vérifiez l’en-tête Authorization.
`402`	`insufficient_balance`	Solde insuffisant : rechargez votre compte pour lancer cette tâche.
`404`	`unknown_type`	Type de tâche inconnu : vérifiez le champ type de votre requête.
`429`	`rate_limited`	Trop de requêtes : ralentissez la cadence, puis réessayez.

Notes techniques

Contrat d'entrée, champs de réponse et comportement de validation

L'unit optionnelle est l'ensemble fermé C ou F et vaut C par défaut. Le requirement optionnel est un nombre non négatif d'heures dont la culture a besoin ; si vous l'omettez, les champs liés à l'exigence sont omis de la réponse plutôt que renvoyés comme null. Exemple : huit relevés horaires Celsius 8.0, 6.5, 5.0, 4.2, 7.2, 9.0, 3.5, 6.0 avec le seuil par défaut 7.2 donnent cinq heures de froid car 7.2 n'est pas strictement sous la base. Associez la réponse à vos propres graphiques si vous avez besoin d'un tracé temporel ; ce point de terminaison ne renvoie que des décomptes agrégés. Envoyez en POST un corps JSON avec temperatures comme un tableau non vide de nombres finis (ou une chaîne séparée par des virgules ou des espaces que le gestionnaire analyse de la même façon). Le threshold optionnel vaut par défaut 7.2 lorsque unit est C et 45 lorsque unit est F ; remplacez-le si la fiche cultivar utilise une autre base. En cas de succès le corps renvoie temperatures_count, threshold et unit ; signale chilling_hours et hours_above_or_equal ; donne fraction_below comme heures de froid divisées par la longueur de la série ; et inclut une courte chaîne de formule plus un message humain résumant le décompte. Lorsque requirement est présent vous recevez aussi requirement_met, shortfall et surplus afin que les tableaux de bord colorent une réussite ou un échec sans recalculer. Séries vides, relevés non finis, plus de vingt mille heures, requirement négatif ou unit inconnue échouent avec invalid_input en nommant le problème ; une validation échouée n'est pas facturée.

Où une API d'heures de froid prouve sa valeur en production

Les laboratoires d'enseignement en horticulture et phénologie utilisent de courtes séries synthétiques pour que les étudiants voient comment une seule heure tiède sort du décompte lorsqu'elle est au seuil. Remplacez plus tard le modèle simple par des scores Utah ou Dynamic seulement lorsque votre équipe d'agronomie standardise ces unités ; d'ici là, un décompte clair sous seuil reste la première réponse la plus recherchable et la plus auditable pour planifier la dormance hivernale. Un logiciel de gestion de verger peut pousser chaque semaine d'hiver de données de station vers ce point de terminaison et stocker chilling_hours à côté de l'humidité du sol et du risque de gel sans embarquer la logique de froid dans chaque client. Les programmes de sélection comparant des sites peuvent traiter par lots de nombreuses séries avec seuil et exigence fixes, puis filtrer sur requirement_met pour le placement des cultivars. Comme l'implémentation est pure parse de niveau A, chaque appel réussi coûte le prix de base publié $0.002 sans jetons de modèle ni réseau sortant.

Cas d'intégration

Criblage d'aptitude de site et de cultivar

Traitez par lots des hivers historiques pour des sites candidats avec seuil et exigence fixes ; conservez les sites où requirement_met est vrai sur assez de saisons.

Questions techniques

Combien coûte le calculateur d'heures de froid ?

L'outil navigateur est gratuit. Les requêtes API utilisent le solde prépayé KIT à $0.002 par appel réussi ; une entrée invalide n'est pas facturée.

Consulter la documentation complète du KIT →

Lancer gratuitement