logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

EMS – deterministyczny system zarządzania energią dla domu off-grid

rezydent1 19 Lip 2026 11:33 1050 19

TL;DR LABEL_AI_GENERATED

  • EMS dla domu off-grid to autorski, deterministyczny system zarządzania energią elektryczną i cieplną całego budynku.
  • Każdy moduł publikuje raport stanu zamiast wydawać polecenia, a Boss zbiera dane i przydziela budżet energii dla odbiorników.
  • Dom ma 170 m², około 20 ton betonu w ogrzewaniu podłogowym i około 18 ton żelbetowego stropu, więc działa jak magazyn energii.
  • System już steruje grzałkami SSR, planuje nadwyżki PV, zapisuje pełną telemetrię decyzji i działa na serwerze Ubuntu z dostępem przez Tailscale oraz Telegram.
  • Projekt nie jest gotowym produktem ani instrukcją budowy; to R&D testowane w rzeczywistym domu, z przyszłą integracją ogrzewania podłogowego i kotła na drewno.
Podsumowanie AI na podstawie dyskusji. Może zawierać błędy.
Słuchaj:
  • Autorski projekt systemu zarządzania przepływem energii elektrycznej i cieplnej
    Wstęp
    Przez ostatnie kilkanaście miesięcy rozwijałem własny system zarządzania energią dla domu pracującego w trybie off-grid.
    Nie jest to sterownik grzałek ani kolejny system działający według prostej zasady „jeżeli napięcie przekroczy wartość X, włącz przekaźnik”. Celem projektu było opracowanie deterministycznego systemu podejmowania decyzji energetycznych dla całego budynku.
    System traktuje energię jako wspólny zasób, niezależnie od postaci, w jakiej jest magazynowana lub wykorzystywana.
    W praktyce oznacza to jednoczesne zarządzanie:
    • energią elektryczną,
    • energią zgromadzoną w akumulatorach,
    • energią cieplną zgromadzoną w buforze wody,
    • energią zmagazynowaną w masie ogrzewania podłogowego,
    • a docelowo również energią dostarczaną z kotła opalanego drewnem.

    Założenia projektu
    Dom, w którym pracuje system, od początku został zaprojektowany jako magazyn energii.
    Nie jest to przypadkowy budynek, lecz element całego projektu energetycznego.
    Podstawowe parametry:
    • powierzchnia użytkowa: 170 m²
    • współczynnik przenikania ciepła ścian: około 0,15 W/(m²K)
    • współczynnik przenikania ciepła dachu: około 0,10 W/(m²K)
    • ściany z 48 cm betonu komórkowego
    • około 20 ton betonu w ogrzewaniu podłogowym
    • około 18 ton żelbetowego stropu
    Tak duża masa akumulacyjna powoduje bardzo dużą bezwładność cieplną budynku.
    Dlatego system nie steruje temperaturą pomieszczeń co kilka minut.
    Steruje energią.
    Budynek traktowany jest jako magazyn energii o dużej pojemności cieplnej, a nie jako zbiór niezależnych odbiorników.

    Dlaczego nie mierzę temperatury pokojowej?
    To pytanie pojawia się najczęściej.
    W przypadku budynku o bardzo dużej pojemności cieplnej temperatura wewnętrzna zmienia się powoli. Znacznie ważniejsze od chwilowej wartości temperatury jest określenie:
    • ile energii zostało dostarczone,
    • ile energii zostało odebrane,
    • jaki jest trend zmian.
    Model energetyczny budynku okazuje się znacznie bardziej użyteczny niż ciągłe reagowanie na zmianę temperatury o kilka dziesiątych stopnia.

    Architektura systemu
    System został zbudowany w sposób modułowy.
    Każdy moduł odpowiada wyłącznie za własny obszar funkcjonalny i publikuje raport opisujący swój aktualny stan.
    Przykładowe moduły:
    • Battery – stan magazynu energii,
    • Planner – prognoza produkcji energii z instalacji PV,
    • Floor – model ogrzewania podłogowego,
    • Buffer – model bufora ciepła,
    • Weather – prognoza pogody.
    Moduły nie wydają sobie nawzajem poleceń.
    Komunikują się wyłącznie poprzez publikowane raporty opisujące ich stan.
    Dzięki temu każdy z nich może być rozwijany niezależnie od pozostałych.

    Boss – centralny moduł decyzyjny
    Najważniejszym elementem systemu jest moduł Boss.
    Boss nie steruje bezpośrednio urządzeniami.
    Na podstawie raportów ze wszystkich modułów buduje aktualny obraz stanu energetycznego domu, a następnie wyznacza budżet energii dla poszczególnych odbiorników.
    Przykładowy podział budżetu:
    • grzałki elektryczne – 2400 W,
    • ogrzewanie podłogowe – 1200 W,
    • bufor ciepła – 800 W,
    • ciepła woda użytkowa – 500 W.
    Następnie odpowiednie moduły wykonawcze realizują przydzielony budżet.
    Takie rozwiązanie pozwala wymieniać lub rozbudowywać poszczególne elementy wykonawcze bez ingerencji w logikę decyzyjną całego systemu.

    Determinizm
    Jednym z podstawowych założeń projektu było świadome zrezygnowanie z wykorzystania sztucznej inteligencji w procesie sterowania.
    Dla identycznego zestawu danych wejściowych system zawsze podejmuje identyczną decyzję.
    Pozwala to na:
    • pełną analizę procesu decyzyjnego,
    • łatwe wykrywanie błędów,
    • przewidywalność działania,
    • możliwość odtworzenia każdej decyzji nawet wiele miesięcy po jej podjęciu.
    Każda decyzja posiada:
    • unikalny identyfikator,
    • uzasadnienie,
    • poziom pewności,
    • kompletną telemetrię stanu systemu.
    Modele sztucznej inteligencji mogą natomiast w przyszłości służyć wyłącznie jako narzędzie wspomagające analizę danych historycznych i proponujące modyfikacje algorytmów. Nie uczestniczą jednak bezpośrednio w procesie sterowania.

    Telemetria
    System zapisuje nie tylko końcową decyzję.
    Rejestrowany jest kompletny obraz systemu w chwili jej podjęcia.
    Zapisywane są między innymi:
    • moc instalacji PV,
    • napięcie i prąd akumulatorów,
    • obciążenie domu,
    • nadwyżka energii,
    • trendy zmian,
    • prognoza produkcji PV,
    • jakość danych z poszczególnych modułów,
    • przydzielony budżet energii,
    • czas wykonania algorytmu.
    Telemetria pełni rolę „czarnej skrzynki” systemu.
    Dzięki temu możliwe jest późniejsze przeanalizowanie każdej decyzji bez zgadywania, dlaczego została podjęta.

    Rozwój systemu
    Obecnie system zarządza przede wszystkim energią elektryczną oraz wykorzystaniem nadwyżek energii z instalacji fotowoltaicznej.
    Kolejnym etapem będzie integracja z ogrzewaniem podłogowym oraz kotłem opalanym drewnem.
    Docelowo Boss będzie oceniał bilans energetyczny całego domu i przedstawiał użytkownikowi sugestie, między innymi:
    • zapotrzebowanie energetyczne do końca doby lub do rana,
    • optymalny moment rozpalenia kotła,
    • wykorzystanie energii zgromadzonej w buforze,
    • proponowany czas pracy poszczególnych obwodów ogrzewania podłogowego.
    Boss nadal nie będzie sterował kotłem.
    Będzie jedynie przedstawiał użytkownikowi wynik analizy energetycznej całego systemu.

    Platforma sprzętowa i komunikacja
    System pracuje na dedykowanym komputerze z systemem Ubuntu, działającym nieprzerwanie jako serwer zarządzania energią.
    Komunikacja z urządzeniami odbywa się lokalnie poprzez sieć LAN oraz interfejsy szeregowe.
    Zdalny dostęp realizowany jest za pomocą prywatnej sieci VPN opartej na Tailscale, dzięki czemu system nie wymaga przekierowywania portów ani wystawiania usług do Internetu.
    Do komunikacji z użytkownikiem wykorzystywany jest Telegram, który oprócz powiadomień alarmowych umożliwia wykonywanie podstawowych operacji administracyjnych oraz zmian konfiguracji.
    Interfejs użytkownika stanowi aplikacja webowa prezentująca aktualny stan systemu, historię decyzji, telemetrię oraz umożliwiająca ręczne sterowanie wybranymi elementami instalacji.

    Stan projektu (lipiec 2026)
    Obecnie system obejmuje:
    • zarządzanie energią elektryczną w instalacji off-grid,
    • sterowanie grzałkami poprzez moduły SSR (mierzenie czasu pracy grzałek, na tej podstawie uruchamianie ich w odpowiedniej kolejności, tak aby w miarę wyrównać czasy pracy),
    • planowanie wykorzystania nadwyżek energii z instalacji PV,
    • deterministyczny moduł decyzyjny Boss,
    • pełną telemetrię wszystkich decyzji,
    • monitoring stanu akumulatorów,
    • monitoring urządzeń wykonawczych,
    • panel WWW,
    • zdalny dostęp poprzez Tailscale,
    • komunikację i powiadomienia przez Telegram.
    Najbliższy etap rozwoju obejmuje integrację z ogrzewaniem podłogowym oraz źródłem ciepła opalanym drewnem, dzięki czemu system będzie zarządzał energią zgromadzoną zarówno w akumulatorach, jak i w magazynach ciepła budynku.

    Podsumowanie
    Projekt jest autorskim systemem badawczo-rozwojowym (R&D), rozwijanym i testowanym w rzeczywistym domu pracującym w trybie off-grid.
    Jego celem nie jest stworzenie uniwersalnego produktu dla każdej instalacji, lecz opracowanie deterministycznego modelu zarządzania energią, który można rozwijać i weryfikować na podstawie rzeczywistych danych eksploatacyjnych. Dopiero wtedy będzie można wdrażać w innych instalacjach.
    Artykuł nie jest instrukcją budowy instalacji ani prezentacją gotowego produktu komercyjnego. Stanowi opis koncepcji oraz architektury systemu rozwijanego w praktyce, którego kolejne etapy są weryfikowane na podstawie wielomiesięcznej pracy w rzeczywistych warunkach.



    Chętnie poznam opinie osób zajmujących się automatyką budynkową oraz systemami EMS.
    Interesuje mnie przede wszystkim dyskusja dotycząca architektury systemu i modelu podejmowania decyzji, a nie wyboru konkretnego sprzętu czy języka programowania.
    Czy Waszym zdaniem deterministyczny model zarządzania energią ma przewagę nad klasyczym sterowaniem opartym o proste reguły "IF... THEN..."?



    EMS – deterministyczny system zarządzania energią dla domu off-grid


    EMS – deterministyczny system zarządzania energią dla domu off-grid

    EMS – deterministyczny system zarządzania energią dla domu off-grid

    EMS – deterministyczny system zarządzania energią dla domu off-grid EMS – deterministyczny system zarządzania energią dla domu off-grid EMS – deterministyczny system zarządzania energią dla domu off-grid EMS – deterministyczny system zarządzania energią dla domu off-grid Panel WWW z wykresem: produkcja PV i pobór mocy w czasie, z zakresem dat i przyciskiem „Generuj”

    Fajne? Ranking DIY
    O autorze
    rezydent1
    Poziom 15  
    Offline 
    rezydent1 napisał 279 postów o ocenie 155, pomógł 2 razy. Jest z nami od 2013 roku.
  • #2 21941792
    gulson
    Administrator Systemowy
    Posty: 29525
    Pomógł: 150
    Ocena: 6122
    Ciekawa koncepcja, podejście do traktowania całego budynku jako magazynu energii
    Muszę się zastanowić jak temat wypromować w dziale Energia Odnawialna.

    Ciekawa byłaby funkcja celu - np. komfort termiczny lub jestem przeziębiony, chcę cieplej.
    Wiem, że żony narzekają, jak jest chłodno zimą ;)


    Myślę, że standardowe IF THEN dla wielu źródeł energii, magazynów, odbiorników, traci sens.
    Człowiek by się zajechał, jakby chciał opisać wszystkie warunki.

    BOSS to jakiś model AI?
  • #3 21941800
    rezydent1
    Poziom 15  
    Posty: 279
    Pomógł: 2
    Ocena: 155
    Dziękuję za komentarz.

    Dokładnie taki był mój zamysł – nie sterować pojedynczymi urządzeniami, ale traktować cały dom jako jeden system energetyczny.

    W moim przypadku energia może być magazynowana jednocześnie:

    w akumulatorach,
    w buforze ciepłej wody,
    w masie ogrzewania podłogowego,
    a w przyszłości również w energii dostarczanej z kotła opalanego drewnem.

    Boss nie zarządza urządzeniami, lecz dostępnym budżetem energii. Dopiero moduły wykonawcze decydują, w jaki sposób ten budżet zostanie zrealizowany.

    Jeżeli chodzi o AI – nie.

    Boss jest świadomie zaprojektowany jako moduł deterministyczny. Dla identycznych danych wejściowych zawsze podejmie identyczną decyzję. Dzięki temu mogę po kilku miesiącach odtworzyć każdą decyzję i sprawdzić, dlaczego została podjęta. Każda decyzja posiada pełną telemetrię opisującą stan systemu w chwili jej podjęcia.

    Nie wykluczam natomiast wykorzystania AI jako narzędzia analitycznego. Gdy system zgromadzi kilka lub kilkanaście miesięcy danych, modele AI mogą pomóc wskazać miejsca, w których warto zmienić progi decyzyjne lub algorytmy. Sama decyzja sterująca pozostanie jednak deterministyczna.

    Jeżeli chodzi o funkcję celu, obecnie jest nią możliwie najlepsze wykorzystanie dostępnej energii przy zachowaniu bezpieczeństwa magazynu energii oraz komfortu cieplnego budynku.

    Docelowo chciałbym, aby Boss potrafił również podpowiadać użytkownikowi działania, a nie tylko sterować urządzeniami. Przykładowo: „do rana będzie potrzebne około 18 kWh energii cieplnej – warto rozpalić kocioł” albo „uruchom obieg ogrzewania podłogowego w strefie X na około 40 minut”. Nadal byłaby to jednak sugestia dla użytkownika, a nie autonomiczna decyzja systemu.

    System posiada możliwość przełączenia z trybu doradczego do trybu automatycznej realizacji decyzji. Obecnie pozostaje ona wyłączona, ponieważ chcę najpierw zweryfikować poprawność modelu podczas wielomiesięcznej pracy w rzeczywistych warunkach.

    Starałem się również oddzielić proces podejmowania decyzji od procesu ich wykonania. Dzięki temu logika zarządzania energią jest niezależna od konkretnego sprzętu i może być rozwijana bez przebudowy całego systemu.
  • #4 21941846
    gulson
    Administrator Systemowy
    Posty: 29525
    Pomógł: 150
    Ocena: 6122
    To bardzo ciekawe, jeśli rezygnujesz z standardowego IF ELSE THEN to w jaki sposób może działać BOSS? Czym będzie BOSS?
    Jakiś system punktacji?
    Jakiś system matematyczny?

    Rozumiem, że bez AI, ale również bez reguł IF THEN ?
  • #5 21941886
    rezydent1
    Poziom 15  
    Posty: 279
    Pomógł: 2
    Ocena: 155
    To bardzo dobre pytanie.

    Nie tyle rezygnuję z reguł IF...THEN..., co z budowania całego systemu jako ogromnego drzewa takich zależności.
    Przy kilku źródłach energii, kilku magazynach i wielu odbiornikach liczba reguł bardzo szybko rośnie i staje się trudna do utrzymania.
    Boss działa trochę inaczej.

    Poszczególne moduły (Planner, Battery, Buffer, Floor, Weather) nie wydają poleceń, lecz publikują raport opisujący swój stan.
    Przykładowo:

    dostępna moc PV,
    napięcie i trend akumulatora,
    ilość energii zgromadzonej w buforze,
    zapotrzebowanie ogrzewania podłogowego,
    jakość danych i poziom pewności.

    Boss buduje z tych raportów obraz aktualnego stanu systemu.
    Następnie przeprowadza ocenę tego stanu i wyznacza budżet energii dla poszczególnych odbiorników.
    W praktyce bliżej mu do funkcji oceny (ang. evaluation function) niż klasycznego drzewa IF...THEN.
    Oczywiście wewnątrz algorytmu nadal istnieją pojedyncze warunki, np. zabezpieczenia akumulatora czy kontrola poprawności danych. Nie da się całkowicie wyeliminować instrukcji warunkowych.
    Różnica polega na tym, że nie opisuję każdej możliwej sytuacji osobną regułą, lecz oceniam stan energetyczny systemu jako całości i na tej podstawie wyznaczam budżet energii.
    Na obecnym etapie jest to deterministyczny model matematyczno-logiczny. W przyszłości może zostać wzbogacony o funkcję kosztu lub funkcję celu, ale nadal chcę zachować pełną przewidywalność procesu decyzyjnego.

    W moim zamyśle pierwsze miesiące pracy systemu służą przede wszystkim zebraniu danych opisujących zachowanie konkretnego budynku. Na ich podstawie możliwa jest kalibracja i weryfikacja modelu energetycznego oraz progów decyzyjnych Bossa.
    Po zakończeniu tego etapu system powinien już stabilnie zarządzać energią w danym obiekcie.

    W przyszłości architekturę będzie można przenieść do innego budynku, jednak nie będzie to rozwiązanie typu „plug and play”. Każdy budynek ma inną charakterystykę cieplną, inne źródła energii, inną bezwładność i inne priorytety użytkowników.
    Nowy obiekt będzie wymagał ponownej kalibracji modelu, ale nie rozpocznie pracy od zera. Będzie korzystał z doświadczeń zdobytych podczas projektowania poprzednich instalacji, dzięki czemu proces dostrajania powinien być znacznie krótszy.

    Za jakiś czas można zaimplementować do :
    Dom A (170 m², bardzo duża akumulacja ciepła),
    Dom B (120 m², pompa ciepła),
    Dom C (300 m², dwa magazyny energii),
    Warsztat,
    Gospodarstwo.
    i etc...
    Każdy będzie miał ten sam Boss, ale inny model energetyczny i inne parametry.
    To jest właśnie cecha dobrze zaprojektowanej architektury: logika pozostaje wspólna, a dostrajany jest model konkretnego obiektu.
  • #6 21942926
    sq3evp
    Poziom 39  
    Posty: 6728
    Pomógł: 226
    Ocena: 901
    czym się różni funckja oceny od klasycznego warunku i algorytmu?
    To jest po prosty bardziej rozbudowana funkcja if...then przypominają ca "in case of" - czyli warunki w trochę inny sposób.

    Przypomina mi to dewelopera, który twierdził, że nie potrzbuje algorytmów a implementował warunki, czyli algorytm postępowania.

    To jest raczej automatyczne sterowanie czy bramki logiczne i działania na sumach czy iloczynach (używając klasycznych działa z logiki). Tylko, że do oceny stanów potrzb decydowa czy coś jest w zakresie czy poza.
    Oczywiście można zakresy zmieniać bo warunki brzegowe ulegają zmianie - tutaj dużo pomóc może jaki język się za tym kryje.
  • #7 21942994
    gulson
    Administrator Systemowy
    Posty: 29525
    Pomógł: 150
    Ocena: 6122
    No właśnie, wydaje mi się, że tutaj będzie działać jakiś system punktowy, ale to nadal IF ELSE.
  • #8 21942999
    sq3evp
    Poziom 39  
    Posty: 6728
    Pomógł: 226
    Ocena: 901
    gulson napisał:
    No właśnie, wydaje mi się, że tutaj będzie działać jakiś system punktowy, ale to nadal IF ELSE.

    Dokładnie - tylko brzmi to lepiej, że nie używamy.

    Widziałem jak programowało się sterowniki SIMATIC - przemysłowe, używane w wielu poważnych zakładach pracy.
    Dla automatyka (także był dla niego interfesj używajacy symboli stosowanych w automatyce) był to co najwyżej system automatycznego sterowania a nie pełna automatyka.
    Eleletronik (także był dla niego interfesj używajacy symboli stosowanych w elektronice czyli bramek i rejestrów) mówił podobnie.
    Dla biznesu było sprzedawana prawie jaki AI tylko, że 20 lat temu to było.

    Byłu to warunki z tym że dane wejściowe zmienny były, ale było to Jeśli... To...albo. Ładnie wyglądało na panelu z algorytmem.

    Był też interfejs dla programisty - chyba coś jak C to było.
    Tu już było głownie if..the i case of.
  • #9 21943057
    exlibris71
    Poziom 18  
    Posty: 213
    Pomógł: 21
    Ocena: 108
    Ale czemu uparliście się tak na to „if then else”? Możliwości jest więcej, np. system reguł z solverem albo jakiś system logiki rozmytej...
  • #10 21943111
    sq3evp
    Poziom 39  
    Posty: 6728
    Pomógł: 226
    Ocena: 901
    exlibris71 napisał:
    Ale czemu uparliście się tak na to „if then else”? Możliwości jest więcej, np. system reguł z solverem albo jakiś system logiki rozmytej...

    A czym jest fuzzy logic?
    Logika rozmyta tym różni się od "zwykłej logiki" tym ze w zwykłej są tylko dwa staty: 0 i 1.
    W rozmytej mamy wiele stanów, ale jeżeli zaimplementujemy warunki if..then to daje są to warunki.
    Pamiętam jak robiłem tablice prawy dla logiki binarnej i rozmytej i sięjakoś nie różniły. Także można optymalizować tabli i takżę można tam zawrzeeć warunki - kwestia tylko podejścia do implementacji.
    Czym jest suma gliczna czy iloczyn jak nie warunkiem?
    Kwestia implementacji - gdzieś tam pod spodem jest rozbijane wszystko na elementy atomowe czyli najdrobniejsze. AI także opeira sie algorytmy korzystając ze zbiorów ML, które są jako źródło porównywane z zadanym sygnałem (w przypadku AI jest to prompt, czyli zapytanie do modelu AI).
    Granularnie robi porównanie warunków logicznych i porównuje ciągi znaków (sic! znowy porównania czy jeśli...to..albo).
  • #11 21943256
    rezydent1
    Poziom 15  
    Posty: 279
    Pomógł: 2
    Ocena: 155
    Dziękuję za wszystkie komentarze. Myślę, że częściowo mówimy o różnych poziomach opisu tego samego problemu.
    Oczywiście, że na najniższym poziomie każdy program wykonuje porównania, skoki warunkowe i operacje logiczne. Z tego punktu widzenia zarówno sterownik PLC, system ekspertowy, logika rozmyta, jak i algorytm napisany w Pythonie ostatecznie zostaną sprowadzone przez kompilator lub interpreter do instrukcji procesora. Z tym trudno polemizować.
    Natomiast moim celem nie było pokazanie, że „nie ma żadnych if-ów”. One oczywiście są i będą.
    Różnica polega na tym, gdzie one występują i co opisują.
    Nie buduję systemu w postaci setek reguł typu:

    jeżeli napięcie > X
    i PV > Y
    i temperatura < Z
    to włącz grzałkę nr 3

    Po dodaniu kolejnych źródeł energii, odbiorników i magazynów liczba takich zależności rośnie bardzo szybko i utrzymanie ich staje się trudne.
    W moim przypadku moduły (Battery, Planner, Buffer, Floor itd.) nie podejmują decyzji wykonawczych. Publikują jedynie opis swojego stanu: dostępność energii, jakość danych, prognozę, zapotrzebowanie czy priorytet.
    Boss otrzymuje obraz całego systemu i na jego podstawie wyznacza budżet energii, a nie stan konkretnych przekaźników. Dopiero wykonawcy realizują ten budżet zgodnie ze swoimi możliwościami.
    To nie jest próba ucieczki od algorytmów. Wręcz przeciwnie – cały system jest deterministycznym algorytmem. Chodzi jedynie o to, aby logika była opisana na poziomie zarządzania energią, a nie sterowania pojedynczymi urządzeniami.
    Nie twierdzę również, że jest to AI ani logika rozmyta. Świadomie z tego zrezygnowałem. Dla tych samych danych wejściowych Boss zawsze podejmie identyczną decyzję i mogę po kilku miesiącach odtworzyć cały proces decyzyjny dzięki zapisanej telemetrii.
    Czy kiedyś wykorzystam AI? Być może, ale wyłącznie jako narzędzie analityczne do oceny zgromadzonych danych i proponowania zmian progów lub modeli. Sam proces sterowania chciałbym pozostawić deterministyczny.
    Moim zdaniem najciekawsze będzie dopiero zweryfikowanie tej architektury po kilku miesiącach pracy i po dołączeniu kolejnych magazynów energii (ogrzewanie podłogowe, bufor oraz kocioł na drewno). Wtedy będzie można ocenić, czy takie podejście rzeczywiście upraszcza zarządzanie złożonym systemem, czy nie.

    Widzę, że chyba nie do końca udało mi się przekazać, o co chodzi w architekturze systemu. Nie twierdzę, że nie ma tam instrukcji if ani algorytmów. Oczywiście są. Różnica polega na tym, co jest przedmiotem decyzji.
    W klasycznym sterowniku logika często wygląda mniej więcej tak:

    PV

    IF

    Grzałka

    Czyli decyzja dotyczy konkretnego urządzenia.

    U mnie wygląda to inaczej:

    PV
    Bateria
    Bufor
    Podłoga
    Pogoda
    Drewno

    BOSS

    Budżet energii

    Wykonawcy

    Boss nie odpowiada na pytanie: „czy włączyć grzałkę?”
    Boss odpowiada na pytanie: „jak rozdysponować dostępną energię w całym domu?”
    Dopiero moduły wykonawcze (SSR, sterownik podłogówki, CWU itd.) realizują przydzielony budżet zgodnie ze swoimi możliwościami.
    Dlatego dla mnie grzałka nie jest celem sterowania. Jest tylko jednym z wykonawców. Za kilka miesięcy dojdzie ogrzewanie podłogowe i kocioł na drewno, ale Boss nie będzie musiał zmieniać swojej filozofii działania – nadal będzie zarządzał budżetem energii, a nie konkretnymi urządzeniami.
  • #12 21943323
    aadeer
    Poziom 17  
    Posty: 280
    Pomógł: 11
    Ocena: 178
    rezydent1 napisał:
    Boss otrzymuje obraz całego systemu i na jego podstawie wyznacza budżet energii, a nie stan konkretnych przekaźników. Dopiero wykonawcy realizują ten budżet zgodnie ze swoimi możliwościami.

    Czyli jak konkretnie jest to realizowane? Jakieś równanie?

    Dlaczego uważasz, że AI jest niedeterministyczne? I co w Twoim systemie znaczy określenie deterministyczny? Bo zależy jak do tego podejdziemy, zwykły regulator PID można potraktować jako niedeterministyczny (jeżeli nie ma jakiegoś mechanizmu resetowania bloku I, anti-windup, itd), a nawet skomplikowany regulator MIMO zrobiony na kilku warstwowej sieci neuronowej będzie w pełni deterministyczny, zakładając, że jest sieć typu feed-forward (jako sieć neuronową można zaimplementować też regulator rozmyty - patrz podejście ANFIS).

    Ciekawy jestem właśnie tego w jaki sposób zaimplementowałeś te regułu w bloku BOSS, bo z opisu brzmi trochę właśnie jak taka próba sprzedaży 😏
    sq3evp napisał:
    Dla biznesu było sprzedawana prawie jaki AI tylko, że 20 lat temu to było.


    Piszesz, że w pełni deterministyczny i są tam jakieś reguły, więc byłoby to podejście RBC - Rule Based Control, ale pojawiło się też coś o modelu i uwzględnianiu energii zgromadzonej m.in. w podłogówce, czyżby jakiś wariant sterowania MPC - Mode Based Control?
  • #13 21943531
    rezydent1
    Poziom 15  
    Posty: 279
    Pomógł: 2
    Ocena: 155
    Nie jest to AI ani MPC. Obecnie najbliżej mu do klasycznego **Rule Based Control (RBC)** rozszerzonego o prosty model stanu energetycznego domu.

    Określenie „deterministyczny” rozumiem dosłownie: dla identycznego zestawu danych wejściowych algorytm zawsze podejmie identyczną decyzję. Nie ma losowości ani procesu uczenia.

    BOSS nie steruje bezpośrednio przekaźnikami. Jego zadaniem jest wyznaczenie dostępnego budżetu energii na podstawie stanu całego systemu (akumulator, prognoza PV, magazyny ciepła itd.). Dopiero poszczególne moduły wykonawcze realizują ten budżet zgodnie ze swoimi możliwościami.
    Docelowo widzę miejsce dla AI, ale nie jako elementu podejmującego decyzje. Gdy system zgromadzi odpowiednio dużą historię zarejestrowanych decyzji i ich rezultatów (setki tysięcy przypadków), AI może posłużyć do analizy tych danych i zaproponowania lepszych progów lub reguł działania BOSS-a. Sam proces podejmowania decyzji chciałbym pozostawić deterministyczny.
    Na obecnym etapie byłoby to trochę jak używanie lasera do zabijania komara – problem po prostu nie uzasadnia jeszcze takiej złożoności.

    Nie planuję publikować wszystkich reguł decyzyjnych. Chciałem pokazać architekturę i sposób podejścia do problemu, a nie kompletną implementację.

    Obecnie największą wartością projektu nie są kolejne reguły, lecz systematycznie rosnąca baza rzeczywistych decyzji i ich rezultatów. To właśnie ona z czasem pozwoli zweryfikować założenia, udoskonalać algorytm i – być może – wykorzystać AI jako narzędzie do analizy, a nie do podejmowania decyzji.
  • #14 21943791
    aadeer
    Poziom 17  
    Posty: 280
    Pomógł: 11
    Ocena: 178
    rezydent1 napisał:
    prosty model stanu energetycznego domu

    Prosty? Takie modele rzadko są proste😉, uwzględniasz tam chyba przenikalności przegród - jakiś model RC?

    Ogólnie projekt ciekawy, napisz coś więcej o technikaliach - w czym napisany? Pracuje na jakimś serwerze, a może Rsp PI? Długo powstawał? Pisałeś czy promptowałeś?

    Z drugiej strony - czy mając dobrze dopracowany moduł sterujący - reguły - nie łatwiej byłoby zaimplementować wszystko np. w HomeAssistant jako skrypty i automatyzację? Wtedy wykresy, integracje z urządzeniami czy bota telegramowego miałbyś gotowe.

    I ostatnie pytanie - są już jakieś realne efekty ekonomiczne? Mi na taryfie dynamicznej udało się zejść od kwietnia z ceną o połowę, a to właściwie tylko kilka IFów w HA.
  • #15 21944197
    rezydent1
    Poziom 15  
    Posty: 279
    Pomógł: 2
    Ocena: 155
    Co do technicznych aspektów – Ubuntu wybrałem z bardzo prozaicznego powodu – z Linuksem pracuję od prawie 30 lat, więc to po prostu moje naturalne środowisko, system działa na serwerze z Ubuntu, a całość jest napisana w Pythonie. Taki wybór daje mi dużą elastyczność w rozwijaniu projektu, dodawaniu nowych modułów i integracji z kolejnymi urządzeniami.
    Nie, nie stosuję modelu RC. Mówiąc „prosty model” miałem na myśli uproszczoną reprezentację magazynów energii w systemie (akumulator, CWU, podłoga itd.), a nie model cieplny budynku wykorzystywany do symulacji wymiany ciepła.
    Architektura, logika i założenia są moje. ChatGPT wykorzystuję jako narzędzie wspomagające – głównie do dyskusji nad architekturą, szukania błędów, refaktoryzacji i czasem generowania fragmentów kodu. Ostateczne decyzje projektowe i integracja są po mojej stronie.
    Home Assistant jest platformą automatyki domowej, natomiast BOSS stanowi warstwę decyzyjną EMS. To dwa różne poziomy architektury. Od początku moim założeniem było stworzenie niezależnego systemu EMS z własną logiką decyzyjną, dlatego nie planuję opierać go na Home Assistant.

    Jeżeli chodzi o efekty ekonomiczne, to jeszcze za wcześnie na wyciąganie wniosków. Na razie zależy mi przede wszystkim na zebraniu możliwie dużej ilości danych z różnych warunków pogodowych i pór roku. Dopiero wtedy będzie można uczciwie ocenić skuteczność algorytmu.
    Mogę natomiast powiedzieć jedno – od 1 lipca mój dom pracuje całkowicie poza siecią energetyczną (off-grid), więc materiału do analizy z każdym dniem przybywa.
  • #16 21944253
    Chris_W
    Poziom 39  
    Posty: 8483
    Pomógł: 386
    Ocena: 1051
    Nawet jeśli sterujesz "entalpicznie" - tak by to należało nazwać - to nadal musisz znać temperatury i ustalić na ich podstawie stan początkowy, bez tego będzie głupiał system.
    To samo robi każdy PID, nawet o tym nie wiedząc.
    W przypadku ciepła - temperatura jest wskaźnikiem poziomu energii cieplnej zgromadzonej, zmiany tej temperatury określaja dawki ciepła dostarczane i zabierane - regulator PID operując w czasie na bazie temperatur osiąga równowagę dokładnie tak samo, jak liczenie entalpii cieplnej ( sumy wszystkich energii) obiektu i bilansowanie ich. To jest to samo. Tylko nazewnictwo i filozofia inna.
    No i chyba najważniejsze zcentralizowałeś system - teraz podłogówka lub CWU nie działaja każde sobie, pilnując własnej temperatury, tylko wybiera to jakiś centralny komputer - jakaś oszczedność z tego jest.
  • #17 21944346
    rezydent1
    Poziom 15  
    Posty: 279
    Pomógł: 2
    Ocena: 155
    Myślę jednak, że nie do końca udało mi się wyjaśnić, co próbuję modelować.
    Większość regulatorów odpowiada na pytanie:
    „Jak utrzymać temperaturę na zadanym poziomie?”
    Mój system próbuje odpowiedzieć na inne pytanie:
    „Jaki jest aktualny stan energetyczny budynku?”

    To są dwa różne problemy.
    Nie buduję regulatora temperatury. Buduję estymator stanu energetycznego.
    Temperatura jest dla mnie jedynie jedną z informacji o systemie, ale nie opisuje jego stanu energetycznego.
    Przykładem jest bufor ciepła.
    Jeżeli umieszczę jeden czujnik temperatury w połowie wysokości bufora i odczytam 50°C, to tak naprawdę nie wiem, ile energii jest w nim zgromadzone.
    Nawet cztery czujniki nie rozwiązują całkowicie problemu, ponieważ występują zjawiska uwarstwienia, mieszania oraz zmiennych przepływów. Temperatura opisuje lokalny stan wody, ale nie daje pełnej informacji o energii zgromadzonej w całym zbiorniku.
    Dlatego próbuję odwrócić sposób myślenia.

    Nie chcę wyznaczać energii wyłącznie z temperatury.
    Chcę estymować stan energetyczny na podstawie bilansu energetycznego.
    System wie:
    ile energii dostarczyły grzałki,
    ile energii dostarczył kocioł,
    ile energii zostało odebrane przez instalację,
    jakie są przewidywane straty,
    jaki był przebieg procesu w czasie.

    Na tej podstawie szacuje aktualny stan magazynów energii.
    Temperatura służy jedynie jako sygnał weryfikacyjny, który pozwala sprawdzić, czy model nie zaczyna odbiegać od rzeczywistości.
    Można więc powiedzieć, że nie steruję temperaturą.
    Próbuję zbudować cyfrowy model energetyczny budynku, który odpowiada na pytanie:
    „Ile energii mam obecnie do dyspozycji?”
    Dopiero na podstawie tej estymacji Boss podejmuje decyzję, jak tę energię wykorzystać.
    Nie twierdzę, że temperatura jest niepotrzebna. Twierdzę jedynie, że sama temperatura nie jest wystarczającą zmienną do opisania stanu energetycznego budynku.
    PS.
    Dobrym przykładem jest akumulator.
    Każdy elektronik wie, że akumulator o napięciu 52 V nie jest opisywany wyłącznie napięciem. Do oceny jego stanu wykorzystuje się również bilans ładunku (SoC), historię pracy, prąd ładowania i rozładowania czy modele matematyczne.
    Ja próbuję zastosować podobne podejście do całego domu. Nie interesuje mnie wyłącznie temperatura jednego elementu, lecz estymacja stanu energetycznego całego budynku, który traktuję jako złożony magazyn energii.
  • #18 21944446
    Chris_W
    Poziom 39  
    Posty: 8483
    Pomógł: 386
    Ocena: 1051
    rezydent1 napisał:
    Myślę jednak, że nie do końca udało mi się wyjaśnić, co próbuję modelować.
    Większość regulatorów odpowiada na pytanie:
    „Jak utrzymać temperaturę na zadanym poziomie?”
    Mój system próbuje odpowiedzieć na inne pytanie:
    „Jaki jest aktualny stan energetyczny budynku?”

    Wg Twojej filozofii...
    Każdy termostat mierzy aktualny stan energetyczny materii, a jak zacznie coś robić, to wtedy utrzymuje temperaturę ;)
    Zastosuj to samo do Twojego systemu - mierzy on bilans energetyczny budynku - a jak zacznie coś robić to będzie ten bilans utrzymywał na zadanym poziomie...
  • #19 21944552
    rezydent1
    Poziom 15  
    Posty: 279
    Pomógł: 2
    Ocena: 155
    Myślę, że nadal mówimy o dwóch różnych poziomach modelowania.
    Termostat, PID czy regulator temperatury rozwiązują problem regulacji konkretnej wielkości.
    Ja próbuję wcześniej odpowiedzieć na pytanie:
    Jaki jest stan energetyczny całego układu?
    Dopiero po jego oszacowaniu podejmowana jest decyzja o wykorzystaniu energii.
    Innymi słowy, Boss nie reguluje temperatury.
    Boss korzysta z estymacji stanu energetycznego i dopiero na tej podstawie przydziela budżet energii poszczególnym odbiornikom.
    Lokalne regulatory temperatury mogą nadal istnieć i wykonywać swoją pracę. Nie próbuję ich zastąpić.
    Moim celem nie jest zbudowanie lepszego termostatu, lecz modelu, który opisuje stan energetyczny budynku i pozwala planować wykorzystanie dostępnej energii.

    Dlatego patrzę na architekturę bardziej w ten sposób:

    obiekt

    estymacja stanu

    model energetyczny

    planowanie

    decyzja Bossa

    lokalne regulatory

    a nie:

    wartość zadana

    regulator

    obiekt

    To są dwa różne poziomy opisu systemu.
    Na tym etapie uważam temat temperatury za wyjaśniony. W kolejnych miesiącach to nie teoria będzie najważniejsza, lecz dane z rzeczywistej pracy systemu. One pokażą, czy przyjęty model rzeczywiście dobrze estymuje stan energetyczny budynku.
  • #20 21944770
    sq3evp
    Poziom 39  
    Posty: 6728
    Pomógł: 226
    Ocena: 901
    Problem jest "nietrywialny" jak mawiał profesor automatyki.
    Energetyk, elektronik i informatyk też.
    Takich problemów jest wiele.
    Pomyśleć jest ciekawy, trochę taki jak na pracę inżynierską albo magisterską. Nie wiem tylko czy nie z inżynierii środowiska czy elektroniki.
    Także może być jako projekt teoretyczny dla studentów przedmiotu logika rozmyta.
    Teraz całościowo to widzę ambitny pomysł. Podejście jest całościowe, ale widzę wiele zmiennych do rozwiązania.
Słuchaj:

Podsumowanie tematu

LABEL_AI_GENERATED
Dyskusja dotyczy autorskiego, deterministycznego systemu EMS/BOSS do zarządzania energią w domu off-grid, który traktuje budynek jako wspólny magazyn energii elektrycznej i cieplnej. System nie steruje pojedynczymi urządzeniami prostym schematem IF-THEN, lecz zbiera raporty z modułów takich jak Planner, Battery, Buffer, Floor i Weather, a następnie buduje obraz stanu instalacji oraz wyznacza budżet energii dla odbiorników. W opisie podkreślono, że energia jest magazynowana w akumulatorach, buforze ciepłej wody, masie ogrzewania podłogowego oraz docelowo także w zasobniku z kotła na drewno. Autor zaznacza, że rozwiązanie jest deterministyczne, z pełną telemetrią i możliwością odtworzenia każdej decyzji, a nie oparte na AI; dyskusja koncentruje się na różnicy między klasycznymi regułami, funkcją oceny, logiką rozmytą, systemem reguł i sterowaniem automatycznym.
Podsumowanie AI na podstawie dyskusji. Może zawierać błędy.
REKLAMA