Chování 4Q elektroměru XT211, komunikace

[Mex]

Tak hlásím, že data na portále zpětně doplnili.

Ještě dnes dopoledne to tam nabylo, teď odpoledne už to tam je.
Podle grafu to vypadá věrohodně, má to takový ten klasický tvar křivky solární výroby s občasnými výpadky.
Nicméně to ještě dodatečně ověřím podle svých dat, která mám v minutových intervalech nachytaná z elektroměru.

Pokud to z elektroměru dodatečně vytáhli až teď, tak to znamená, že má paměť podrobných dat zřejmě aspoň na měsíc.

Na reklamaci mi dosud stále neodpověděli.

[Kajap]

Chápeš, že se bude fakturovat podle těch konečných stavu - na 99%, je to jenom moje spekulace ale cokoliv jinýho by byla přeci...

Uvědomujete si, že to co zmiňujete je pro pevné tarify, ale nikoli pro dynamické alias spotové? U spotového tarifu jako má Mex se cena průběžně mění a když nebudou mít data o tom jaký odběr byl v jednotlivých časových úsecích z rozdílnou cenou, tak jim zřejmě jen koncový stav stačit nebude. Když to přeženu ad absurdum pokud by celý odběr za chybějící den byl jen krátkodobý a spadal by zrovna do záporné ceny pak pokud by mu naúčtovali cokoli víc tak by ho v podstatě obrali a ne jeho vinou.

Ty data se buď přenesou na konci měsíce celý a kdyby se ztratila tak se udělá podle diagramu dopočet.

Víš že tady spekulujeme?

Jedině že bude mít přesný data on u sebe tak si to pak může porovnat ale předpokládám že asi odchylka nalezena nebude a jestli jo tak i podle toho diagramu jsou naprosto minimální - to by pak totiž nějak nemoh fungovat vůbec celý velký trh, tý elektřiny se musí vyrobit tolik kolik spotřebuje takže ty charakteristiky odběru jsou víceméně jak prdel na hrnec

[Valdano]

Víš že tady spekulujeme?

Samozřejmě, že jen spekulujeme.

Jedině že bude mít přesný data on u sebe tak si to pak může porovnat

Vždyť to Mex píše hned o příspěvek výš, že má podrobná data po minutách, a že si to překontroluje. To, že má podrobná data po minutách tady psal už i v předchozí části tohoto tématu.

předpokládám že asi odchylka nalezena nebude...

Pokud už to načetli ať už z paměti elektroměru nebo z jiné databáze kde to mohli mít klidně už od toho předmětného dne, tak by to mělo samozřejmě sedět.

Může to být klidně i tak jak zde spekuloval glottis když zmínil to, že to co je viditelné pro koncového uživatele na distribučním portálu je jen taková ukázka na koukání a nejsou to data pro fakturaci. Ta surová data, ze kterých se skutečně vychází při fakturaci tedy mohou být v úplně jiné databázi, která pro uživatele dostupná není. Když se něco podělá v databázi pro uživatele tak se nic neděje a provozovatel portálu to může dodatečně načíst z jiné databáze nebo je možné i to, že se opravy dělají automaticky při nějakých synchronizacích dat mezi těmi různými databázemi. Tomu by ostatně nasvědčovalo i to co zde uvedl pave69, který podobné výpadky dat v minulosti také zaznamenal a zpožděním se data na portálu uživatele objevila i když nic nereklamoval.

[Mex]

To s různými databázemi je samozřejmě možné, ale připadá mi to dost nepravděpodobné.
Zdroj dat je jen jeden - elektroměr. Tak jaký půvab by mělo brát z něho data a 2x je nezávisle ukládat?

Obecný trend informatiky je spíš mít data jen jednou a pokud možno spolehlivě.
Takže bych si tipnul, že to všechno leze z jedné databáze. A v ní že prostě ten den 22.8.2026 chyběl, ať už z jakéhokoli důvodu.
Např. že jsem měl ten elektroměr v době přenosu vypnutý, protože jsem zrovna něco montoval v rozvaděči.

Asi nemají kontrolu na konzistenci dat průběžnou, ale zřejmě jen na konci měsíce, před exportem dodavatelům elektřiny.
A když zjistí, že někde něco chybí, tak si to dožádají.
A funguje to až se zpožděním. Data za předchozí den už tam dopoledne byla, ale ten chybějící den se tam objevil až později odpoledne.

Jak jsem psal, zkontroluju to. Jen to nebude hned, trochu nestíhám.
A mám to v úplně jiném formátu, tak si na to musím napsat nějaký konverzní program.

[Valdano]

To s různými databázemi je samozřejmě možné, ale připadá mi to dost nepravděpodobné.
Zdroj dat je jen jeden - elektroměr. Tak jaký půvab by mělo brát z něho data a 2x je nezávisle ukládat?

Důvodem může být bezpečnost. Primární by měla být databáze surových dat, která zřejmě nebude přístupná přes žádný pro uživatele dostupný portál. Pouze do této databáze se ukládají surová data z elektroměrů. Databáze, ze které se zobrazují data na portálu uživatelům pak může být jen kopií části vyseparovaných dat ze zdrojové databáze surových dat přičemž se ta separace a kopie nejspíš provádí v nějakých periodických intervalech automaticky a občas se zřejmě může stát to, že se něco nepodaří a pak se to s nějakým zpožděním automaticky opraví.

Obecný trend informatiky je spíš mít data jen jednou a pokud možno spolehlivě.

Dovolím si nesouhlasit. Jsem z oboru a provozujeme několik serverů kde jsou primární zabezpečené databáze dat z různých technologií a z nich se pro různé účely provádějí automatické separované přírůstkové kopie do jiných menších a méně důležitých databází. Primární databáze jsou obvykle redundantní se synchronizací dat a jsou provozovány na samostatných oddělených strojích dokonce v různých budovách. Replikační kopie z primárních do méně důležitých databází se nedělají obvykle z důvodu velkých datových objemů.

[Mex]

Tak možné by to bylo.
Ale opět - nebylo by myslím úplně logické, že by tu uživatelskou databázi dělali přírůstkově. Že by každý den přihodil další den, a občas na něco zapomněli.
Kdybych to dělal, tak bych jednoduše v noci, po importu dat z elektroměrů, prostě zreplikoval tu master-databázi do nějaké té uživatelsky přístupné kopie.

[Valdano]

Nemáme informace o tom, jak to mají v reálu řešeno a i kdyby jste se jich na to zeptal tak vám to dle mého názoru neřeknou a ani nesmí. To jsou čistě interní důvěrné informace. Takže bych to uzavřel s tím, že ať už je to jakkoli tak vámi zmíněná chybějící data už na portálu jsou a vše je tedy OK. Nic víc se k tomu už stejně nedozvíme a tak nemá moc smysl se o tom ani dohadovat.

[Mex]

Zatím mi sice neodpověděli na můj dotaz/stížnost.
Ale jsem optimista a věřím, že mi časem odpoví.
A třeba se něco nového dozvíme.

[pave69]

Prosím nepamatuješ si náhodou, jestli v té době, kdy Ti tam něco chybělo, jestli jsi nevypínal hlavní jistič?

Nemyslím si, tyhle věci nedělám. Prostě se nějaké dny objevily s hodně velkým zpožděním, možná až po konci měsíce.

[glottis]

To s různými databázemi je samozřejmě možné, ale připadá mi to dost nepravděpodobné.
Zdroj dat je jen jeden - elektroměr. Tak jaký půvab by mělo brát z něho data a 2x je nezávisle ukládat?

Obecný trend informatiky je spíš mít data jen jednou a pokud možno spolehlivě.
Takže bych si tipnul, že to všechno leze z jedné databáze. A v ní že prostě ten den 22.8.2026 chyběl, ať už z jakéhokoli důvodu.
Např. že jsem měl ten elektroměr v době přenosu vypnutý, protože jsem zrovna něco montoval v rozvaděči.

Uz je to trosku off topic ale ... naopak je to dost bezne, ze se pro takovyhle provoz, kdy nejake miliony zarizeni hrnou v urcitem intervalu obrovska kvanta dat, pouzije na vstupu nejaky buffer, fronta. Treba uplne na jine technologii co to zvladne prijmout. treba Kafka je na to jak delana. Ukladat opravdu jen surova data pekne za sebou do souboru. Nasledne to pak nejaky proces schroupe a pouklada do pomalych relacnich databazi nebo jinych timescale. Pritom treba se rovnou neco prepocita, ceny, statistiky. Kdyz se objevi chyba, databaze se vyprazdni, posunou se jen indexy v kafce a cele se to sesrotuje znovu.

[Mex]

Stáhl jsem z portálu EGD export za srpen.
Vypadá to, že ta chybějící data tam doplnili podle reálného stavu, takže potud OK.

Ale ta vyexportovaná data nesedí úplně přesně na sumární počítadla elektroměru.
Za ten měsíc je tam odchylka něco přes 3 kWh u výroby (z cca 1100 kWh), a cca 1 kWh u spotřeby (z cca 35 kWh).
Oboje je náhodou pro mě dobrým směrem (výrobu nadhodnotili, spotřebu podcenili), takže mi to nevadí.
Ale nesvědčí to příliš dobře o použitých technologiích a nástrojích.

Vzniklo to zřejmě zaokrouhlováním. Data mají v kWh na 2 desetinná místa, a tedy s granulitou 10W.
Nicméně samo zaokrouhlení výsledku by při správném zpracování nemuselo dělat chybu.
Jsou to rolující počítadla, takže co se kvůli zaokrouhlení neuplatní v jedné 1/4-hodině, má přetéct do té následující.

Pak jsem dneska dostal mailem sumární tabulku o spotřebě a výrobě. Opět v Excelovém formátu.
Ta už je organizovaná jinak.
Má časovou značku a 12 sloupců, ale reálnou informaci nesou jen 2 z nich.
Tady už jsou čísla zobrazená na 4 desetinná místa. Ale vlastní data jsou tam uvedena jen na 2 desetinná místa.
Prostě základní školácké chyby při práci s velkými daty, na opakování u zkoušky.
Ta data dávají stejný výsledek jako ta z exportu z portálu, takže jsou evidentně ze stejného primárního zdroje.
A tedy ani zde nesedí na stavy sumárních počítadel.

A ani v jedné sadě dat to není rozlišeno podle odběru v různých tarifních pásmech (VT/NT).
Takže ze 12 sloupců je jich tam 10 zbytečně, ale už se tam nevešla informace v jaké sazbě to bylo účtováno.
Jistě se to dá zpětně dopočítat ručně při znalosti časů jednotlivých pásem.
Otázkou je, jak by to bylo někdy zpětně.
Jestli třeba za 5 let při nějaké kontrole někdo zjistí, jaké spínací časy platily v srpnu 2026.
Navíc v Excelu se s tím bude asi bude pracovat dost špatně, takže to bude chtít spíš nahrát do nějaké databáze.

Nevím proč se mi pořád dere na jazyk poznámka o ne-úplně-nejostřejších tužkách v penálu.

[thesaro]

Problém může být, že různá odběrná místa mají různě stanovenou dobu VT v různých oblastech. Podle mě to spárují až v datech zaslaných obchodníkovi, kdy si vytáhnou konkrétní časy VT pro konkrétní OM v daném období. A obchodník dostane tabulku se spotřebovanými kWh a cenou za distribuci za každou čtvrthodinu měsíce. No a musí k tomu ještě přimíchat data z EDC kvůli sdílení a teď nově od září i vyhodnocování technické flexibility a zohledňování aktivace regulační energie (SVR).

A jednoho krásného dne, až dojde k tarifní reformě u NN, zmizí tohle předpotopní dělení na VT/NT a budou třeba dynamické ceny distribuce v průběhu dne. Nebo si začnem hlídat čtvrthodinová maxima, což by se spotřebou domácnosti taženou střídačem+baterkama mohla být celkem brnkačka.