Chciałem żeby mój opus napisał mi custom component (integrację) albo appdeamon do obsługi wentylacji w mieszkaniu. Nie potrafi zrozumieć jakie są wymagania. Mam mieszkanie 110m2. Sypialnia dzieci 1 (w home assistant wpisany jako pokój Hanny), łazienka mają okna skierowane na północ. Sypialnia rodziców oraz pokój zabaw (w home assistant wpisany jako pokój Emmy) mają okna na wschód. Salon połączony z kuchnią są od strony południowej. Salon ma tylko przesuwne drzwi hs, kuchnia ma okna. Chce zrobić jakiś kombajn który będzie potrafił obslugiwac:
Temperaturę w pokoju, wilgotność w pokoju. Uchylanie okna poprzez smarwi. Wilgotność względna w pokoju. Wilgotność względna na zewnątrz. Pylenie na zewnątrz. Warunki pogodowe typu burza grad mocny deszcz ITP. Osuszacz powietrza, nawilżacz powietrza, air purifier, czujnik zamknięcia drzwi, rolety sterowanie shelly 2pm gen4. Wiatrak wyciągowy w łazience z prysznicem. Portable air condtion zamontowany na lato w oknie w kuchni. Chciałbym wybierać który pokój co ma i żeby ta automatyzacja/appdeamon/ integracja sterowała wentylacja/wietrzeniem w moim mieszkaniu. Bardzo proszę o pomoc bo mój agent cały czas tworzy automatyzację wykluzajace się. Nie potrafi śpiące tego w całość.
#Mój agent Openclaw opus 4.6 nie potrafi sobie poradzić. Napisaniem automatyzacji/appdeamon/
1 messages · Page 1 of 1 (latest)
Da się to ogarnąć, ale nie jako „kilka automatyzacji”. Przy takiej liczbie warunków i urządzeń najlepszy wzorzec to jeden orchestrator (state machine) + konfiguracja per pokój, inaczej zawsze wyjdą automatyzacje wykluczające się.
Co bym zrobił (praktycznie)
1) Nie custom component na start.
Custom integration w HA ma sens dopiero jak logika jest stabilna. Na początek:
- AppDaemon (Python) albo
- jedna automatyzacja “controller” + skrypty/templaty + helpery (input_*).
AppDaemon zwykle wygrywa czytelnością, bo łatwo zrobić priorytety, histerezę i “minimum czasu działania”.
Rdzeń logiki: priorytety (żeby nic się nie gryzło)
Zdefiniuj jedno miejsce, które wybiera tylko jeden stan na pokój:
A. Bezpieczeństwo (zawsze wygrywa)
- burza / grad / mocny deszcz / bardzo silny wiatr → zamyka okna, blokuje wietrzenie
- (opcjonalnie) gdy nikogo nie ma w domu → zamyka okna
B. Higiena łazienki
- po prysznicu (gwałtowny wzrost RH lub RH > próg przez X min) → włącz wyciąg na min. N minut
(to działa niezależnie od reszty, ale też powinno respektować “cisza nocna”, jeśli chcesz)
C. Komfort w pokoju (główna decyzja)
- jeśli w pokoju za wilgotno / za ciepło / (warto dodać CO2 jeśli masz) → spróbuj wietrzenia, ale tylko gdy “na zewnątrz jest sens”
- jeśli na zewnątrz nie ma sensu (PM, deszcz, wilgoć, ekstremalna temp.) → użyj osuszacza/nawilżacza/AC/purifier zamiast okien
D. Anty-“klikanie” (histereza + minimum czasu)
- okno po otwarciu trzymać min. np. 5–10 min
- urządzenia (osuszacz/nawilżacz) min. np. 15 min
- progi z histerezą (np. RH_high=60%, RH_low=55%)
Klucz, którego brakuje w Twoim opisie: “czy na zewnątrz jest lepiej?”
Najprostsza stabilna reguła to porównanie punktu rosy (dew point):
- jeśli dewpoint_out + margin < dewpoint_in → wietrzenie pomaga osuszać
- jeśli odwrotnie → wietrzenie zwykle pogarsza wilgoć (zwłaszcza latem)
Do tego bramki:
- PM2.5/PM10 poniżej progu
- brak ostrych opadów/burzy
- wiatr < próg
- temp. zewn. nie ekstremalna (albo osobne tryby lato/zima)
Żeby to spiąć w całość: potrzebuję 8 konkretów
Wystarczy krótko, nawet w punktach (z entity_id jeśli możesz):
- Czy masz czujniki CO2 w pokojach? (to bardzo pomaga w “kiedy wietrzyć”)
- Jak sterujesz Smarwi: to jest
cover(pozycja %) /switch/ coś innego? (jakie encje) - Jakie masz źródło pogody (encje): deszcz/burza/wiatr? (np. met.no, AccuWeather, własna stacja)
- Jakie masz PM na zewnątrz (PM2.5/PM10) i encje?
- Każdy pokój: jakie ma urządzenia (osuszacz/nawilżacz/purifier/rolety/okno) + encje
- Czy mają być tryby: noc/cisza, eco, away?
- Czy są ograniczenia bezpieczeństwa: np. nie otwieraj okna jeśli drzwi zamknięte, albo jeśli dzieci śpią?
- Portable AC w kuchni: jak sterowane (IR/Broadlink, smart plug, klima jako
climate?) i czy okno wtedy ma pozostać w jakiejś pozycji?
Jeśli chcesz, mogę Ci dać gotowy “szkielet” pod Opusa (prompt)
Tylko potrzebuję odpowiedzi na powyższe, bo inaczej agent będzie “zgadywał” i znów wypluje sprzeczności.
Na teraz najważniejsza rada: wymuś w poleceniu, żeby generował JEDEN kontroler, nie wiele automatyzacji:
- “single source of truth”
- priorytety + histereza + minimum run time
- konfiguracja per pokój jako słownik/JSON/YAML
Wklej proszę listę pokoi i encje (nawet częściowo), a ja Ci ułożę konkretną specyfikację + strukturę AppDaemon/HA, tak żeby Twój agent miał jasne wymagania i nie robił wykluczających się automatyzacji.
1 nie mam czujników CO2, myślałem o całodobowym wietrzeniu. Smarwi uchyla tylko okna. Nie otwiera ich na oścież więc nie ma ryzyka wychłodzenia pomieszczenia nawet w zimie. Mieszkam w Szwajcarii w nowym bloku, dobrze zaizolowanym i sąsiedzi na demna non stop grzeją I w domu mam aż za ciepło. Nie udało mi się w zimie zejść później 21 stopni w sypialniach. Poza tym wszędzie oprócz łazienki z wanną mam firanki które też ograniczają trochę ruch powietrza.
2. cover.bathroom_window_window
3. Custom integracja meteoswiss
4. Nie mam czujnika pm, mieszkam w Szwajcarii tu zawsze czyste powietrze, nikt nie pali w piecu kopciuchem czy coś. Jedyny to problem pylenie lipy czy czegost tam ale to chyba meteoswiss dostarcza
5. Każdy ma rolety sterowane przez shelly pm2 oraz smarwi na uchylnym oknie, termometr. Mam też Xiaomi air purifier jakiś oraz Xiaomi evaporitive humidifier ale nie wiem gdzie postawić, pewnie postawie w sypialni gdzie śpią córki. Portable ac będzie na oknie w kuchni. Osuszacz jest w piwnicy.
6 tryby hmm czy ja wiem. Może tylko zwykły I away. Away będzie rzadziej ale wciąż wietrzył.
7 nie mam jeszcze pomysłów na ograniczenia.
8. Sterowane będzie poprzez Smart pług.
Z encjami będzie trochę problem bo nie wszystkie sprzęty mam skonfigurowane
Największy problem u Ciebie nie jest „brak encji”, tylko brak jednego mózgu, który podejmuje decyzje. Jak zrobisz to jako wiele automatyzacji, to zawsze będą się wykluczać.
Poniżej masz konkretny plan i spec, żeby Opus (albo Ty) mógł to napisać jako AppDaemon “VentilationManager” (najczytelniejsze do priorytetów, timerów i histerezy). Custom component zostawiłbym na później.
1) MVP (żeby ruszyło nawet bez wszystkich urządzeń)
Zacznij od 2 rzeczy:
- Sterowanie uchyłem okien (Smarwi / cover) per pokój
- Łazienka: wyciąg po prysznicu (RH wysokie lub szybki wzrost RH)
Resztę (purifier/nawilżacz/AC/rolety) dodajesz etapami, ale pod tym samym “managerem”.
2) Zasada, która zatrzymuje konflikty: per pokój tylko jeden stan
Manager utrzymuje stan np.:
CLOSED(zamknięte)TRICKLE(wietrzenie “ciągłe”/delikatne – u Ciebie to może być uchył, ale z warunkami)PURGE(mocniejsze wietrzenie przez X minut – u Ciebie nadal uchył, tylko dłużej)LOCKOUT_WEATHER(blokada: deszcz/burza/wiatr)
I tylko manager ma prawo wysyłać komendy do coverów. Żadnych innych automatyzacji od okien.
3) Warunki zewnętrzne (MeteoSwiss) – minimalny zestaw
Nie masz PM → okej, to pomijamy.
Potrzebujesz z MeteoSwiss przynajmniej:
outdoor_temperatureoutdoor_humidity(jeśli jest; bardzo pomaga)precipitationalbo “raining now”wind_gust/wind_speed
thunderstorm / severe warning(jeśli integracja daje)
Opcjonalnie:
pollen_index(jak chcesz blokować wietrzenie przy pyleniu lipy)
4) Krytyczny trik: nie RH%, tylko punkt rosy (żeby nie robić gorzej)
Bez CO2 nadal da się sensownie wietrzyć, ale potrzebujesz reguły “czy na zewnątrz jest sucho fizycznie”.
Najstabilniej:
- liczysz
dewpoint_inidewpoint_out - jeśli
dewpoint_out + margines < dewpoint_in→ wietrzenie osusza - jeśli nie → wietrzenie może podnieść wilgoć (klasyk latem)
To jest dokładnie ten typ logiki, którego Opus nie złoży dobrze, jeśli mu nie dasz jako twardej reguły.
5) Progi (sensowne startowe, potem dostroisz)
Globalnie:
- Komfort RH:
40–55% - “Za wilgotno”:
> 60%przez np. 10 min →PURGE(o ile pogoda pozwala) - Histereza: np. włącz >60%, wyłącz <55%
- Minimum czasu po akcji:
- po otwarciu: min. 10 min
- po zamknięciu: min. 10 min (żeby nie klikało)
Pogoda blokuje wietrzenie:
- pada / burza / grad → zamknij
- silny wiatr (np. gust > 12–15 m/s) → zamknij
6) Łazienka (prysznic) – prosta i niezawodna reguła
Wykrywanie “prysznicu” bez czujnika:
- jeśli
RH_now - RH_10min_ago > 7–10%alboRH > 70%→ włącz wyciąg na 20 min - jeśli RH nadal wysokie, przedłużaj co 5 min aż spadnie np. <60%
To powinno działać niezależnie od okien, ale dalej respektować np. “cisza nocna” jeśli kiedyś dodasz.
7) Jak to opisać Opusowi: konfiguracja per pokój (nawet jak encji brak)
Powiedz mu, że ma zrobić konfigurację jak poniżej (placeholdery możesz uzupełnić później):
rooms:
hanna:
temp: sensor.hanna_temperature
rh: sensor.hanna_humidity
window: cover.hanna_window
blinds: cover.hanna_blinds # opcjonalne
emma:
temp: sensor.emma_temperature
rh: sensor.emma_humidity
window: cover.emma_window
bathroom:
temp: sensor.bathroom_temperature
rh: sensor.bathroom_humidity
window: cover.bathroom_window_window
fan: switch.bathroom_fan
outdoor:
temp: sensor.meteoswiss_temperature
rh: sensor.meteoswiss_humidity
rain: binary_sensor.meteoswiss_rain
wind_gust: sensor.meteoswiss_wind_gust
storm: binary_sensor.meteoswiss_thunderstorm
pollen: sensor.meteoswiss_pollen # opcjonalne
I zasada: jeśli jakaś encja nie istnieje → manager ma to zignorować i działać dalej, bez wywalania całej logiki.
8) Dwie dodatkowe reguły, które uratują Cię przed “całodobowym uchyłem”
- Nie trzymaj uchyłu, gdy na zewnątrz jest wilgotniej (dewpoint_out ≥ dewpoint_in) – bo robi się kondensacja na ramach/okolice okna i potem “magicznie” pleśń.
- Zrób “trickle” jako cykl: np. 10 minut uchyłu co 40–60 minut, tylko gdy pogoda OK. To daje “ciągłe wietrzenie”, ale bez stałego wychładzania/hałasu.
Co teraz potrzebuję od Ciebie (żeby zamknąć spec na 100%)
Wystarczą nazwy encji z MeteoSwiss:
- temp zewn., RH zewn., deszcz (tak/nie), wiatr/gust, burza/ostrzeżenie
I jedno zdanie: czy chcesz w nocy wietrzyć tak samo jak w dzień (tak/nie).
Jak to wrzucisz, to mogę Ci przygotować gotowy tekst “prompt/spec” dla Opusa, który wymusi jeden AppDaemon orchestrator + brak konfliktów (priorytety, histereza, minimum run time).
Czemu dew point a nie relative humidity z integracji thermalconfort? Podałem tam temp zewnętrzna z meteoswiss oraz rh z meteoswiss.
Meteoswiss daje takie encje:
HomeAssistant:
Skill Check: none
mcporter check: ha-mcp
Jasne — u Ciebie integracja MeteoSwiss daje (stacja 9247) takie encje:
• weather.weather_at_9247
Pogoda/meteo:
• sensor.time_at_9247
• sensor.temperature_at_9247
• sensor.precipitation_at_9247
• sensor.sunshine_at_9247
• sensor.global_radiation_at_9247
• sensor.relative_humidity_at_9247
• sensor.dew_point_at_9247
• sensor.wind_direction_at_9247
• sensor.wind_speed_at_9247
• sensor.wind_gusts_peak_1s_at_9247
• sensor.air_pressure_at_9247
• sensor.air_pressure_sea_level_qff_at_9247
• sensor.air_pressure_sea_level_qnh_at_9247
Pylki:
• sensor.pollen_time_at_9247_pmu
• sensor.pollen_birch_at_9247_pmu
• sensor.pollen_grasses_at_9247_pmu
• sensor.pollen_alder_at_9247_pmu
• sensor.pollen_hazel_at_9247_pmu
• sensor.pollen_beech_at_9247_pmu
• sensor.pollen_ash_at_9247_pmu
• sensor.pollen_oak_at_9247_pmu
• sensor.pollen_birch_level_at_9247_pmu
• sensor.pollen_grasses_level_at_9247_pmu
• sensor.pollen_alder_level_at_9247_pmu
• sensor.pollen_hazel_level_at_9247_pmu
• sensor.pollen_beech_level_at_9247_pmu
• sensor.pollen_ash_level_at_9247_pmu
• sensor.pollen_oak_level_at_9247_pmu
Ostrzeżenia:
• sensor.weather_warnings_at_9247
• sensor.most_severe_weather_warning_at_9247
• sensor.most_severe_weather_warning_level_at_9247
Jak chcesz, mogę od razu pogrupować to na „kluczowe do automatyzacji wietrzenia” vs „opcjonalne”.
Elmakus:
Która encja pokazuje czy jest deszcz burza ITP i co pokazuje?
HomeAssistant:
Skill Check: none
mcporter check: ha-mcp
Najważniejsza do typu pogody (deszcz/burza itd.) jest:
• weather.weather_at_9247
Pokazuje stan pogody jako tekst (enum), np.:
• sunny
• partlycloudy
• cloudy
• rainy (deszcz)
• pouring (mocny deszcz)
• lightning (burza)
• lightning-rainy (burza z deszczem)
• hail (grad)
• snowy, snowy-rainy
• fog
• windy, windy-variant
• clear-night
• exceptional (nietypowe/ekstremalne)
Dodatkowo:
• sensor.precipitation_at_9247 — ilość opadu (liczbowa)
• sensor.weather_warnings_at_9247 — liczba aktywnych ostrzeżeń
• sensor.most_severe_weather_warning_* — najpoważniejsze ostrzeżenie/poziom (gdy istnieje)
Elmakus:
sensor.most_severe_weather_warning_at_9247
Ta pokazuje jakieś konkretne ostrzezenia
HomeAssistant:
Skill Check: none
mcporter check: ha-mcp
Tak — dokładnie ta encja pokazuje typ najpoważniejszego ostrzeżenia (konkretną kategorię), np.:
• Wind
• Thunderstorms
• Rain
• Snow
• Slippery roads
• Frost
• Thaw
• Heat waves
• Avalanches
• Earthquakes
• Forest fires
• Flood
• Drought
• Unknown
Gdy brak aktywnego ostrzeżenia, często ma unavailable (lub czasem unknown).
Nie będziemy brali pod uwagę pyłków bo nie mam nigdzie źródła pyłków lipy a to o te mi chodzi
Dew point (punkt rosy) jest lepszy od samego RH%, bo mówi ile faktycznie pary wodnej jest w powietrzu – niezależnie od temperatury. RH to tylko „jak blisko do nasycenia przy tej temperaturze”, więc potrafi strasznie mylić przy porównaniu wewnątrz vs na zewnątrz.
Czemu dew point wygrywa nad relative humidity (nawet z thermalcomfort)
Masz klasyczną sytuację:
- Na zewnątrz zimno → RH może być wysokie (np. 80–95%), ale absolutnie wody w powietrzu jest mało.
- W środku ciepło → RH może być niższe (np. 45–55%), ale absolutnie wody w powietrzu może być więcej.
Przykład (intuicyjny, nie musisz liczyć ręcznie):
- Outdoor: 5°C i 90% RH → dew point ~ 3–4°C
- Indoor: 22°C i 50% RH → dew point ~ 11°C
Mimo że na zewnątrz RH jest większe, to dew point na zewnątrz jest dużo niższy, więc wietrzenie osusza.
Dlatego reguła „wietrz gdy RH_out < RH_in” jest błędna w wielu dniach roku, a reguła „wietrz gdy dewpoint_out < dewpoint_in” jest stabilna.
Dodatkowy plus: dew point pomaga unikać problemów z kondensacją/pleśnią (gdy dewpoint_out jest wyższy niż w środku, wpuszczasz wilgoć).
I u Ciebie jest luksus: MeteoSwiss już daje gotowe:
sensor.dew_point_at_9247
więc nawet nie musisz liczyć z thermalcomfort (thermalcomfort jest OK jako fallback, ale skoro masz dew point z MeteoSwiss, to bierz to).
Jak z MeteoSwiss zrobić “czy wolno wietrzyć”
Masz sensowny zestaw encji do bramek:
1) “Czy pada / burza / grad” (twardy zakaz wietrzenia)
Najprościej:
weather.weather_at_9247i blokuj gdy stan ∈
rainy,pouring,lightning,lightning-rainy,hail,snowy,snowy-rainy
Dodatkowo (bardziej „fizyczne”):
sensor.precipitation_at_9247> jakiś próg ⇒ blokuj (próg zależy od jednostek tej encji w HA; często to mm/h albo mm)
2) “Czy jest niebezpiecznie”
sensor.most_severe_weather_warning_level_at_9247
np. jeśli >= 2 (albo >=3, zależnie jak chcesz konserwatywnie) ⇒ blokujsensor.most_severe_weather_warning_at_9247
jeśli typ to np.Thunderstorms/Wind/Rain/Flood⇒ blokuj
3) “Za duży wiatr”
sensor.wind_gusts_peak_1s_at_9247> próg ⇒ blokuj (np. startowo 12–15 m/s, potem dostroisz)
Reguła “czy wietrzenie ma sens” (bez CO2)
Skoro chcesz „całodobowe wietrzenie”, to ja bym zrobił to jako cykliczny trickle, ale tylko gdy ma sens osuszająco:
Warunek na “okno uchył OK”:
- pogoda nie blokuje (deszcz/burza/ostrzeżenia/wiatr)
- oraz:
dewpoint_out <= dewpoint_in - 1.5°C(margines przeciw “klapaniu”)
Jeśli ten warunek nie jest spełniony, to zamiast trzymać uchył cały czas, lepiej robić:
- krótkie przewietrzenie 5–10 min co np. 1–2h albo w ogóle odpuścić (zwłaszcza latem, gdy dewpoint_out jest wysoki)
Brak pyłków lipy
OK — w takim razie całkowicie ignoruj pollen encje, nie ma sensu robić fikcyjnych blokad.
Następny krok
Daj mi 2–3 encje z wnętrza (po jednej z pokoju): temperatura + wilgotność (np. sensor.hanna_temperature, sensor.hanna_humidity) i potwierdź:
- czy chcesz w nocy tak samo wietrzyć jak w dzień (tak/nie)
A ja Ci ułożę gotowy, spójny “prompt/spec” dla Opusa: jeden orchestrator (AppDaemon), priorytety, histereza, minimum czasy i konkretne warunki na podstawie Twoich meteoswiss encji.
Chodizlo mi o względna wilgotność! Czemu dew point a nie względna wilgotność?
Nie chcę polegać na liczbie niebezpiecznstw, tylko jak są straszne dla dzieci zjawiska pogodowe. Mały deszczyk albo padający śnieg nie przeszkadza. Bo wietrzyć zawsze trzeba nie? Nawet jeśli na chwilę by mi to podniosło wilgotność w domu.
sensor.bathroom_thermometer_temperature
sensor.bathroom_thermometer_humidity
RH (wilgotność względna) to to, co chcesz kontrolować dla komfortu, ale to nie jest dobre kryterium do decyzji “czy wpuścić powietrze z zewnątrz, żeby było sucho”.
Czemu dew point, a nie RH?
RH zależy od temperatury. To jest “% nasycenia przy tej temperaturze”, więc porównywanie RH wewnątrz vs na zewnątrz często wprowadza w błąd.
- Na zewnątrz może być 90% RH, ale zimno → w powietrzu jest mało wody.
- W środku może być 50% RH, ale ciepło → w powietrzu może być więcej wody.
Dew point (punkt rosy) mówi wprost “ile pary wodnej jest w powietrzu” w sposób porównywalny między temperaturami. Dlatego najlepsza praktyka jest taka:
- cel/komfort definiujesz w RH (np. 40–55%)
- decyzję czy wietrzenie osuszy czy dowilży opierasz o dew point (różnica dp_in vs dp_out)
Masz to nawet gotowe z MeteoSwiss: sensor.dew_point_at_9247.
“Ja chcę wietrzyć zawsze” — da się, tylko zrób to sprytnie
Jeśli chcesz wietrzyć nawet gdy to chwilowo podniesie RH, to w praktyce robisz trickle-ventilation w cyklach:
- normalnie: np. 10 min uchył / 50 min zamknięte
- gdy
dewpoint_out > dewpoint_in(czyli ryzyko dowilżenia): np. 3–5 min uchył / 55–60 min zamknięte - gdy w łazience po prysznicu: wentylator + ewentualnie dłuższy uchył (jeśli pogoda bezpieczna)
To daje “zawsze trochę świeżego powietrza”, ale nie robi z mieszkania wilgotnej jaskini w dni, kiedy na zewnątrz jest parno.
Pogoda: nie “liczba ostrzeżeń”, tylko konkretne zjawiska (jak chcesz)
Da się zrobić dokładnie tak, jak mówisz: blokować tylko straszne/ryzykowne rzeczy, a lekki deszcz/śnieg przepuszczać.
Najprostsza reguła na bazie MeteoSwiss:
Blokuj wietrzenie, gdy:
weather.weather_at_9247jest jednym z:
lightning,lightning-rainy(burza)hail(grad)exceptional(ekstremalne)
- albo porywy wiatru są duże:
sensor.wind_gusts_peak_1s_at_9247> próg (np. startowo 12–15 m/s)
Nie blokuj tylko dlatego, że jest rainy albo snowy — jeśli dla Ciebie to OK.
Dodatkowo możesz użyć:
sensor.most_severe_weather_warning_at_9247jako “typ” (np. tylkoThunderstormsiWindblokują)- i zignorować kompletnie “ilość ostrzeżeń”.
Łazienka: na Twoich encjach (już się da sensownie zrobić)
Masz:
sensor.bathroom_thermometer_temperature
sensor.bathroom_thermometer_humidity
Reguła “prysznic” bez CO2 i bez dodatkowych czujników:
- jeśli RH > 70% albo RH wzrosła o > 8–10% w ciągu 10 minut → włącz wyciąg na 20 min
- jeśli po 20 min RH nadal > 65% → przedłużaj co 5–10 min
To jest stabilne i nie gryzie się z resztą, jeśli wszystko robi jeden manager.
Co potrzebuję jeszcze (minimalnie), żeby dopiąć “gotowy prompt/spec dla Opusa”
- Encja okna w łazience masz:
cover.bathroom_window_window— super.
Potwierdź tylko: jak wygląda sterowanie? (np.cover.open_coveruchyla,cover.close_coverzamyka? Czy jest pozycja %?) - Jedna przykładowa encja okna + temp + RH dla jednego pokoju (np. Hanna), nawet jeśli reszta jeszcze niegotowa.
Jak to podasz, to przygotuję Ci jednolity “kontrakt” dla Opusa: AppDaemon VentilationManager z:
- stanami per pokój (żadnych konfliktów),
- cyklem “zawsze wietrzę”,
- logiką dew point jako korektą (krócej/dłużej),
- i blokadą tylko dla burzy/ gradu/ ekstremy/ silnego wiatru.
No to chodizlo mi o bezwzględna wilgotność. Ta co pokazuje ile jest gram wody w powietrzu.
Tak — “wilgotność bezwzględna” (absolute humidity, np. g/m³) to dokładnie to, o co chodzi przy decyzji, czy wpuszczane powietrze będzie suszyć czy dowilżać.
I teraz ważne: punkt rosy (dew point) to w praktyce inny zapis tej samej informacji o ilości pary wodnej w powietrzu (dokładniej: o ciśnieniu pary wodnej). Dlatego używam dew point jako kryterium, bo:
- RH% jest mylące przy porównaniu wnętrze vs zewnątrz (bo zależy od temperatury).
- Dew point jest porównywalny między temperaturami i dobrze koreluje z “ile wody niesie powietrze”.
- U Ciebie MeteoSwiss już daje gotową encję:
sensor.dew_point_at_9247, więc nie musisz nic liczyć.
Dew point vs absolute humidity (g/m³) – praktycznie
- Jeśli Td_out < Td_in, to powietrze na zewnątrz ma mniej wilgoci “w sensie bezwzględnym” → wietrzenie będzie osuszać.
- Jeśli Td_out > Td_in, to wietrzenie będzie raczej dowilżać.
To jest ten sam wniosek, który dostałbyś porównując absolute humidity out vs in.
Jeśli koniecznie chcesz iść w g/m³ (bezwzględną) zamiast dew point
Możesz:
- policzyć z
temperature+relative_humidity(thermalcomfort umie to wypluć jako osobne sensory), i wtedy reguła brzmi:
- wietrz “mocniej” gdy
AH_out + margines < AH_in- wietrz “słabiej/krócej” gdy
AH_out >= AH_in
- wietrz “słabiej/krócej” gdy
Ale skoro masz dew point z MeteoSwiss, to najprościej i najstabilniej jest oprzeć bramkę właśnie o dew point (a RH dalej trzymać jako “cel komfortu”).
Minimalna reguła do Twojego “wietrzyć zawsze”
- Zawsze rób cykl typu: 10 min uchył / 50 min zamknięte (przykład).
- Jeśli
dew_point_out <= dew_point_in - 1.5°C→ możesz robić dłuższe cykle (bardziej osusza). - Jeśli
dew_point_out > dew_point_in→ rób krótsze cykle (np. 3–5 min), żeby “świeże powietrze” było, ale bez pompowania wilgoci.
Jeśli chcesz, w następnym kroku mogę Ci rozpisać dokładnie: jakie sensory wewnętrzne policzyć (dew point / absolute humidity per pokój) i gotowe warunki “lockout” tylko dla burzy/gradu/silnego wiatru z Twoich encji MeteoSwiss.
Ok to będziemy działać na dew point. Skoro mówisz że to to samo tylko inaczej napisane. Ja chcialem właśnie żeby się co kilka godzin wietrzylo na kilka minut. Jaki interwał i na jak długo uważasz że będzie ok? I w lato jak temperatura porównywalna z tą w domu albo niższa to może warto non stop wietrzyć?
Dobra — skoro idziemy na dew point, to da się ustawić bardzo sensowne “wietrzenie co kilka godzin na kilka minut” bez CO₂.
Startowe ustawienia (sensowne “defaulty”)
Ponieważ uchył (tilt) daje zwykle mniejszą wymianę niż otwarcie na oścież (a u Ciebie jeszcze firanki), to czasy muszą być trochę dłuższe niż klasyczne “5 minut przeciągu”.
Proponuję jako punkt wyjścia:
Tryb normalny (cały rok)
- co 2–3 godziny: uchył na 10–15 minut
- i koniecznie: min. przerwa po zamknięciu też ~ 60–90 minut (żeby nie “mieliło” okna)
Korekta wg dew point (to robi całość “smart”)
- jeśli
dp_out <= dp_in - 2°C(na zewnątrz realnie sucho) → możesz robić 15–25 min co 2h - jeśli
dp_outjest podobny (|dp_out - dp_in| < 1°C) → trzymaj 10–15 min co 3h - jeśli
dp_out > dp_in + 0.5–1°C(na zewnątrz parniej) → rób tylko “świeże powietrze” 3–5 min co 2–3h (bez pompowania wilgoci)
To zwykle daje “zawsze wietrzymy”, ale bez efektu ubocznego typu: lipiec i nagle w środku 65% RH.
Lato: “non stop wietrzyć jak temp. podobna?”
Czasem tak — ale nie patrz na temperaturę jako główny warunek, tylko na dew point:
Warto wietrzyć długo / nawet prawie ciągle, jeśli:
dp_out <= dp_in - 1°C(albo przynajmniej nie wyższy)- i nie masz włączonego AC (bo wtedy walczysz sam ze sobą)
Nie warto wietrzyć ciągle, nawet gdy jest podobna temperatura, jeśli:
dp_outjest wyraźnie wyższy (parno na zewnątrz) → w środku RH zacznie rosnąć
Najlepsza strategia na lato (praktyczna)
- nocą / rano (gdy zwykle dp_out spada) możesz robić “night flush”:
- np. 30–60 min uchyłu co 2–3h, albo dłużej jeśli masz niskie dp_out
- w dzień wracasz do krótkich cykli, jeśli na zewnątrz jest parno.
Dwie ważne uwagi (żeby to działało stabilnie)
- AC w kuchni: jak portable AC działa, to dla tego pokoju (i najlepiej całego mieszkania) ustaw tryb “AC active” = nie wietrzyć / tylko minimalne 3 min co parę godzin, inaczej tracisz efekt chłodzenia.