> For the complete documentation index, see [llms.txt](https://docs.myrspoven.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.myrspoven.com/myrspoven-docs/myrspoven-docs-fr/fonctionnalites-dia/comfort-schedule.md). # Programme de confort Comment myCoreAI assouplit les exigences de confort pendant les heures d’inoccupation. Le planning de confort permet à myCoreAI d’assouplir les exigences de confort lorsqu’un bâtiment est inoccupé. Maintenir en permanence un confort de type heures de bureau gaspille de l’énergie sur des étages vides. Les nuits, les week-ends et les débuts de matinée peuvent fonctionner avec des bornes de température plus larges et une ventilation réduite sans que personne ne s’en rende compte. Il existe en deux variantes : un **manuel** planning configuré par bâtiment, et **Programme de confort automatique (ACS)** qui apprend l’occupation à partir des capteurs de CO₂ du bâtiment. Ils peuvent aussi être combinés. L’ACS applique ses abaissements en plus des bornes imposées par le planning manuel en vigueur. ## Planning de confort manuel La variante manuelle est un planning hebdomadaire des bornes de confort, configuré par bâtiment dans BackOffice. Les opérations définissent les plages horaires et les bornes min/max applicables à chacune. myCoreAI reçoit ces bornes comme des limites variables dans le temps et optimise à l’intérieur de celles-ci. Le planning manuel est explicite et prévisible. Les bornes changent exactement au moment indiqué par le planning, chaque semaine. C’est aussi sa limite. Il ne s’adapte pas à l’usage réel du bâtiment. ## Programme de confort automatique (ACS) L’ACS supprime les suppositions. Au lieu d’un planning configuré, myCoreAI déduit l’occupation à partir des données des capteurs de CO₂. Quand les personnes arrivent, le CO₂ augmente. Quand elles partent, il diminue. À partir de ce schéma, myCoreAI construit un planning hebdomadaire d’occupation par unité de traitement d’air (UTA) à une résolution de 15 minutes et applique des abaissements pendant les heures qu’il a apprises comme non occupées. ### Comment l’occupation est apprise * myCoreAI analyse environ les 90 derniers jours de relevés de CO₂ pour les zones desservies par chaque UTA. * Pour chaque profil de jour de semaine, il repère la hausse matinale du CO₂, généralement de 05:00 à 11:00, et la baisse du soir, généralement de 14:00 à 22:00. * Il marque comme occupé le temps entre ces événements et construit un profil hebdomadaire par UTA. * Les plannings sont recalculés en continu, de sorte que les changements d’utilisation se répercutent dans le planning appris en quelques semaines. Des UTA différentes peuvent recevoir des plannings différents. Un bâtiment où une UTA dessert une salle de sport ouverte 24 h/24 et l’autre des bureaux ne sera pas considéré comme occupé de manière uniforme. ### Ce qui change pendant les heures d’inoccupation Trois abaissements sont configurés par bâtiment. Chacun est indépendant. | Réglage | S’applique à | Effet pendant les heures d’inoccupation | | ---------------------------------- | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------- | | Décalage de température intérieure | Bornes de température intérieure | Les bornes s’élargissent de ±X °C. Le bâtiment peut s’éloigner davantage de la consigne. | | Décalage d’air soufflé | Température d’air soufflé de l’UTA | La consigne peut baisser jusqu’à X °C. | | Décalage de ventilation | Consignes de pression/débit de l’UTA | La consigne peut baisser jusqu’à X %, ou augmenter avec une valeur négative, sans jamais descendre en dessous de 30 % du maximum configuré. | Une valeur de `0` désactive cet abaissement. Si les trois sont `0`, l’ACS calcule quand même les plannings mais n’applique aucune modification. ### Sécurités L’ACS n’assouplit les bornes que lorsqu’il est certain que le bâtiment est vide. En cas de doute, il suppose qu’il est occupé. * Si les données de CO₂ sont absentes, trop courtes ou trop plates pour montrer un profil net, le planning revient par défaut à une occupation totale. * Un profil de jour de semaine doit montrer au moins 4 heures d’occupation pour être pris en compte. Sinon, cette UTA revient à une occupation totale. * La ventilation ne descend jamais sous 30 % du maximum configuré, de sorte qu’un renouvellement d’air de base est toujours maintenu. * Des signaux individuels peuvent être exclus de l’ACS. C’est utile pour les zones qui doivent maintenir des conditions en continu, comme les salles serveurs ou les laboratoires. {% hint style="info" %} Le planning appris suit uniquement les profils des jours de semaine. Les jours fériés suivent le planning de leur jour de semaine correspondant, ainsi un lundi férié est traité comme un lundi normal. {% endhint %} ## Interaction avec d’autres fonctionnalités * [**Liberté IA**](/myrspoven-docs/myrspoven-docs-fr/fonctionnalites-dia/ai-freedom.md) active l’ACS avec un abaissement garanti. Les bornes de confort s’élargissent d’au moins 0,5 °C pendant les heures d’inoccupation, même si aucun décalage de température intérieure n’est configuré. * [**Min/max adaptatifs**](/myrspoven-docs/myrspoven-docs-fr/fonctionnalites-dia/adaptive-min-max.md) peut limiter jusqu’où les températures de départ du circuit de chauffage peuvent baisser. Conservez les deux valeurs à `100` sauf raison particulière de ne pas le faire. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.myrspoven.com/myrspoven-docs/myrspoven-docs-fr/fonctionnalites-dia/comfort-schedule.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.