> 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-pl/funkcje-ai/comfort-schedule.md). # Harmonogram komfortu Jak myCoreAI łagodzi wymagania komfortu w godzinach, gdy obiekt jest nieużywany. Harmonogram komfortu pozwala myCoreAI złagodzić wymagania dotyczące komfortu, gdy budynek jest nieużytkowany. Utrzymywanie komfortu w godzinach pracy przez całą dobę powoduje marnowanie energii na pustych piętrach. W nocy, w weekendy i wczesnym rankiem można stosować szersze granice temperatury i ograniczoną wentylację, nie wpływając zauważalnie na użytkowników. Występuje w dwóch wariantach: **ręczny** harmonogram skonfigurowany dla każdego budynku oraz **Automatyczny harmonogram komfortu (ACS)** który uczy się poziomu zajętości na podstawie własnych czujników CO₂ w budynku. Można je także łączyć. ACS stosuje swoje ograniczenia dodatkowo do wszelkich granic obowiązujących w harmonogramie ręcznym. ## Ręczny harmonogram komfortu Wariant ręczny to tygodniowy harmonogram granic komfortu, konfigurowany dla każdego budynku w BackOffice. Zespół operacyjny definiuje przedziały czasowe oraz minimalne i maksymalne granice obowiązujące w każdym z nich. myCoreAI otrzymuje te granice jako zmienne w czasie limity i optymalizuje działanie w ich ramach. Harmonogram ręczny jest jednoznaczny i przewidywalny. Granice zmieniają się dokładnie wtedy, gdy wskazuje harmonogram, co tydzień. Jest to również jego ograniczenie. Nie dostosowuje się do rzeczywistego sposobu użytkowania budynku. ## Automatyczny harmonogram komfortu (ACS) ACS eliminuje potrzebę zgadywania. Zamiast skonfigurowanego harmonogramu myCoreAI wnioskuje o zajętości na podstawie danych z czujników CO₂. Gdy ludzie przychodzą, poziom CO₂ rośnie. Gdy wychodzą, spada. Na podstawie tego wzorca myCoreAI tworzy tygodniowy harmonogram zajętości dla każdej centrali wentylacyjnej (AHU) z rozdzielczością 15 minut i stosuje ograniczenia w godzinach, które rozpoznał jako nieużytkowane. ### Jak wykrywana jest zajętość * myCoreAI analizuje około ostatnich 90 dni odczytów CO₂ dla stref obsługiwanych przez każdą AHU. * Dla każdego wzorca dnia tygodnia wykrywa poranny wzrost CO₂, zazwyczaj między 05:00 a 11:00, oraz wieczorny spadek, zazwyczaj między 14:00 a 22:00. * Oznacza czas między tymi zdarzeniami jako okres użytkowania i tworzy tygodniowy wzorzec dla każdej AHU. * Harmonogramy są stale przeliczane, więc zmiany w sposobie użytkowania zostają uwzględnione w wyuczonym harmonogramie w ciągu kilku tygodni. Różne AHU mogą mieć różne harmonogramy. Budynek, w którym jedna AHU obsługuje czynną całą dobę siłownię, a inna biura, nie będzie traktowany jako użytkowany w jednakowym stopniu. ### Co zmienia się w godzinach nieużytkowania Dla każdego budynku konfiguruje się trzy ograniczenia. Każde z nich jest niezależne. | Ustawienie | Dotyczy | Efekt w godzinach nieużytkowania | | ------------------------------- | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | Korekta temperatury wewnętrznej | Granice temperatury wewnętrznej | Granice rozszerzają się o ±X °C. Temperatura w budynku może bardziej odbiegać od wartości docelowej. | | Korekta powietrza nawiewanego | Temperatura powietrza nawiewanego AHU | Wartość zadana może zostać obniżona o maksymalnie X °C. | | Korekta wentylacji | Wartości zadane ciśnienia/przepływu AHU | Wartość zadana może zostać obniżona o maksymalnie X% albo podwyższona przy wartości ujemnej, lecz nigdy poniżej 30% skonfigurowanego maksimum. | Ustawienie `0` wyłącza to ograniczenie. Jeśli wszystkie trzy są `0`, ACS nadal oblicza harmonogramy, ale nie wprowadza żadnych zmian. ### Zabezpieczenia ACS łagodzi granice tylko wtedy, gdy ma pewność, że budynek jest pusty. W razie wątpliwości zakłada, że budynek jest użytkowany. * Jeśli dane CO₂ są niedostępne, obejmują zbyt krótki okres lub są zbyt jednolite, aby wskazywać wyraźny wzorzec, harmonogram domyślnie przyjmuje pełne użytkowanie. * Wzorzec dnia tygodnia musi wykazywać co najmniej 4 godziny użytkowania, aby został uznany za wiarygodny. W przeciwnym razie dana AHU przechodzi na tryb pełnego użytkowania. * Wentylacja nigdy nie spada poniżej 30% skonfigurowanego maksimum, dzięki czemu podstawowa wymiana powietrza jest zawsze utrzymana. * Poszczególne sygnały można wykluczyć z ACS. Jest to przydatne w strefach, w których warunki muszą być utrzymywane przez całą dobę, takich jak serwerownie lub laboratoria. {% hint style="info" %} Wyuczony harmonogram uwzględnia wyłącznie wzorce dni tygodnia. Święta państwowe działają według harmonogramu odpowiadającego im dnia tygodnia, więc świąteczny poniedziałek jest traktowany jak zwykły poniedziałek. {% endhint %} ## Interakcja z innymi funkcjami * [**AI Freedom**](/myrspoven-docs/myrspoven-docs-pl/funkcje-ai/ai-freedom.md) włącza ACS z gwarantowanym ograniczeniem. Granice komfortu rozszerzają się o co najmniej 0,5 °C w godzinach nieużytkowania, nawet jeśli nie skonfigurowano korekty temperatury wewnętrznej. * [**Adaptacyjny min./max.**](/myrspoven-docs/myrspoven-docs-pl/funkcje-ai/adaptive-min-max.md) może ograniczać, jak bardzo mogą spaść temperatury zasilania obiegów grzewczych. Zachowaj obie wartości na poziomie `100` chyba że istnieje konkretny powód, aby tego nie robić. --- # 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-pl/funkcje-ai/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.