> 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/indoor-climate-baseline.md). # Bazowa charakterystyka klimatu wewnętrznego Bazowa wartość klimatu wewnętrznego pozwala myCoreAI uwzględniać historyczny klimat wewnętrzny budynku przy określaniu, jak agresywnie optymalizuje, zamiast opierać się wyłącznie na skonfigurowanych limitach temperatury. To jeden z mechanizmów objętych AI Freedom. Cel: dać myCoreAI więcej przestrzeni do oszczędzania energii tam, gdzie budynek historycznie tolerował szersze granice komfortu, bez nigdy działania poza warunkami, w których faktycznie pracował. ## Jak obliczana jest wartość bazowa myCoreAI buduje wartość bazową na podstawie **danych referencyjnych** — historycznych danych o temperaturze wewnętrznej z okresów, gdy myCoreAI nie sprawował kontroli. Na ich podstawie oblicza **limity referencyjne**: minimalną i maksymalną wartość dla każdego czujnika, które przybliżają historyczne granice komfortu budynku. * Dotyczy wyłącznie **czujników temperatury wewnętrznej**. CO₂, temperatury zasilania i liczniki energii nie są objęte zmianą. * Odrzucane są wartości odstające przed obliczeniem limitów; pojedyncza zimna lub ciepła godzina nie zaburza wyniku. * Wymaga wystarczającego pokrycia sezonowego. Jeśli okres referencyjny nie zawiera dość danych zimowych i letnich, nie można utworzyć wartości bazowej i myCoreAI wraca do skonfigurowanych limitów. ## Jak działa to ustawienie Wartość bazowa jest kontrolowana razem z AI Freedom i w praktyce działa binarnie: | AI Freedom | Wartość bazowa | | ---------- | ------------------------------------------------------------------- | | 0 | Wyłączone — używane są tylko skonfigurowane limity. | | > 0 | Włączone — każda wartość powyżej zera stosuje pełną wartość bazową. | Gdy jest aktywna, myCoreAI porównuje dla każdego czujnika dwa zestawy kandydackich limitów: 1. Te **skonfigurowane limity** ustawione w platformie. 2. Te **limity referencyjne** pochodzące z historii. Dla dolnej granicy myCoreAI wybiera ten zestaw, który ma **niższą średnią** w godzinach pracy — ten, który daje większy margines do obniżania temperatury. Dla górnej granicy wybiera ten, który ma **wyższą średnią**. Jeśli zestaw referencyjny nie jest najbardziej zewnętrzny, myCoreAI przesuwa limity referencyjne tak, aby ich średnia odpowiadała średniej skonfigurowanej; kształt krzywej referencyjnej zostaje zachowany, ale poziom jest dopasowany do tego, co skonfigurowano. Wartość bazowa jedynie **poszerza** granice komfortu. Nigdy nie zaostrza limitów bardziej, niż zostały skonfigurowane. ## Godziny pracy myCoreAI rozdziela godziny pracy od reszty tygodnia, ponieważ tolerowane granice komfortu często różnią się między dniami roboczymi a nocami/weekendami. Godziny pracy są ustalone dla wszystkich budynków na **07:00–18:00, od poniedziałku do piątku**. Każdy limit referencyjny ma więc jedną wartość dla godzin pracy i inną dla pozostałych godzin. W budynku o stabilnym klimacie te dwie wartości są niemal identyczne. W budynku o silnych wzorcach dnia/nocy lub dni robocze/weekend różnią się bardziej. ## Dolny próg bezpieczeństwa dla historycznie ciepłych budynków Jeśli budynek historycznie działał w cieple, ale ma skonfigurowane stosunkowo niskie dolne limity, zastosowanie minimalnej wartości referencyjnej dosłownie mogłoby obniżyć temperaturę budynku poniżej najniższej, na jakiej kiedykolwiek pracował. Zapobiega temu reguła bezpieczeństwa: > Jeśli średnia minimalna wartość referencyjna jest wyższa niż 20,7 °C, ale skonfigurowana wartość minimalna jest niższa niż 20,7 °C, myCoreAI dostosowuje wybrane limity tak, aby ich średnia wyniosła 20,7 °C. ## Przykład z życia Budynek biurowy ma skonfigurowany dolny limit temperatury wewnętrznej na 20,0 °C, ale dwa sezony grzewcze danych referencyjnych pokazują, że budynek nigdy faktycznie nie działał poniżej 21,4 °C w godzinach pracy. Przy AI Freedom ustawionym powyżej zera myCoreAI wybiera minimalną wartość referencyjną jako najbardziej zewnętrzną dolną granicę, a następnie stosuje dolny próg bezpieczeństwa 20,7 °C: wybrany dolny limit jest przesunięty tak, aby jego średnia w godzinach pracy wynosiła 20,7 °C zamiast 20,0 °C. Górna granica pozostaje na skonfigurowanej wartości, ponieważ referencyjna wartość maksymalna mieści się w jej obrębie. Rezultat: myCoreAI zyskuje realistyczny dolny limit, względem którego może działać podczas nocnego obniżenia temperatury i porannego rozpędzania, bez nigdy nie doprowadzania budynku poniżej temperatur, które historycznie utrzymywał. ## Co to oznacza w praktyce * Skonfigurowane limity pozostają nadrzędne. Wartość bazowa jedynie poszerza granice komfortu. * Budynki z bogatymi danymi historycznymi zyskują większą elastyczność, ponieważ istnieje więcej dowodów na to, co budynek tolerował. * Budynki z ubogą lub niereprezentatywną historią wracają do skonfigurowanych limitów i działają zachowawczo. * Niedawno podłączone budynki widzą niewielki lub żaden efekt wartości bazowej, dopóki nie zgromadzi się wystarczająco dużo danych z okresów wyłączeń w różnych sezonach. --- # 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/indoor-climate-baseline.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.