Ceny godzinowe day-ahead [EUR/MWh]
🔔 Alerty cenowe
Średnie ceny dobowe i trend (SMA)
Statystyki rynków (cały okres)
🔌 Zdolności przesyłowe day-ahead (NTC) — granice rynku
Oferowane zdolności przesyłowe (ENTSO-E 11.1, dokument A61) w MW na granicach wybranego rynku. Klucz do trwałości spreadów: mała zdolność = różnica cen między rynkami może się utrzymać, duża = arbitraż transgraniczny ją domknie.
Profil godzinowy — średnia cena wg godziny
Dzień tygodnia — średnia cena
Mapa cieplna: (EUR/MWh)
🟩 tanio · 🟥 drogo — szukaj powtarzalnych pasm: to Twoje okna zakupu/sprzedaży.
Spready między rynkami (potencjał arbitrażu)
Średni spread godzinowy pary rynków. Stabilny, wysoki spread = strukturalna różnica cen. Realizacja wymaga zdolności przesyłowych (PTR/FTR) — traktuj jako sygnał kierunkowy.
Przegląd OZE — wszystkie rynki
— ładuje się automatycznie z bazy (sekundy); ~30 s/rynek tylko dla rynków, których nie ma jeszcze w bazie (limity Energy-Charts)
— dane generacji doładowują się przy pierwszym wyborze rynku
Generacja OZE (wiatr+PV) a cena —
Fundament rynku spot: więcej OZE w systemie → niższa cena krańcowa (merit order). Współczynnik z regresji poniżej jest estymowany z Twoich danych — to element „uczenia się" fundamentów.
Prognoza OZE na jutro (day-ahead, MW)
Porównanie rynków bilansujących
— ładuje się automatycznie po pobraniu danych
Rynek bilansujący PSE vs day-ahead [PLN/MWh] — ostatnie 7 dni
CEB — cena energii bilansującej (po niej PSE rozlicza niezbilansowanie), CEN — cena niezbilansowania. Day-ahead przeliczony po średnim kursie NBP. Gdy CEB > DA, niedokontraktowanie (kupno na RB) jest droższe niż zakup z wyprzedzeniem — to miara ryzyka BRP. Dla Polski dane pochodzą z PSE (CEB/CEN w PLN); dla pozostałych rynków — ceny niezbilansowania z ENTSO-E Transparency w EUR (kategorie: A04 nadwyżka / A05 niedobór; wymaga tokenu ENTSOE_TOKEN w Netlify).
Ceny mocy bilansujących PSE — usługi systemowe [PLN/MW·h]
Ceny marginalne zakupu mocy bilansującej przez PSE: FCR (regulacja pierwotna), aFRR (wtórna automatyczna), mFRR (wtórna manualna); „g" = w górę, „d" = w dół. To przychody „za gotowość" — drugi strumień dla elastycznych aktywów obok arbitrażu energii (model Entrix/suena). Do tego RCE — rynkowa cena energii (rozliczenie prosumentów) — dorysowana na wykresie głównym.
💰 Stack przychodów magazynu: FCR / aFRR / mFRR / arbitraż DA (PL)
Założenia: moce z cen marginalnych cmbp-tp (PLN/MW·h) przy pełnej dyspozycyjności mocy magazynu przez dobę; dla aFRR/mFRR liczymy korzystniejszy kierunek w każdej godzinie (jedna usługa naraz, bez przychodów/kosztów energii aktywacji); arbitraż = ideał przy pełnej znajomości cen DA (× kurs NBP). Wartości brutto — bez opłat, degradacji i prekwalifikacji. Parametry magazynu z zakładki Prognoza.
Kapitał portfela wirtualnego [EUR]
Zasady i działania
Portfel działa w pełni automatycznie: przy każdym wczytaniu danych aplikacja zapisuje rekomendację modelu dla KAŻDEGO załadowanego rynku na najbliższą dobę bez opublikowanych cen (jedna pozycja na rynek i dobę, wyłącznie na podstawie prognozy — każdy rynek ma własny portfel z parametrami swojego modelu). Po publikacji cen aukcji pozycja rozlicza się sama: rekomendacja → realny rezultat → porównanie z ideałem przy pełnej wiedzy. Parametry magazynu pochodzą z zakładki Prognoza. Po przerwie (np. tygodniu bez wejścia) aplikacja odtwarza brakujące dni (oznaczone 🔁): model jest deterministyczny i liczy prognozę wyłącznie z danych sprzed danej doby, więc odtworzone pozycje są tak samo uczciwe jak zapisane na żywo. Dodatkowo serwer Netlify codziennie o ~11:00 zapisuje rekomendację modelu do niezależnego dziennika (panel Netlify → Forms → „dziennik") ze stemplem czasu — dowód, że powstała przed publikacją cen, nawet gdy nikt nie otwiera strony.
Wyniki per rynek
Dziennik transakcji
Parametry profilu
Rekomendacje dla Twojego profilu
Struktura rynków energii (horyzont czasowy)
| Rynek | Horyzont | Do czego służy traderowi |
|---|---|---|
| Terminowy (forward/futures) | lata → dni | Zabezpieczanie ceny (hedging) dużych wolumenów; większość energii odbiorców końcowych kontraktowana jest tutaj. |
| Dnia Następnego (DAM) | D-1, aukcja ~12:00-13:00 | Główny rynek spot — cena krańcowa SMP wyznaczana przez najdroższą przyjętą ofertę (merit order). To ceny z tej aplikacji. |
| Dnia Bieżącego (intraday) | ten sam dzień, do ~h przed dostawą | Korekta pozycji po aktualizacji prognoz OZE/zapotrzebowania; kluczowy dla ograniczania ryzyka bilansowania. |
| Bilansujący | czas rzeczywisty | OSP (PSE) rozlicza odchylenia od kontraktów; ceny potrafią być skrajne — niezbilansowanie to główne ryzyko krótkoterminowe. |
| Rynek mocy | lata | W Polsce od 2019: wynagrodzenie za dyspozycyjność mocy, dodatkowy strumień przychodu dla elastycznych aktywów. |
Instytucje rynku polskiego
| Podmiot | Rola |
|---|---|
| PSE | Operator Systemu Przesyłowego (OSP/TSO) — bilansowanie systemu, rynek bilansujący, połączenia transgraniczne. |
| TGE | Towarowa Giełda Energii — rynek dnia następnego i bieżącego, rynek terminowy, gaz, prawa majątkowe. |
| URE | Regulator — koncesje na obrót energią (~450 wydanych), taryfy, nadzór rynku. |
| OSD | PGE, Tauron, Enea, Energa, E.ON (Stoen) — dystrybucja; zasada TPA umożliwia zmianę sprzedawcy od 2007 r. |
Role handlowe
| BRP (Podmiot Odpowiedzialny za Bilansowanie) | Odpowiada finansowo za zbilansowanie portfela (produkcja = zużycie). Mniejszi gracze handlują przez BRP. |
| BSP (Dostawca Usług Bilansujących) | Składa oferty regulacyjne do OSP — elastyczne wytwarzanie, magazyny, DSR. Dodatkowy przychód dla baterii. |
Checklista wejścia na rynek
1) Koncesja URE na obrót energią elektryczną → 2) członkostwo TGE (bezpośrednie lub przez dom maklerski / BRP) → 3) rejestracja REMIT (ACER) → 4) umowa o bilansowanie z PSE lub BRP → 5) zabezpieczenia finansowe i limity ryzyka.
Prognoza cen —
Parametry aktywa / strategii
Skumulowany wynik strategii [EUR]
Uczenie modelu (optymalizacja parametrów)
Model prognozy uczy się na Twoich danych: przeszukuje kombinacje pamięci (half-life), wagi dnia tygodnia i mieszania trendu, minimalizując błąd MAE na historycznym walk-forward. Najlepsze parametry są zapamiętywane osobno dla każdego rynku.
Wydłuża okres walidacji: trening i backtest liczą się wtedy na całej pobranej historii (prognoza nadal waży ostatnie 60 dni — celowo, rynek się zmienia). Głęboka historia przeżywa auto-odświeżanie. Źródło: własna baza (tyle, ile zebrał backfill), awaryjnie ENTSO-E/EC.
Trenuje model każdego załadowanego rynku po kolei (skrócona siatka 48 kombinacji + doładowanie OZE i pogody per rynek) i zapisuje parametry — od tej pory każdy portfel paper tradingu liczy się własnym modelem. Z głęboką historią może potrwać kilka minut; postęp w liczniku i w Logu.
Zgłoś opinię, sugestię lub błąd
Do zgłoszenia automatycznie dołączany jest kontekst techniczny (wersja aplikacji, przeglądarka, wybrane rynki i ostatnie błędy z logu) — ułatwia diagnozę.
Jak trafiają do Ciebie zgłoszenia
Formularz korzysta z wbudowanego mechanizmu Netlify Forms. Zgłoszenia znajdziesz w panelu Netlify: Twój site → Forms → opinie.
Aby dostawać je od razu na skrzynkę, ustaw powiadomienie: Site configuration → Forms → Form notifications → Add notification → Email notification i podaj swój adres.
Darmowy plan Netlify obejmuje 100 zgłoszeń miesięcznie. Jeśli formularz nie może się połączyć (np. aplikacja otwarta jako plik lokalny), zgłoszenie otworzy się jako gotowy e-mail.
Pełny log zdarzeń (połączenia, dane, ML)
Historia wersji
| Wersja | Zmiany funkcjonalne | Zmiany niefunkcjonalne |
|---|---|---|
| v11.60 | TOR R DOMKNIĘTY (R2+R3+R4 w panelu /moj): (R2) widok „Σ Portfel" — skumulowana krzywa kapitału i KPI CAŁEGO portfela (suma wszystkich konfiguracji po dobach), przełącznik Σ↔pojedyncze aktywo w nagłówku; (R3) nota „Na tle Europy" — pozycja rynku aktywa w top X% spośród 17 rynków wg capture (jakości modelu), porównanie ANONIMOWE i znormalizowane (procent ideału, nie wolumen — 100 MW nie bije 1 MW); (R4) ODZNAKI liczone wyłącznie z danych (nie z klikania): „N dni z planem", „Capture X% — top klasa", „% dni na plusie", „dodatni wynik od startu", „portfel N aktywów", „rynek w top X%" — wiarygodność ponad zabawę, spójnie z produktem dla inwestorów | Zero nowych tabel — wszystko liczone w locie z commits/model_params (żadnych danych wynikowych per użytkownik); krzywa Σ sumuje ostatnie znane wartości skumulowane konfiguracji per doba |
| v11.59 | Naprawa BŁĘDNEJ definicji „jakości modelu" (retrening oflagował 10 rynków jako słabe, w tym DE-LU/NL z capture 97% — bo mają MAE>25): MAE (błąd bezwzględny w EUR/MWh) rośnie naturalnie ze zmiennością cen i NIE jest miarą jakości — model z MAE 30 i capture 95% jest doskonały. Jedyną miarą wartości modelu dla baterii jest CAPTURE (ile procent idealnego zysku łapie); próg zmieniony na capture < 60%. Konsola i healthcheck przeliczają jakość WPROST z aktualnych modeli (nie z dziennika), więc werdykt jest poprawny natychmiast; przy obecnych modelach (najniższy capture to IT-North 84,9%) — wszystkie w normie, alarm gaśnie | Wymaga wklejenia nowego retrain.mjs do GitHuba (ta sama poprawka progu w dzienniku); MAE nadal pokazywane w tabeli Modele, ale informacyjnie |
| v11.58 | Kalibracja czułości monitoringu po nocy z fałszywymi alarmami: Netlify uruchamia zadania cyklicznie w trybie BEST-EFFORT (nie gwarantuje każdego tyknięcia — po serii deployów i nocą gubi pojedyncze godziny), a nasze zapisy są idempotentne i redundantne co godzinę, więc zgubione tyknięcie SAMO się nadrabia. Puls i healthcheck pilnują teraz WYNIKÓW, nie każdego tyknięcia: czerwony werdykt zapala się dopiero gdy proces milczy > 2,5 h, gubi ponad połowę doby (<12/24) albo tnie się limitem czasu — pojedyncze luki to już tylko informacja (kolumna „zgubione godziny" bez czerwieni). Licznik pokazuje UNIKALNE godziny + „+N dup" dla podwójnych wyzwoleń po deployu (koniec mylącego „54/24"). Backstopem pozostaje świeżość zbiorów | Zmiana wyłącznie w progach i prezentacji — zero zmian w zbieraniu danych; dane przez całą noc pozostały świeże (żaden zbiór nie był oflagowany) |
| v11.57 | R1 — WIELE KONFIGURACJI W PORTFELU: zalogowany użytkownik zarządza do 8 aktywami (nazwa + rynek + MW/MWh) wprost z menu Konto (dodawanie, usuwanie — API /api/configs po sesji); poranny mail 06:30 zawiera OSOBNĄ SEKCJĘ dla każdej konfiguracji (plan wykonawczy, werdykt stackingu, rozliczenie wczoraj, sprawdzian modelu, prognoza na jutro — wszystko per aktywo, temat maila zbiorczy); panel /moj dostał przełącznik konfiguracji (osobna krzywa kapitału per aktywo, liczona jak zawsze w locie z commits); zero danych wynikowych per użytkownik — konfiguracja to tylko parametry | Tabela configs z seedem z subscribers (schema-r1.sql); brak wpisów w configs = zachowanie dotychczasowe (konfiguracja bazowa z subskrypcji) — pełna kompatybilność wstecz |
| v11.56 | TRZY DUŻE KROKI naraz: (1) Z5 — ŚWIĘTA KRAJOWE per rynek w modelu v2 (17 kalendarzy: daty stałe + pochodne Wielkanocy — Wielki Piątek, Wniebowstąpienie, Zielone Świątki, Boże Ciało wg kraju) we wszystkich sześciu konsumentach prognozy (retrening, daily-commit, maile, /moj, aplikacja); (2) Z1 — PROGNOZA ZAPOTRZEBOWANIA day-ahead (ENTSO-E A65, największy driver cen obok OZE): nowy kind=load, tabela load_fc, zbieranie w ingest3 w rotacji, odczyt what=load, świeżość w konsoli i healthchecku — konsumpcja w modelu to przyszłe v3, dane już się kumulują; (3) R0 — KONTA MAGIC-LINK: logowanie bez hasła (link mailowy ważny 15 min, jednorazowy; sesja 30 dni w podpisanym ciasteczku HttpOnly, zero przechowywanych sekretów), menu Konto z trzema stanami (formularz → zalogowany: panel osobisty, zmiana konfiguracji, wyloguj), konto = subskrypcja | Wymaga: schema-z1-r0.sql w Neon, env SESSION_SECRET, wklejenia retrain.mjs do GitHuba (Z5); uproszczenia świąt opisane w kodzie (RO bez kalendarza prawosławnego, Midsommar pominięty) |
| v11.55 | KONSOLA /admin PRZEPROJEKTOWANA na pełną aplikację administracyjną (decyzja Bogdana): powłoka z boczną nawigacją i siedmioma sekcjami — Przegląd (werdykt+puls+świeżość), Integralność (11 testów), Przebiegi, Modele, BACKTEST, Procesy (ręczne uruchomienia + harmonogram), Subskrybenci (z roadmapą zarządzania pod R0); zakładka Backtest PRZENIESIONA z aplikacji użytkownika do konsoli — osadzona jako tryb embed (/app#backtest-embed pokazuje sam silnik treningu bez nagłówka i nawigacji; jeden kod, zero duplikacji), ładowana leniwie przy pierwszym wejściu w sekcję; z aplikacji usunięty tryb #admin z v11.54 (zbędny) | Nawigacja sekcji po stronie przeglądarki (bez przeładowań), kotwice #sekcja w URL, układ mobilny (sidebar → pasek); struktura gotowa na kolejne funkcje administracyjne |
| v11.54 | Porządki w nawigacji (sugestia Bogdana): (1) zakładka BACKTEST schowana przed użytkownikami — to narzędzie strojenia modelu, którego rolę przejął nocny retrening; dostępna w trybie administratora: wejście na /app#admin odblokowuje ją trwale (flaga w przeglądarce), wyłączenie w menu Konto; (2) grupa „DECYZJE" przemianowana na „REKOMENDACJE" (Prognoza + Paper trading) — trafniej opisuje zawartość: to system rekomenduje, użytkownik decyduje u siebie | Link do trybu admina dodany w konsoli /admin (sekcja 5); przy wyłączaniu trybu z aktywnym Backtestem aplikacja wraca na Rynki |
| v11.53 | Karta NTC ładuje się AUTOMATYCZNIE z bazy przy każdym odświeżeniu danych i przy zmianie rynku w selektorze (przycisk „Pobierz NTC" był reliktem trybu na żądanie z epoki żywego ENTSO-E — dziś odczyt to jedno tanie zapytanie do bazy); przycisk pozostał jako ręczne odświeżenie | Osłona przed równoległymi startami (state.ntcRun) |
| v11.52 | PRZEGLĄD UX/UI — spójność aplikacji z landingiem i przygotowanie pod konta (zlecenie Bogdana): (1) nagłówek w dwóch rzędach — marka z hasłem „kokpit 17 rynków energii · wszystko z własnej bazy" u góry, pasek narzędzi ze statusem i kontrolkami niżej (koniec ścisku 10 elementów w jednej linii); (2) MENU „👤 Konto" w prawym górnym rogu — dziś: zapis na plan dzienny + wskazówka o panelu osobistym z maila, jutro: gotowy slot na logowanie magic-link (R0) i wiele konfiguracji (R1); (3) 11 zakładek pogrupowane w cztery sekcje z etykietami: RYNKI / DECYZJE / MOJE / INFO, skrócone nazwy (Wzorce, OZE, Bilansowanie, Prognoza…); (4) przycisk 🏆 Ranking w pasku narzędzi; (5) promienie przycisków 8 px jak na landingu; nawigacja zawija się na wąskich ekranach | Palety obu stron były już zgodne (GitHub-dark, wspólny akcent) — zmiany dotyczą hierarchii i struktury, zero zmian w logice danych; decyzje spisane w UX-NOTES.md |
| v11.51 | Status i rytm odświeżania mówią językiem bazy (spostrzeżenie Bogdana — „aktualizacja, auto za 30 min" było niespójne z odczytem z bazy): pasek statusu pokazuje „🗄 odczyt z bazy HH:MM, kolejny za N min", a automatyczne odświeżenie celuje w ~:45 po pełnej godzinie — tuż PO tym, jak wszystkie trzy procesy w tle (:07/:22/:37) zapiszą świeże dane — zamiast sztywnych 30 minut z czasów pobierania na żywo; tryb po-aukcyjny (co 10 min po 13:00 do publikacji cen) bez zmian | Komunikat o brakujących rynkach bez nieaktualnego „limitu zapytań API" |
| v11.50 | STACK PRZYCHODÓW DLA KAŻDEGO RYNKU (zakładka RB): karta „arbitraż vs gotowość FCR/aFRR/mFRR" działa teraz pod selektorem rynku — PL jak dotąd z cen PSE (PLN), pozostałe kraje z bazy (what=stack, ceny mocy 17.1.B&C w EUR): cztery KPI z projekcją roczną, wykres historii dziennej, werdykt „gdzie skierować aktywo" z przewagą × nad arbitrażem i licznikiem wygranych dni — ten sam silnik co w mailu 06:30 i publicznym /ranking; rynki bez publikacji cen mocy dostają uczciwą notę i sam arbitraż; parametry baterii z zakładki Prognoza | Cache per rynek+parametry (state.stackE); opis założeń PLN/cmbp widoczny tylko dla PL, strefy EUR mają własną notę źródłową w konkluzji |
| v11.49 | Audyt wszystkich zakładek pod kątem reliktów sprzed ery „wszystko z bazy" (zlecenie Bogdana): (1) nota w zakładce OZE mówi prawdę — ładowanie z bazy w sekundy, ostrzeżenie o ~30 s dotyczy tylko rynków spoza bazy; (2) opis głębokiej historii wskazuje właściwe źródło (baza → awaryjnie ENTSO-E/EC) zamiast nieaktualnego „Energy-Charts"; (3) główna pętla ładowania: przy zbiorczym odczycie wszystkie 17 rynków naraz — partie po 3 z przerwami 350 ms były pod limity EC; (4) tabela RB „wszystkie rynki": partie po 4 zamiast 2 (limit ENTSO-E nie dotyczy odczytu z bazy); (5) komentarze w kodzie zaktualizowane do stanu faktycznego | Efekt łączny z v11.47-48: pierwsze załadowanie i tabele porównawcze w pojedynczych sekundach |
| v11.48 | Przegląd OZE „wszystkie rynki" wypełnia się od razu: pauza ~30 s/rynek (relikt crawlu Energy-Charts sprzed etapu 3) stosowana jest teraz WYŁĄCZNIE po rynkach realnie pobranych na żywo z EC — odczyty z bazy (dziś: komplet 17 rynków) lecą bez przerw, więc tabela ładuje się w 2-3 sekundy; licznik pokazuje źródło (🗄 = baza) i uczciwy komunikat tylko przy faktycznym sięgnięciu do EC | ensureRes oznacza źródło danych (src:db) — wzorzec do ponownego użycia w innych ładowaniach zbiorczych |
| v11.47 | ETAP 5 „CIENKI KLIENT" (pytanie Bogdana: po co przy każdej zakładce łączymy się per rynek, skoro wszystko jest w bazie?): (1) ceny wszystkich 17 rynków ładowane JEDNYM zbiorczym zapytaniem what=bundle na początku każdego cyklu odświeżenia — zamiast 17 osobnych połączeń (nota w Logu „🗄 Zbiorczy odczyt… JEDNYM zapytaniem, aktualne na"); pojedyncze zapytania zostają tylko jako zapas i dla głębokiej historii 180/365 dni; (2) zakładka RB czyta raporty PSE (rozliczenia, RCE, ceny mocy) z archiwum pse_raw w bazie (what=pse, pola odchudzone) zamiast na żywo z api.raporty.pse.pl — żywe API tylko przy pokryciu <70% okna (historia w bazie rośnie od 18.07, więc głębsze okna same przejdą na bazę z czasem) | Efekt: otwarcie aplikacji = 2-3 zapytania zamiast ~20; CDN cache 5 min na bundle; zakładki nie inicjują już żadnych pobrań ze źródeł zewnętrznych w normalnym trybie |
| v11.46 | ES — kalibracja finalna na rozkładzie rozjazdów per dzień (diagnoza SQL Bogdana): doby dostawy ≤27.07 mają DAM w serii bez klasyfikacji (historia przepublikowana przy migracji OMIE), doby od 28.07 — w cls=1 (nowe publikacje); filtr stosuje GRANICĘ CZASOWĄ per seria zamiast jednej reguły dla całej strefy — głęboka historia i świeże doby wybierają właściwą serię jednocześnie, bez ręcznego arbitrażu przy przyszłych backfillach | Ogon z 15.07 (sprzed okna backfillu) domknięty arbitrażem SQL (EC służy przez coalesce); rozliczenia ES bezpieczne: 20-27.07 przeliczone na EC, 28.07 rozliczony na cls1 zgodnym z EC |
| v11.45 | ES — TRZECIA zmiana semantyki OMIE w lipcu (wykryta przez v_price_mismatch: 95 rozjazdów do 21,5 EUR; metadane debug pokazały powrót do schematu DAM=bez klasyfikacji, cls1-3=IDA, z IDA3 startującą o 12:00): filtr wyboru aukcji ma teraz JAWNĄ listę strefową (ES: seria bez klasyfikacji ma pierwszeństwo; pozostałe rynki: cls=1) zamiast jednej reguły globalnej; rozliczenia commitów liczą z coalesce(ENTSO-E, EC) — po arbitrażu SQL rozliczenie odtworzy się z cen EC tam, gdzie ENTSO-E unieważniono; korekta rozliczeń ES 21-27.07 z pełnym audytem w params (co, kiedy, dlaczego, poprzedni wynik) | Wniosek systemowy potwierdzony trzeci raz: semantyka classificationSequence jest niestabilna per OSP — kontrola dwuźródłowa to jedyna realna obrona (wykryła wszystkie trzy zmiany); wymaga SQL w Neon + backfill ingest?days=10 |
| v11.44 | Po weryfikacji rozdzielenia procesów (ingest przechodzi czysto w limicie): podniesiony timeout OZE w ingest3 z 12 do 16 s — hiszpański dokument A75 nie mieścił się w 12 s (jednorazowy głośny błąd „res ES: timeout", dane nadrobione następną rotacją) | Budżet czasu ingest3 po zmianie: najgorszy przypadek ~41 s na strefę równolegle — wciąż duży zapas do limitu 60 s |
| v11.43 | DIAGNOZA FAŁSZYWYCH ALARMÓW PULSU (konsola pokazała sprzeczność: „ostatni ingest 3,9 h temu" przy świeżości danych 0,9 h — czyli przebiegi BYŁY, ale ginęły przed wpisem do dziennika, ucinane limitem czasu funkcji): (1) DZIENNIK DWUFAZOWY — marker startu zapisywany na początku przebiegu, domknięcie na końcu; timeout zostawia teraz ślad „rozpoczęty, niedokończony" zamiast niczego, a puls odróżnia „bez startu" (harmonogram) od „ucięty" (timeout); (2) ingest2 przyspieszony: sekcje NTC/pogoda/outages RÓWNOLEGLE, outages zredukowane do PL+1 strefy (dokumenty A80 są bardzo ciężkie); (3) rozjazdy dwuźródłowe rozbite per rynek w teście zgodności (liczba, max Δ, ostatni dzień) — wzorzec skupienia w jednym rynku wskazuje zmianę semantyki u źródła; (4) nota o podwójnych wpisach po deployach (nieszkodliwe — zapisy idempotentne); (5) ROZDZIELENIE PROCESÓW po dowodzie z logów Netlify (Duration: 60000 ms = twardy limit + retry): nowy ingest3 (:22) przejął porównanie Energy-Charts i rotację etap 3 (OZE/niezbilansowanie/ceny mocy, strefy równolegle) — ingest (:07) został z cenami/PSE/OZE-PL/NBP/rozliczeniami i mieści się w limicie z zapasem | Dane nigdy nie były zagrożone: zapisy partiami + upserty; problemem była tylko widoczność przebiegów w dzienniku |
| v11.42 | STRAŻNIK PIPELINE'U: (1) retrening zapisuje po każdym przebiegu pełny dziennik (czy się uruchomił i skończył, ile rynków, na ilu dniach historii, które modele słabe [capture<40% lub MAE>25], wynik pobrania bałtyckiego, czas) — /admin pokazuje to jako TRZY testy: uruchomienie/zakończenie, kompletność danych wejściowych, wartość modeli; (2) nowy poranny healthcheck 07:15 — uruchamia rdzeń testów i wysyła maila TYLKO gdy coś czerwone (zero szumu; ?force=1 do testu doręczalności, ?dry=1 podgląd JSON), z linkiem do konsoli; healthcheck sam też zostawia ślad w dzienniku | Wymaga env ADMIN_EMAIL (adresat alertów; fallback REPORT_SENDER) i wklejenia nowego retrain.mjs do repo GitHub; wpisy retrain/healthcheck wyłączone z pulsu godzinowego w /admin |
| v11.41 | Konsola /admin v2 — z podglądu na MONITORING: (0) puls procesów — czy KAŻDA godzina ostatniej doby realnie zapisała (lista brakujących godzin per proces, werdykt), (1) dziewięć testów integralności z werdyktami OK/UWAGA/AWARIA i kolumną „co zrobić przy awarii" (komplet cen wczoraj 17×23 h, ceny na jutro po aukcji, commity zapisane i rozliczone, 3 raporty PSE, prognoza OZE, rotacja pogody, NTC, zgodność dwuźródłowa, wiek modeli), na górze ZBIORCZY werdykt 🟢/🔴 z listą problemów i akcji, (7) panel ręcznego uruchamiania procesów (dry i właściwe, backfill, test bałtycki) | Odpowiedź na wymóg „bullet-proof": każda awaria ma nazwaną przyczynę i przycisk naprawy; progi testów zależne od pory dnia (aukcja, commit) |
| v11.40 | ETAP 4B + KONSOLA ADMINISTRACYJNA: (1) pogoda i niedyspozycyjności czytane NAJPIERW z bazy (open-meteo/ENTSO-E tylko jako zapas — pogoda przełącza się automatycznie, gdy baza uzbiera ~80% potrzebnej historii; w Logu nota „🗄 z bazy, aktualne na"); (2) nowa prywatna strona /admin?key=… — dashboard jakości danych: świeżość każdego zbioru z werdyktami (OK/OPÓŹNIENIE/PRZESTARZAŁE wg kadencji), 24 ostatnie przebiegi obu procesów zbierania z błędami, pokrycie cen per rynek, licznik rozjazdów dwuźródłowych, modele per rynek (v1/v2, MAE, capture, wiek), subskrybenci; (3) ingest2 dopisuje przebiegi do dziennika ingest_runs | Wymaga env ADMIN_KEY; strona no-store, noindex, bez linków z części publicznej |
| v11.39 | Naprawa „Invalid Date" w znaczniku świeżości i nocie NTC: Neon zwraca stemple „YYYY-MM-DD HH:MM:SS+00" (strefa bez minut), których Date() w przeglądarkach nie przyjmuje — wspólny parser normalizuje do pełnego ISO (+00 → +00:00, brak strefy → UTC) | Jedna funkcja parseTs/fmtTs dla wszystkich odczytów stempli z bazy |
| v11.38 | ETAP 4 „wszystko z bazy" (decyzja architektoniczna 28.07): NOWY godzinowy proces w tle ingest2 (:37) zbiera do bazy także NTC (granice PL co godzinę + rotacja stref), pogodę (17 rynków, pełny cykl ~4 h, historia+prognoza 3 dni) i niedyspozycyjności (PL + rotacja); nowe odczyty what=ntc|wx|outages|fresh; karta NTC czyta NAJPIERW z bazy z notą „🗄 z bazy, aktualne na HH:MM" (żywe API tylko jako zapas); w nagłówku aplikacji stały znacznik świeżości — najechanie pokazuje aktualność każdego zbioru; kadencja godzinowa uzasadniona zmiennością źródeł (aukcja DA raz dziennie, pogoda co ~6 h, awarie zdarzeniowo — minuty nie mają sensu) | schema-etap4.sql (tabele ntc, wx_hourly, outages_snap — wymaga uruchomienia w Neon); przełączenie prognozy pogodowej i karty outages na odczyt z bazy — etap B (dane już się zbierają) |
| v11.37 | P1-14c LT DZIAŁA (kalibracja zakończona): parser skalibrowany na żywej odpowiedzi Baltic Transparency Dashboard (kolumny Final/Preliminary per kraj — Final ma pierwszeństwo, kwadranse PT15M uśredniane do godzin Europe/Warsaw, EUR/MWh); ponieważ API blokuje IP chmurowe Netlify (timeout — z przeglądarki działa), produkcyjne pobieranie przeniesione do nocnego retreningu na GitHub Actions (inne IP, zapis wprost do tabeli imbalance, okno 7 dni, Final nadpisuje Preliminary przy kolejnych przebiegach); aplikacja pokaże LT automatycznie (czyta niezbilansowanie najpierw z bazy) | Diagnostyka ingest?dry=1&baltic=1 pozostaje; parser przetestowany jednostkowo na próbce (średnia godz. i pierwszeństwo Final); wymaga wklejenia nowego retrain.mjs do repo GitHub |
| v11.36 | Diagnostyka połączenia z Baltic Transparency Dashboard: próba dwóch hostów API + raportowanie przyczyny błędu połączenia (kod DNS/TLS/reset) zamiast ogólnego „fetch failed" — kalibracja P1-14c w toku | Nagłówek user-agent w zapytaniu (część API odrzuca anonimowe klienty) |
| v11.35 | Cztery elementy backlogu: (1) P1-7 NTC — karta „Zdolności przesyłowe day-ahead" w zakładce Rynki (ENTSO-E A61, oba kierunki na granicach wybranego rynku, ocena „wąsko/szeroko" dla trwałości spreadów, nowy kind=ntc); (2) P2-16 MODEL v2 — profile typu dnia (roboczy/sobota/niedziela+święta, z Wielkanocą) jako alternatywa dla wagi dnia tygodnia: nocny retrening testuje OBIE siatki (60+36 kombinacji) i wybiera lepsze MAE per rynek, prognozy w aplikacji, daily-commit, mailach i panelu /moj rozumieją oba formaty parametrów (pełna kompatybilność wstecz — archiwalne krzywe liczą się po staremu); (3) P1-14c — niezbilansowanie LT z Baltic Transparency Dashboard (otwarte API bałtyckich OSP; parser defensywny, kalibracja: ingest?dry=1&baltic=1); (4) metodologia kalkulatora na landingu (rozwijana: co liczymy i czego NIE liczymy) | DE niezbilansowanie: netztransparenz.de wymaga rejestracji OAuth — pozostaje w backlogu z instrukcją; wymaga wklejenia nowego retrain.mjs do repo GitHub; dowW 3× na krańcu siatki = empiryczne uzasadnienie modelu v2 |
| v11.34 | A2 (domknięcie rdzenia historyjek) — PUBLICZNA KRZYWA KAPITAŁU na stronie głównej: dzienne skumulowane P&L modelu ze wszystkich rynków (rozliczone commity ze stemplem sprzed aukcji) na tle ideału przy pełnej znajomości cen; podpis z wynikiem od startu, capture i liczbą rozliczonych dób; sekcja pojawia się dopiero przy ≥3 dobach danych | Endpoint what=equity w /api/db; wykres w czystym SVG bez bibliotek (zero zależności, zgodnie z architekturą landingu); przy błędzie sekcja pozostaje ukryta |
| v11.33 | Widoczny pasek nawigacji w nagłówkach podstron /raport, /ranking i /moj: „← Strona główna" + linki krzyżowe (raport↔ranking, aplikacja) — sam link w logo (v11.32) był za mało zauważalny | Pasek ukrywany przy druku (@media print) |
| v11.32 | Nawigacja powrotna: logo „⚡ EnergyTrader" jest teraz linkiem do strony głównej na WSZYSTKICH podstronach (/app, /raport, /ranking, /moj) — wcześniej z podstron nie dało się wrócić na landing bez edycji adresu | Poprawka UX po zgłoszeniu użytkownika (27.07) |
| v11.31 | A5 — publiczny RANKING EUROPY: strona /ranking „gdzie w Europie bateria zarabia najwięcej" — dla każdego z 17 rynków najlepsza pojedyncza strategia [EUR/MW/dzień] dla baterii referencyjnej 1 MW / 2 MWh: arbitraż DA (ideał, śr. 30 dni) vs gotowość FCR/aFRR/mFRR (śr. 14 dni; PL z cen PSE, inne kraje z 17.1.B&C); paski, kolorowe etykiety strategii, jawne oznaczenie krajów bez publikacji cen mocy; CTA do planu dziennego; linki z landingu i raportu | Endpoint what=ranking w /api/db (jedno źródło logiki, strona renderuje z niego); projekcja roczna w hero; sekcja „jak to czytać" z zastrzeżeniami (prekwalifikacja, wykluczanie rynków, kary) |
| v11.30 | Naprawa werdyktu stackingu dla PL: FCR i mFRR były puste (null), bo odczyt z raportu PSE cmbp-tp używał złych nazw pól — poprawione na rzeczywiste (fcr_g, mfrrd_g/mfrrd_d); mFRR liczony teraz jako max z kierunków góra/dół (spójnie z aFRR); poprawka w what=stack i w mailu 06:30 | Nazwy pól potwierdzone w parserze aplikacji (jedno źródło prawdy); zasada: przy null w danych najpierw sprawdź nazwy pól, nie zakładaj braku publikacji |
| v11.29 | A4/P1-6 etap 1 — DZIENNY WERDYKT STACKINGU: porównanie arbitraż DA vs gotowość FCR/aFRR/mFRR dla parametrów baterii; w mailu 06:30 ramka „Gdzie dziś skierować aktywo" z wygraną strategią i przewagą ×, dla PL z cen PSE (cmbp), dla innych krajów z cen 17.1.B&C; endpoint what=stack (werdykt + historia 7 dni „kto wygrywał"); jawne zastrzeżenia (prekwalifikacja, wykluczanie rynków) | Uproszczenia etapu 1: gotowość = śr. cena mocy × 24 h × MW (pełna dyspozycyjność, bez energii aktywacji); pełna optymalizacja godzinowa i hybrydy — etap 2 |
| v11.28 | Osobisty panel subskrybenta /moj (dostęp kluczem z maila): PRYWATNA krzywa kapitału liczona w locie i deterministycznie — dla każdej doby prognoza wyłącznie z danych sprzed niej, parametrami modelu z TAMTEGO dnia (archiwum w commits), więc panel co do grosza zgadza się z historią maili; KPI (wynik, % dni zyskownych, capture, EUR/dobę), wykres model vs ideał, tabela ostatnich dób, zmiana konfiguracji przez ponowny zapis; link „Twój panel" w każdym mailu | Subskrybent = profil + konfiguracja (decyzja architektoniczna 20.07): żadnych danych wynikowych per użytkownik — wszystko funkcją (parametry × baza), pełna odtwarzalność |
| v11.27 | NORTH STAR (A3): spersonalizowane plany dzienne — zapis z parametrami baterii (rynek + MW/MWh, tabela subscribers w Neon, honeypot, wypis jednym kliknięciem), codzienny mail 06:30 (Brevo): plan wykonawczy na dziś z cen aukcyjnych, rozliczenie wczorajszego planu, sprawdzian modelu (prognoza sprzed aukcji vs ideał) i prognoza na jutro do jutrzejszej weryfikacji | Funkcje subscribe (/api/subscribe) i send-plans (harmonogram 04:30 UTC, ?dry=1); wymaga env BREVO_API_KEY + REPORT_SENDER; schema-subscribers.sql; USER-STORIES.md z mapą historyjek |
| v11.26 | Nowa architektura wejścia (decyzja UX 20.07): strona główna to LANDING dla inwestora magazynowego — hero „Ile zarobiłaby Twoja bateria?", kalkulator liczony na prawdziwych cenach PL z 30 dni (potencjał + ile model realnie chwyta), pasek track recordu na żywo, „jak to działa" w 3 krokach z akcentem na dowód, top spready dnia, CTA subskrypcji; kokpit ekspercki przeniesiony pod /app | Nowe endpointy /api/db: what=landing (pakiet wejściowy) i what=battsim (kalkulator); routing /app w netlify.toml |
| v11.25 | ETAP A trybu gościa (P1-12): publiczny raport dzienny online pod /raport (renderowany z bazy: ranking spreadów, plany magazynowe, aFRR z wnioskiem gotowość vs arbitraż, wyniki modelu, druk=PDF) + kafel publicznego track recordu na zakładce Rynki + CTA subskrypcji codziennych raportów (formularz Netlify „subskrypcja", zapisy z aplikacji i ze strony raportu) + przycisk „📄 Raport dzienny" w nagłówku | Lejek wartość→zachęta→kontakt wg koncepcji z 20.07; wysyłka e-mail (Resend) i pełne konta — etap B/C |
| v11.24 | Korekta reguły wyboru DAM po weryfikacji dwuźródłowej: cls=1 to day-ahead także w OMIE (potwierdzone zgodnością z EC co do grosza) — cls=1 ma pierwszeństwo zawsze; seria bez klasyfikacji (prawdopodobnie cena produktu godzinowego) tylko awaryjnie do czasu publikacji cls=1; IDA (cls≥2) zawsze odrzucane | Trzecia iteracja filtra — każda wymuszona przez v_price_mismatch, żadna przez przypadek; wymagany ponowny backfill |
| v11.23 | Adaptacyjny wybór aukcji day-ahead: semantyka klasyfikacji serii RÓŻNI SIĘ między OSP (DE: DAM=cls1; Hiszpania/OMIE: DAM=bez klasyfikacji, cls1-3=aukcje intraday) — filtr działa per doba: serie bez klasyfikacji mają pierwszeństwo, inaczej cls=1; wykryte przez v_price_mismatch (ES zawyżone 4-15 EUR przez zmieszanie DAM z IDA1) | Po deployu wymagany ponowny backfill (ingest?days=90) — nadpisze skażoną historię ES i podobnych stref |
| v11.22 | ETAP 3 „wszystko z bazy": serwer archiwizuje co godzinę OZE (generacja A75 + prognoza A69 — nowy kind=res, P1-14b ✅), niezbilansowanie (EUR po NBP przy zapisie) i ceny mocy 17.1.B&C — rotacja 4 stref/h, PL w każdym przebiegu; aplikacja czyta OZE/RB/ceny mocy NAJPIERW z bazy (odpowiedź natychmiastowa, bez limitów EC), żywe API tylko fallback | Parser ENTSO-E rozumie serie wolumenowe (quantity) obok cenowych; tabele res_hourly/imbalance/capacity (schema-etap3.sql); nowe what=res|imbalance|capacity w /api/db |
| v11.21 | Zakładka OZE jak RB: przegląd wszystkich rynków na GÓRZE i ładowany AUTOMATYCZNIE (raz na sesję, ~30 s/rynek — limity EC), przycisk uzupełnia tylko braki; dane OZE PRZEŻYWAJĄ auto-odświeżenia (wcześniej każde kasowało cały crawl), rynek główny zawsze świeży (prognoza OZE) | Zmiana po uwadze użytkownika — spójny wzorzec obu zakładek porównawczych |
| v11.20 | Karta cen mocy: unieważnienie wpisów cache przeglądarki sprzed kalibracji (nowy wariant adresu) + zasada „negatywnych werdyktów nie utrwalamy" — odpowiedź o braku publikacji nie jest zapamiętywana, kolejna próba pyta na świeżo | Domknięcie serii cache: CDN (Netlify-Vary) + localStorage |
| v11.19 | Ceny mocy 17.1.C DZIAŁAJĄ (pierwszy rynek: Austria — aFRR/mFRR up+down, FCR symetryczny, z dobą jutrzejszą = gotowa forward curve): finalna kalibracja zapytania wg dokumentacji (A81 + businessType=B95 stałe + processType per produkt + wymagany typ kontraktu), po 3 iteracjach na żywym API | KRYTYCZNA naprawa cache CDN: Netlify domyślnie ignorował parametry zapytań funkcji i serwował jedną odpowiedź dla wszystkich wariantów (nagłówek Netlify-Vary: query w entsoe i db); zapasowy alias /api/entsoe2; błędy bez cache |
| v11.18 | P1-8 (etap ENTSO-E): ceny zakontraktowanych mocy bilansujących [17.1.C, dokument A89] dla KAŻDEGO rynku — nowy kind=capacity (produkty FCR/aFRR/mFRR/RR, kierunki up/down, waluty krajowe przeliczane na EUR po NBP); w zakładce RB każdy rynek ma teraz kartę cen mocy (odpowiednik polskich cmbp-tp), z uczciwą adnotacją gdy OSP nie publikuje | Kandydackie EIC obszarów regulacyjnych także dla capacity; tryb debug=1 z metadanymi serii; kraje niepublikujące w 17.1.C → źródła krajowe pozostają w P1-8 |
| v11.17 | Rozróżnienie „awaria" od „źródło wygaszone": gdy ENTSO-E odpowiada „No matching data" dla wszystkich kandydackich obszarów (DE, Bałtowie po migracji 17.1.G), aplikacja pokazuje w tabeli porównawczej rzetelną informację ℹ️ o przeniesionej publikacji zamiast HTTP 502, bez zbędnych ponowień | Funkcja entsoe zwraca no_data (status 200) dla wygaszonych kanałów — koniec mylących błędów w Logu |
| v11.16 | Naprawa błędu „wiecznego pobierania" RB i OZE przy pierwszym otwarciu strony: warunki startu pobrań (RB PSE, OZE/pogoda/outages rynku głównego) sprawdzały STARY stan danych zamiast świeżo pobranego bufora — przy pustej pamięci nigdy nie startowały i działały dopiero od drugiego cyklu auto-odświeżania (~30 min); błąd ukryty od refaktoru v10.4 | Diagnoza: symulacja dokładnego zapytania aplikacji do PSE (dane były, zapytanie poprawne — nigdy nie wychodziło) |
| v11.15 | Porównanie rynków bilansujących przeniesione na GÓRĘ zakładki RB i ładowane AUTOMATYCZNIE po każdym pobraniu danych (przycisk został jako ręczne odświeżenie); kandydacki EIC bloku bałtyckiego dla Litwy | Zmiana po uwadze użytkownika (UX); ochrona przed równoległym uruchomieniem ładowania porównania |
| v11.14 | Niezbilansowanie DE/SE naprawione: ENTSO-E przeniósł publikację między obszarami regulacyjnymi (TenneT DE przestał publikować pod 17.1.G) — funkcja próbuje listy kandydackich EIC po kolei (DE: 4 OSP + strefa, SE: obszar kraju) i zwraca użyty obszar (eic_used); rozdzielone pobrania CRB i kursu NBP (awaria jednego nie zabija drugiego) + błędy RB głośno w Logu zamiast cichej konsoli | Odpowiedź 502 zawiera teraz listę próbowanych obszarów (tried) |
| v11.13 | Naprawa walut niezbilansowania: ENTSO-E publikuje ceny w walutach KRAJOWYCH (CZ→CZK, HU→HUF, SE4→SEK…), a aplikacja traktowała je jako EUR — tabela porównawcza RB zawyżała te rynki nawet ~25×; teraz funkcja zwraca walutę z dokumentu, a aplikacja przelicza na EUR po pełnej tabeli kursów NBP (z mnożnikami, np. HUF za 100) | Wykryte przy weryfikacji zakładki RB (CZ ~4400 „EUR" = 4400 CZK ≈ 178 EUR) |
| v11.12 | Czytanie z własnej bazy jako pierwsze źródło (aplikacja: /api/db, raporty: 1 zapytanie SQL; żywe API tylko fallback); migracja dziennika przeglądarki do serwerowej tabeli commits (przycisk ☁️, klucz MIGRATE_KEY, pochodzenie wierszy jawnie oznaczone); nocny retrening wszystkich rynków na GitHub Actions (02:30, siatka 48, walk-forward 60 dób → model_params) — parametry sezonowości płyną do daily-commit i aplikacji, wagi OZE/pogody pozostają lokalne | Nowe funkcje: db.mjs (prices/params/track), migrate-commits.mjs; paczka github-retrain/ (workflow + skrypt + README); schema-etap2.sql |
| v11.11 | Serwerowy dziennik paper tradingu w bazie (backend etap 1): daily-commit liczy rekomendacje dla WSZYSTKICH 17 rynków z własnej historii cen w Neon (1 zapytanie SQL zamiast 17 wywołań API) i zapisuje je do tabeli commits (pierwsza rekomendacja wiąże — bez nadpisywania); ingest co godzinę rozlicza commity po publikacji cen (real/pnl/ideał) i ma tryb backfillu historii ?days=N (do 370); widok v_track_record w bazie | Netlify Forms pozostaje kanałem powiadomień (3 rynki, 1 wpis/dzień — limit 100/mies.); schema-etap1.sql |
| v11.10 | Jednorazowa jawna korekta rozliczeń paper tradingu z dostaw 17–20.07: przeliczenie na poprawnych cenach day-ahead po naprawie parsera ENTSO-E (v11.9); stare wartości (kup/sprz., wynik, ideał) i powód korekty zapisane w metryce audytowej pozycji, oznaczenie ⚠ KOREKTA w szczegółach rozliczenia i wpis w Logu | Zasada track recordu: żadnych cichych zmian w dzienniku — każda korekta z pełnym śladem: co, kiedy i dlaczego |
| v11.9 | Kontrola jakości dwuźródłowa (backend etap 0) wykryła i naprawiła błąd cen ENTSO-E: dokument A44 zawiera oprócz day-ahead także aukcje intraday (IDA) — parser mieszał je w „cenę godzinową" (rozjazd do 23 EUR/MWh w dolinie solarnej DE-LU); teraz wybierana jest wyłącznie aukcja day-ahead, a przy podwójnej rozdzielczości kwadranse (metodyka uśredniania jak w EC) | Serwerowa baza Neon + funkcja ingest co godzinę (ceny 17 rynków dwuźródłowo, PSE raw, prognoza OZE, NBP) — widok v_price_mismatch; tryb debug=1 w /api/entsoe (metadane serii) |
| v11.8 | ENTSO-E źródłem PODSTAWOWYM cen day-ahead (aplikacja + report-data + daily-commit), Energy-Charts zdegradowane do rezerwy; ładowanie OZE wszystkich rynków w tempie zgodnym z limitami EC (~30 s/rynek, tabela rośnie na bieżąco) | Wg odpowiedzi Fraunhofer ISE (17.07): limit /price to 2 zapyt./min/IP (burst 2), IP funkcji Netlify współdzielone, wiszące połączenia to ich błąd (kolejka bez timeoutu); ⚠ CC BY 4.0 nie obejmuje wszystkich stref /price — nota licencyjna w backlogu (P1-12) |
| v11.7 | Naprawa CICHEJ utraty pozycji portfela: przepełniona pamięć przeglądarki (archiwa logów z dni awarii + duże odpowiedzi cache ENTSO-E) blokowała zapis nowych pozycji bez żadnego komunikatu — zapis automatycznie czyści cache/stare logi i ponawia, a niepowodzenie jest głośno logowane | Sprzątacz localStorage (cache odtwarzalny, logi 3 dni zamiast 7, limit wpisu cache 150 KB); etapy paper tradingu (backfill/auto/rozliczenie) chronione osobno — błąd jednego nie blokuje pozostałych |
| v11.6 | Backfill uzupełnia KAŻDĄ brakującą dobę portfela, także dziurę PRZED najnowszą pozycją (awaria danych rano + zapis na pojutrze po aukcji blokowały odtworzenie dnia bieżącego); kolejność źródeł cen: najpierw bezpośrednio z przeglądarki, proxy Netlify jako rezerwa (EC zwraca 429 dla IP chmurowych) | Fallback ENTSO-E w report-data w partiach po 4 z priorytetem PL/DE-LU — koniec timeoutów przy 11 równoległych zapytaniach |
| v11.5 | Naprawa ładowania rynków: Energy-Charts od pewnego czasu przetrzymuje nadmiarowe połączenia zamiast je odrzucać (stąd tylko ~5 rynków) — zapytania mają teraz twardy timeout 15 s, a ceny day-ahead automatycznie przełączają się na awaryjne źródło ENTSO-E (własny token); to samo w funkcjach serwerowych report-data i daily-commit (timeout + pobieranie równoległe + fallback ENTSO-E) | AbortSignal.timeout we wszystkich fetchach; diagnoza: API EC niedostępne z IP chmurowych, monitoring zewn. 70% błędów public_power w 30 dni |
| v11.4 | Tabele „wszystkie rynki" (OZE i RB) zawsze listują komplet rynków — te bez danych z adnotacją jak je doładować; wybór rynku w selektorze u góry dokłada go do tabeli porównawczej po pobraniu danych | Poprawka po zgłoszeniu: tabela porównawcza pokazywała tylko rynek główny, niezależnie od wyboru |
| v11.3 | Metryka audytowa rozliczeń paper tradingu: każda rozliczona pozycja zapisuje kiedy, z jakiego źródła i po jakich cenach godzinowych została rozliczona — klik na status „rozliczona" pokazuje pełny rachunek z linkiem weryfikacyjnym do API; kolumny settled_at / price_source / hourly_prices w eksporcie CSV | Dowód pochodzenia cen (audit trail) — wymóg wiarygodności track recordu |
| v11.2 | Raporty automatyczne dla wszystkich 17 rynków z rankingiem po SPREADZIE dobowym (kluczowa metryka baterii, nie średnia), sekcją spreadów cross-market i sekcją aFRR PL: dzienne min/max/śr osobno dla kierunków up i down (podstawa forward curve gotowości) z porównaniem „gotowość vs arbitraż" | Endpoint report-data: 17 rynków sekwencyjnie (limit API), pole afrr_pl z cmbp-tp, zestaw rynków konfigurowalny (env MARKETS_REPORT) |
| v11.1 | Kalibracja outages na realnych danych PL: alarmem są NAGŁE ubytki mocy (start <36 h, próg 300 MW), sezon remontowy (~10 GW planowych rewizji) pokazywany informacyjnie w GW | Deduplikacja rewizji dokumentów ENTSO-E (per jednostka MAX zamiast sumy nakładających się wpisów) |
| v11 | Realizm baterii: DoD (pojemność użyteczna = MWh × DoD) i ułamkowy limit cykli/dobę — przy limicie <1 portfel cykluje tylko w najlepsze dni (próg z kwantyla zysków 30 dni); parametry w zakładce Prognoza i w daily-commit (env STORAGE_DOD). Outages (P0-5): niedyspozycyjności mocy wytwórczych z ENTSO-E (A80) — alert przy >500 MW z listą największych zdarzeń | Nowy kind=outages w funkcji ENTSO-E z tolerancyjnym parserem dokumentów Unavailability; dane ładowane dla rynku głównego przy każdym odświeżeniu |
| v10.5 | Serwerowy dziennik wielorynkowy (P0-4): codzienny commit dla rynków z konfiguracji (domyślnie PL+DE-LU+CZ) jako JEDEN zbiorczy wpis dziennie (~31/mies., w limicie Forms); parametry magazynu ze zmiennych środowiskowych; tryb testowy ?dry=1 bez zapisu | Konfiguracja przez env: MARKETS, STORAGE_MW/MWH/EFF |
| v10.4 | Dzienne archiwum logu: zapis per dzień (7 dni wstecz), wybór dnia i pobieranie pliku .txt | Naprawa wyścigu trening ↔ auto-odświeżanie (blokada wzajemna: odświeżanie wstrzymane na czas treningu, wznowienie po); atomowa podmiana danych przy odświeżeniu — czytelnicy nigdy nie widzą pustego stanu |
| v10.3 | Opcja pełnej siatki 540 kombinacji w treningu zbiorczym (checkbox); czas treningu w podsumowaniu | Trening w pełni asynchroniczny z licznikiem postępu — interfejs nie zamiera przy długich obliczeniach; wspólny silnik siatki dla treningu pojedynczego i zbiorczego |
| v10.2 | Trening zbiorczy wszystkich rynków: jeden przycisk trenuje model każdego załadowanego rynku (opcjonalnie z głęboką historią 365 dni per rynek) i zapisuje parametry — każdy portfel paper tradingu działa na własnym wytrenowanym modelu; zbiorcza tabela MAE/capture per rynek | Skrócona siatka 48 kombinacji, sekwencyjnie z oddawaniem wątku UI, postęp w liczniku i Logu |
| v10.1 | Głęboka historia treningu (P0-3): pobranie 180/365 dni cen dla rynku głównego — trening i backtest walidują się na całym okresie (prognoza celowo waży ostatnie 60 dni); dane przeżywają auto-odświeżanie | Źródło Energy-Charts z awaryjnym ENTSO-E (limit dayahead podniesiony do 370 dni); scalanie historii bez duplikatów |
| v10 | Pogoda jako cechy modelu (P0-2): temperatura (kanał popytowy, zawsze) oraz wiatr 100 m i nasłonecznienie (zastępczo, gdy prognoza OZE nieaktywna — np. doba D+2); regresje i korelacje uczone z danych, waga pogody w treningu walk-forward per rynek; opis aktywnych kanałów w prognozie | Źródło open-meteo (ICON/ECMWF, do 90 dni historii + 3 dni prognozy), proxy /api/wx, cache 60 min, ogranicznik korekty ±40 EUR/MWh |
| v9.4 | Audyt kontekstu rynku po zgłoszeniu użytkownika: rekomendacja arbitrażu w „Prognozie" (i raporcie dziennym) filtrowana do par wybranego rynku | Stabilna kolejność rynków we wszystkich widokach (wg listy rynków, nie kolejności pobrania) — deterministyczne KPI zakładki „Rynki", domyślne rynki selektorów i kolumny eksportu CSV |
| v9.3 | Poprawka profilu Spread Trader: rekomendacje filtrowane do par z udziałem wybranego rynku, opis z jego perspektywy (tańsza/droższa strona pary) | — |
| v9.2 | Stack przychodów magazynu (PL): dzienne porównanie FCR / aFRR / mFRR / arbitraż DA — średnie, projekcja roczna, odsetek wygranych dni, wykres skumulowany, automatyczny wniosek „gdzie kierować aktywo" | Analiza na danych cmbp-tp + DA×NBP; jawnie opisane założenia metodyczne |
| v9.1 | Historia wersji w aplikacji (ta tabela — kliknięcie w znaczek wersji) | — |
| v9 | Profile użytkownika: Magazyn / Odbiorca / Producent / Spread Trader — dedykowane parametry i rekomendacje (oszczędności z przesunięcia zużycia, przychody producenta i ryzyko curtailmentu, wartość magazynu przy farmie, pary spreadowe) | Parametry profili zapamiętywane per profil |
| v8.3 | RCE (rynkowa cena energii) na wykresie RB; ceny mocy bilansujących PSE (FCR/aFRR/mFRR, w górę/w dół) — usługi systemowe; rachunek transakcji (konfiguracja → koszt → przychód → wynik) w dzienniku serwerowym i rekomendacjach | Generyczny klient raportów PSE z paginacją |
| v8.2 | Pod-zakładki portfeli: Σ Razem + osobny widok i dziennik każdego rynku; eksport CSV per widok | — |
| v8.1 | Rozszerzenia na wszystkie rynki: wybór rynku mapy cieplnej, tabela porównawcza OZE (beta/korelacja/sygnał), tabela porównawcza rynków bilansujących | Hurtowe doładowanie danych partiami z licznikiem |
| v8 | Portfel paper tradingu dla każdego rynku osobno; tabela wyników per rynek; łączna krzywa kapitału | — |
| v7.2 | Domyślnie wszystkie 17 rynków; przycisk „Wszystkie"; wybór rynków zapamiętywany | — |
| v7.1 | Automatyczne odświeżanie danych: co 30 min, po 13:00 co 10 min do publikacji aukcji, odświeżenie przy powrocie do karty; status z czasem aktualizacji | Ochrona przed równoległym ładowaniem; krótszy cache cen |
| v7 | Ceny niezbilansowania ENTSO-E dla wszystkich rynków (kategorie A04/A05) w zakładce RB z wyborem rynku | Integracja ENTSO-E przez funkcję serwerową (token tylko w zmiennych środowiskowych); parser XML + obsługa archiwów ZIP (w tym strumieniowych); tryb diagnostyczny |
| v6 | Paper trading: wirtualny portfel z automatycznym zapisem rekomendacji i rozliczaniem po publikacji cen, benchmark ideału, dziennik z eksportem; odtwarzanie zaległych dni po przerwie (🔁); serwerowy dziennik commitów (codzienny zapis rekomendacji przed aukcją, stemplowany czasem) | Funkcje serwerowe Netlify: /api/report-data (stały endpoint dla raportów automatycznych), daily-commit (harmonogram); naprawa raportów automatycznych |
| v5 | Pełna dwujęzyczność PL/EN (interfejs, rekomendacje, raporty, wiedza) | Słownik ~70 kluczy + tłumaczenia dynamiczne; wybór zapamiętywany |
| v4.1 | Formularz opinii/błędów z automatycznym kontekstem technicznym | Netlify Forms (bez backendu), zabezpieczenie antyspamowe, awaryjna wysyłka e-mail |
| v4 | Pełny log zdarzeń (połączenia, dane, ML) z eksportem; okno czasowe analizy wzorców (7/14/30 dni/własne); OZE dla wszystkich rynków (doładowanie na żądanie); parametry modelu uczone osobno per rynek | Rejestrowanie każdego zapytania: URL, czas, próba, wynik |
| v3.1 | — | Pobieranie partiami po 3 rynki, automatyczne ponowienia przy limitach API (429/5xx), cache odpowiedzi w przeglądarce, licznik postępu |
| v3 | Rynek bilansujący PSE (CEB/CEN w PLN, porównanie z DA po kursie NBP); prognoza ML łącząca sezonowość z korektą OZE; generator raportu dziennego (e-mail/schowek) | Wdrożenie na Netlify z proxy API (eliminacja CORS); podwójny kanał połączeń z fallbackiem |
| v2 | Moduł OZE: generacja wiatr+PV vs cena, regresja beta, prognoza OZE na jutro, sygnał fundamentalny w rekomendacjach; zakładka wiedzy o rynku (DAM/intraday/RB, PSE/TGE/URE, BRP/BSP, checklista wejścia) | Treści oparte o wiki projektowe IEOP (Notion) |
| v1 | Dashboard cen day-ahead 17 rynków europejskich; analiza wzorców (profile godzinowe, dni tygodnia, mapa cieplna, spready); prognoza cen na jutro; rekomendacje magazynowe kup/sprzedaj; backtest walk-forward; trening modelu (przeszukiwanie parametrów) | Aplikacja jednoplikowa HTML/JS, Chart.js; dane Energy-Charts; parametry w localStorage |