Réduire les risques de messages d'erreur 429 - "concurrency limited section" de Netatmo sous HomeAssistant.

Modifier temporairement la consigne de plusieurs vannes thermostatiques Netatmo depuis Home Assistant est une opération courante… mais qui expose rapidement à des erreurs API. Le messages "429 – Concurrency limited' revient fréquemment.

On ne peut pas simplement “ignorer l’erreur”, il faut éviter qu’elle se produise.

Pourquoi les erreur 429 - "concurrency limited section" apparaissent-elles ?

Erreur 429 – Concurrency limited section (11)

Erreur : 429 - - Failed to enter concurrency limited section (11) when accessing 'https://api.netatmo.com/api/setroomthermpoint'

Lorsque plusieurs commandes sont envoyées quasi simultanément vers l’API de Netatmo, celle-ci refuse les appels excédentaires: un verrou de l'API empêche les modifications concurrentes et les requêtes supplémentaires sont donc rejetées.

Cette erreur 429 – Concurrency limited est directement liée au rythme des appels envoyés vers l’API et sera donc facilement maîtrisée côté automatisation (comme décrit un peu plus loin dans cet article).

⚠️ Limitation Cloud

La solution proposée dans cet article ne résous pas toutes les erreurs générées par l'API Cloud Netatmo: Un exemple typique est : "Erreur 503 – Service Unavailable" qui correspond à un état transitoire imposées aléatoirement par le service cloud Netatmo et demeure indépendantes de la qualité du scénario Home Assistant.

⚠️ Limitation Netatmo

L’utilisation de "continue_on_error: true" ne suffit pas !

Dans un scénario simple, 'continue_on_error: true' permet de ne pas interrompre une séquence. Mais dans le cas des appel de services Netatmo on peut observer que les boucles repeat s’interrompent malgré tout, que des actions sont silencieusement ignorées, et que le système devient non déterministe.

Maîtriser les appels à l’API Netatmo : séquentialisation et contrôle du débit

L’API est un système à débit limité, avec une capacité finie de traitement. Lorsque l’on pilote plusieurs équipements via l’API de Netatmo depuis Home Assistant, deux contraintes doivent être respectées simultanément :

• Absence de concurrence entre appels

• Respect des quotas API : 50 requêtes / 10 secondes et 500 requêtes / heure.

👉 On va chercher à garantir que tous les appels API soient émis séquentiellement, avec un débit contrôlé.

Principe

Avant même de compter explicitement les appels, il est possible d’exploiter une propriété intéressante de Home Assistant :chaque entité mise à jour reflète indirectement une interaction avec l’API.

Pour piloter correctement une API distante comme celle de Netatmo, une difficulté majeure apparaît : le système ne fournit pas explicitement son état de disponibilité. On dispose uniquement d’informations indirectes, dont la plus exploitable est la date de dernière mise à jour des données remontées dans Home Assistant.

Le capteur template :

sensor.netatmo_derniere_mise_a_jour

devient alors une référence temporelle externe, permettant d’estimer si une commande précédente a été prise en compte, si le système a eu le temps de se stabiliser et implicitement, si une nouvelle requête peut être envoyée sans risque.

Puis le script de régulation :

script.attente_du_délai_api

Une fois l'information de référence temporelle disponible, il devient possible de construire un mécanisme de contrôle adapté. Le script présenté ne se contente pas d’introduire un délai arbitraire entre deux appels API. Il met en place une logique plus avancée :

🎯 autoriser une commande uniquement lorsque le système est prêt à la recevoir

Concrètement, ce script agit comme une barrière temporelle dynamique (respect d’un délai minimal), une file d’attente séquentielle et un synchroniseur basé sur le retour d’état réel.

On quitte ainsi une logique de temporisation fixe pour entrer dans une logique asservie, où le rythme des commandes est adapté en continu à la capacité réelle du système Netatmo.

👉 Ce changement de paradigme est fondamental : il transforme une automatisation fragile en un système robuste, déterministe et reproductible. Autrement dit, on ne pilote plus “à l’aveugle”, mais en fonction du dernier événement réellement observé (retour Netatmo).

Cette approche répond directement aux limitations observées : erreurs 429 dues à des appels trop rapprochés et comportements instables malgré continue_on_error.

Enfin, les adaptation des procédures d'appels de services Netatmo

Chaque appels de services Netatmo identifié dans les scripts et automations devra être précédé du script "attente_du_délai_api" qui assurera le délai nécessaire avant la requête de service.

🛠️ Réalisation : séquentialiser les appels API Netatmo dans Home Assistant

Entrons maintenant dans la mise en œuvre concrète. Nous allons détailler un exemple complet en YAML permettant d’assurer la séquentialisation des appels vers l’API Netatmo. L’ensemble de ce mécanisme peut également être implémenté via l’interface visuelle (UI) mais ceci ne sera pas développé dans cadre de ce post.

• le capteur template

  Est à intégrer dans votre configuration YAML, selon votre organisation (fichier template.yaml, sensors.yaml ou configuration centralisée).

• Le script YAML avec délai paramétrable

  Plutôt que d’imposer un délai fixe entre chaque requête API, nous avons choisi l'approche plus flexible d'un script avec délai paramétrable. Un champ d’entrée (fields:) permet de définir dynamiquement le délai entre deux appels, une valeur par défaut garantit un fonctionnement stable, le script assure une file d’attente (mode queued) et évite les appels concurrents.

📡 Première étape : suivre l’activité de l’API Netatmo via un capteur de référence temporelle

Ce capteur ne compte pas directement les appels API. Il répond à une autre question :

Vous souhaitez en lire plus ?

Abonnez-vous à xn--domono-gva.fr pour continuer à lire ce post exclusif.

S'abonner