Home Assistant n’a pas besoin d’un nombre de tâches simultanées à l’échelle de toute la maison ; chaque automatisation doit permettre suffisamment de chevauchement pour son rythme de déclenchement et la durée de ses actions, sans compromettre l’ordre d’exécution.
Dix pièces et deux cents entités n’impliquent pas dix ou deux cents exécutions d’automatisations en parallèle. La quantité utile se mesure par flux de travail : sa fréquence potentielle de déclenchement, la durée pendant laquelle une exécution reste active, la possibilité que les exécutions ultérieures remplacent les précédentes, et la quantité de travail parallèle que l’appareil ou le service cible peut accepter. Commencez par une exécution lorsque l’ordre est important, puis n’ajoutez du parallélisme que lorsque le travail réellement simultané est indépendant et sensible aux délais.
Estimez le chevauchement nécessaire à partir du rythme de déclenchement et de la durée d’exécution
Une première estimation de planification consiste à multiplier le taux d’arrivée par la durée active moyenne. Si une automatisation se déclenche toutes les dix secondes et se termine normalement en une seconde, son besoin habituel de chevauchement est largement inférieur à une exécution. Si des rafales produisent cinq déclenchements par seconde alors que chaque exécution attend deux secondes, la demande simultanée peut approcher dix exécutions, à moins que le flux de travail ne regroupe, redémarre ou mette ces événements en file d’attente.
Les échanges de la communauté sur les modes d’automatisation de Home Assistant montrent pourquoi le parallélisme relève d’un choix de comportement plutôt que d’une formule fondée sur le nombre d’appareils. Les modes unique, redémarrage, file d’attente et parallèle apportent des réponses différentes à la question : « Que doit-il se passer lorsqu’un autre déclenchement survient avant la fin de cette exécution ? »
Utilisez cette formule uniquement comme estimation de charge, et non comme recommandation de réglage. Les rafales, les longues attentes, les accusés de réception des appareils et les délais d’expiration en cas d’erreur peuvent rendre les exécutions les plus lentes beaucoup plus longues que la moyenne. Notez également la durée au 95e percentile ou la durée normale maximale, car le parallélisme est consommé par les exécutions qui restent actives le plus longtemps.
L’ordre d’exécution et l’idempotence imposent une limite plus stricte que le processeur
Certaines actions à l’échelle de la maison sont logiquement dangereuses en parallèle, même lorsque le serveur dispose d’une puissance processeur abondante. Les stores motorisés, les serrures de porte, les réglages progressifs du volume multimédia, les vannes d’irrigation et les scripts à état peuvent recevoir des commandes contradictoires si plusieurs exécutions indépendantes se chevauchent. Dans ces cas, un comportement en file d’attente ou avec redémarrage peut être plus correct qu’une exécution parallèle.
Une explication pratique des automatisations Home Assistant décrit la chaîne déclencheur-condition-action comme un modèle de contrôle déterministe. Le parallélisme doit préserver ce déterminisme plutôt que maximiser le nombre de copies que l’hôte peut techniquement planifier.
Demandez-vous si deux exécutions peuvent s’effectuer dans n’importe quel ordre tout en produisant le même résultat sûr. Si ce n’est pas le cas, n’augmentez pas le parallélisme pour corriger la latence ; raccourcissez l’exécution, regroupez les entrées ou sérialisez-les au niveau de la cible. Davantage de parallélisme n’apporte pas plus de débit lorsque l’appareil en aval n’accepte lui-même qu’une commande significative à la fois.
Les services en aval définissent le plafond utile
Même des exécutions indépendantes finissent par solliciter des ressources limitées : un coordinateur Zigbee, un broker MQTT, une API fournisseur, un service de notifications, une base de données, un canal Wi-Fi ou un appareil physique. Une analyse indépendante du parallélisme dans Home Assistant souligne que les instances d’automatisation sont des tâches et que les actions de service peuvent être suspendues pendant des opérations d’E/S externes ; planifier davantage d’exécutions n’accélère donc pas le traitement par le système en aval. Ces exécutions supplémentaires peuvent seulement entraîner des nouvelles tentatives, une mise en file d’attente, des limitations de débit ou un allongement du délai d’achèvement.
ZimaSpace décrit la même limite dans la mise à l’échelle de workers pilotée par les événements : la profondeur de la file peut justifier davantage de workers, mais seulement jusqu’à ce que le chemin en aval devienne la ressource limitante. Le parallélisme des automatisations Home Assistant doit s’arrêter à ce même type de limite de service.
Pour une rafale d’éclairage local, mesurez combien d’appels de service simultanés le coordinateur peut absorber sans accusés de réception retardés ni nouvelles tentatives. Pour les notifications, respectez les limites de débit du fournisseur. Pour les actions cloud, tenez compte du comportement des délais d’expiration. La valeur maximale correcte est le plus petit plafond imposé par la fiabilité, la capacité en aval et l’objectif de latence — et non le plus grand nombre que le processeur peut lancer.
Utilisez des seuils plutôt qu’un nombre universel
Gardez le parallélisme à une exécution pour les flux de travail où un nouveau déclenchement remplace l’intention précédente ou lorsque l’ordre doit être préservé. Utilisez une file d’attente courte lorsque chaque événement doit finir par être exécuté, mais que la cible est séquentielle. Utilisez des exécutions parallèles uniquement pour des actions indépendantes et idempotentes dont le service en aval dispose d’une marge de capacité mesurée. Augmentez le plafond d’un seul niveau à la fois, tout en surveillant l’âge de l’exécution la plus ancienne et la latence d’achèvement.
Un cas présenté sur le forum Home Assistant concernant le ralentissement d’intégrations cloud montre pourquoi les longues attentes externes peuvent accroître le travail actif. Cela met fortement en garde contre un dimensionnement du maximum fondé uniquement sur un fonctionnement avec une connexion Internet saine lorsque la même automatisation contient des appels exposés à Internet.
Une règle d’arrêt pratique est la suivante : aucun événement requis perdu, aucune file d’attente plus ancienne que le délai acceptable pour le foyer, aucune violation de l’ordre d’exécution de la cible et aucun accroissement de la file lors de la pire rafale normale. Si ces conditions sont réunies, davantage de parallélisme n’apporte aucune valeur à l’utilisateur. Si elles échouent, raccourcissez d’abord l’étape lente ou séparez le travail indépendant ; n’augmentez la limite que lorsque le chevauchement restant est réellement sûr.
Effectuez un test de rafale avant de modifier la limite
Créez une rafale d’événements représentative plutôt qu’une boucle infinie synthétique. Notez le nombre de déclenchements, les exécutions actives, les exécutions en file d’attente, l’âge de l’exécution la plus ancienne, la durée des actions, les accusés de réception des appareils, la charge du processeur, le délai de la boucle d’événements s’il est disponible et les erreurs de l’intégration cible. Répétez le test avec un réglage de parallélisme supérieur et un autre inférieur, en conservant la même rafale d’entrée.
Un article récent sur une architecture privilégiant le local souligne que la fiabilité de Home Assistant dépend du maintien de chemins de contrôle critiques limités, plutôt que de l’ajout de complexité partout. Le parallélisme constitue l’une de ces limites : il doit absorber le chevauchement normal sans transformer une tempête d’événements en saturation de toute la maison.
Choisissez le réglage le plus bas qui termine le travail requis dans le délai imparti et résiste à la rafale sans file d’attente croissante. Il peut s’agir d’une seule exécution, d’une file courte ou d’un nombre modéré d’exécutions parallèles, selon le flux de travail. Effectuez un nouveau test après l’ajout d’appels cloud, de longues temporisations ou de nouveaux capteurs à haut débit, car ces changements modifient la durée et le rythme d’arrivée, même si le nombre d’appareils reste inchangé.
FAQ
La limite par défaut de 10 est-elle une cible de parallélisme recommandée pour chaque automatisation ?
Non. Une limite par défaut est un mécanisme de sécurité, pas une recommandation de dimensionnement. De nombreuses automatisations sont correctes avec une seule exécution, tandis que d’autres nécessitent une file d’attente limitée plus petite ou plus grande, selon leur charge et leur système en aval.
Le mode parallèle rend-il Home Assistant plus rapide ?
Uniquement lorsque les exécutions sont indépendantes et que le goulot d’étranglement peut les traiter simultanément. Si la cible est séquentielle, limitée en débit ou sensible à l’ordre, le mode parallèle peut accroître l’attente et les erreurs au lieu de réduire la latence.
Chaque pièce devrait-elle avoir sa propre automatisation pour réduire le parallélisme ?
Pas nécessairement. Séparer la logique peut améliorer la répartition des responsabilités, mais cela peut aussi créer davantage d’écrivains indépendants pour le même appareil ou la même entité auxiliaire. La structure doit suivre les limites de contrôle et les exigences d’ordre, et non chercher à maximiser le nombre d’automatisations.
Centre Tech & IA
Plus à lire

Pourquoi l’architecture de Home Assistant change-t-elle lorsqu’un serveur domestique ajoute davantage de services ?
Davantage de services modifient l’architecture de Home Assistant lorsqu’ils ajoutent un état partagé, des files d’attente, des appareils, des cycles de mise à jour...

Comment mesurer les performances de Home Assistant sans confondre le cache avec la capacité
Un résultat à chaud prouve la réutilisation, pas la capacité. Mesurez le démarrage à froid, le régime stable à chaud, la charge répétée, la...

Pourquoi Home Assistant peut-il sembler moins réactif sur certains clients ?
Différents clients peuvent sembler plus lents avec le même Core, car la capacité de rendu, l’état du cache, la route et le coût des...

