MyPower.CZ

bud to bola chyba optiky, alebo aurora. momentalne je v severnych lokalitach viditelna. digital ju zachyti, aj keď ju oko nevidi. ale priklanam s k prvej moznosti.

Pružiny budou asi optimální řešení, které by mělo pokrýt ten roztažný prostor aniž by byly články volné.

tak mel tam pripojene tesly. Tam to nastavuje celkem presne a pokud ma proudy a vykony nakoukane, muzes se tim orientovat. Neni to zapojovani nahodnych spotrebicu abych to nejak zatizil. Ale ze to nerekl je jina vec. Treba 6kw je 2x 13A pri 230V. A tech nastavenych 13 tam vicemene potece. Zajimave bylo takhle vedle sebe ty mp2 videt. Hlavne jejich trafa. To nove je vetsi, plossi. Muze se lip chladit.

V originál aplikaci to jde taky zapínat a vypínat, jedině že by jsi to měl v aplikaci zakázané tak stejně to jde ovládat externě vypínačem, zase to musí být v aplikaci povolené. Ta aplikace originál co má na obrázku je OK, ta nejnovější co je je šmejdská a nedoporučujuji vůbec používat!

Kdyz udelam box a necham prostor 2,5mm tak tak tam budou clanky volne. Nejlepsi varianta je asi fakt ta pruzina. Ja mam na baterkach 6xM10 zavitovky a stahnul jsem to proste aby to drzelo po hromade a dala se baterka presunout. Mam na kazde strane dva jekly 40x40 a za nima cetris co je deli od clanku. Je to stazene ze baterka drzi po hromade ale s jekla a jde hybat nejsou jak pribite🤣 Me teda clanky prisli ne uplne rovne takze na sobe nelezi celou plochou.

Odskúšané, funguje. Síce to pri zapojení píše bežnú cenu, nakoniec vo výpise je konečná suma nula. Akurát že mi to nabíjalo max 80 kW namiesto 180 kW, možno to robia schválne 😃

Hodně staré vlákno, ale.... Viděl někdo na trhu ty balancery? Nebo to byl jen pokus, jak získat nějakou tu finanční podporu/dotaci? Osobně mě ten projekt přišel jen jako účelová snaha o získání finančních prostředků. Vymyslet produkt, který je hodně diskutovaný, nabídnout řešení, obalit to do líbivého obalu a předhodit před obecenstvo... A pak jen čekat a doufat, že to vyjde a připluje pár kapříků. Z mého pohledu jak tenkrát, tak i nyní o skutečnou výrobu a vyřešení problému vůbec nešlo... Cílem byla výhra a "ocenění". Nebo že by se ty balancery dali někde koupit?

Přesné měření SOC v BMS závisí na sofistikovaných algoritmech (jako je rozšířený Kalman filtr EKF), které berou v úvahu napětí, proud, teplotu a historii používání, spíše než na konkrétním modelu BMS a také na přesnosti měření; pokročilé algoritmy jako je např. Kalmanův filtr (UKF), zlepšují přesnost SOC o 10 až 15%. Klíčem je kombinace coulombovského počítání (integrace proudu) s měřením napětí a vnitřního odporu (impedance). Co ovlivňuje přesnost: Algoritmy: Pokročilé algoritmy jsou klíčové, protože baterie se chovají nelineárně. EKF efektivně zpracovává dynamiku baterie. UKF je přesnější o 10 až 15%. Metody: Kombinace coulombovského počítání (sledování náboje) a napěťových měření (napětí naprázdno) a testování impedance (vnitřního odporu) pro SOH. Vstupní data: Přesnost závisí na kvalitě dat z čidel (napětí, proud) a jejich zpracování. Potřeba individuální kalibrace čidel a měření s tím také souvisí. Výběr modelu pro odhad SOC/SOH Coulombovo počítání: Jednoduché a efektivní pro systémy, kde není kritická vysoká přesnost. Nejlépe kombinovat s korekčními algoritmy, aby se zabránilo driftu. Kalmanovy filtry (EKF, UKF): Skvělé pro nelineární lithium-iontové baterie. EKF je široce používaný, ale UKF nabízí lepší přesnost při složitých dynamikách. Dvojité nebo společné filtrační modely: Ideální, pro odhady SOC a SOH současně, zejména u systémů čelících stárnutí nebo teplotním výkyvům. Modely strojového učení: Vhodné pro systémy, které mají přístup k rozsáhlým datům o článcích. LSTM nebo stromové modely poskytují adaptivní přesnost, ale vyžadují více výpočetního výkonu. Požadavky na hardware a integrace Přesné senzory: Napěťové, proudové a teplotní senzory s nízkým šumem jsou klíčové. Kvalita senzoru přímo ovlivňuje přesnost odhadu, ale také i cenu. Přesné meření: Přesné měření souvisí se schopnostmi BMS dané omezenými možnostmi ADC. Vyšší přesnost znamená vyšší náklady, které výrobce cenově dostupných BMS nejsou ochotni akceptovat z důvodu obav o významné snížení prodejnosti. Výpočetní výkon: V závislosti na složitosti algoritmu (zejména ML modelů) by měl mít systém BMS dostatečný výpočetní prostor. Tepelný management: Jelikož teplota ovlivňuje chování a měření baterie, je vhodné integrovat teplotní senzory článků pro kompenzaci meření. Budoucnost Do roku 2030 se očekává, že odhadování SOC a SOH bude výrazně přesnější, přičemž chyby se zmenší díky: - Vylepšeným technikám fúze dat kombinujícím data ze senzorů a AI poznatky. - Algoritmům schopným se učit trendy stavu baterie v reálném čase. - Lepší integraci s BMS, optimalizujícím jak hardware, tak software. Závěr Neexistuje jedna univerzální „nejlepší“ BMS. Je třeba hledat systémy, které používají pokročilé adaptivní algoritmy (např. EKF, UKF) a kombinují více metod měření díky čemuž pak poskytují přesnější odhady SOC a SOH. Pro konkrétní aplikace je třeba hledat BMS s prokazatelně dobrými algoritmy pro odhad stavu. Info k JK-BMS Výpočet nebo odhad stavu nabití (SOC) je u JK-BMS jedním z nejčastějších problémů. Zejména po několika týdnech neúplného nabití a resetování BMS na 100 % se SOC může odchýlit až o 60 %, a to není dobré! Autor videa níže testuje přesnost SOC u JK-BMS v porovnání s Victron Smart Shunt. https://www.youtube.com/watch?v=L0oW0zcO-_I Test odhalil významný posun stavu nabití (SOC) u JK-BMS, zejména po obdobích bez plného nabití. Analýza dat zkoumá potenciální příčiny a strategie pro zmírnění těchto problémů. Jak je zmíněno pod videem na YouTube tak podobný problém existuje i u BMS DALY. Rozdíl mezi DALY 4S12V200A a Victron SmartShunt je "někdy" 25 až 30%. Zajímavé jsou následující příspěvky na YouTube pod tím videm. Problém je pravděpodobně v kombinaci nedostatečné přesnosti ADC a špatně naprogramovaného firmwaru. Obecně řečeno, pokud máte BMS s limitem (řekněme) 100 A nebo 200 A, rozsah měření proudu pro ADC bude alespoň dvojnásobný. To znamená, že k získání přesných jemnozrnných hodnot je potřeba alespoň 12bitový ADC a je lepší mít 16bitový ADC (ty jsou obvykle zabudovány v samotném mikrokontroléru). Navíc musí být naprogramován tak, aby odebíral mnoho vzorků za sekundu, aby se vypořádal s harmonickým zkreslením zpětně reagujícím ze strany střídače připojeného k bateriovému systému. To zhruba znamená více než 4000 vzorků za sekundu. (1000 vzorků za sekundu je jeden vzorek na 1 ms a cyklus střídavého proudu je pouze ~16 ms, což nestačí k řádnému zohlednění harmonického zkreslení tvaru vlny). Je tu také kalibrace nulového proudu... no, potřeba jsou dvě kalibrační hodnoty. Nulový proud (protože operační zesilovače obvykle mají napěťové ofsety) a také pevný kalibrační proud 1 A nebo 10 A pro škálování (protože přesné rezistory nejsou dostatečně přesné). Pro výrobce se i v těchto případech snadno splete. Ale bez přesnosti ADC a vysoké vzorkovací frekvence nezáleží na tom, jak dobře je BMS kalibrováno. Vsadím se, že Victronův bočník má pro svůj proudový smysl mnohem lepší algoritmy. Na naší straně... na straně uživatelské konfigurace se vždycky rád mýlím v odečtu SOC a SOC podhodnocuji, místo abych ho nadhodnocoval. Nehledám extrémní úrovně přesnosti, ale pokud SOC ukazuje XYZ, chci vědět, že je to ve skutečnosti alespoň XYZ. Takže obvykle nakonec naprogramuji Peukertovu konstantu 1,05 v mém (např.) Victronovém bočníku. I když skutečná konstanta při C frekvencích, na kterých systém provozuji, je pravděpodobně spíše kolem 1,02. Nejnovější software V19 odstraňuje časovač Float a nahrazuje ho algoritmem Re-Bulk založeným na SOC. Tato změna situaci ve skutečnosti zhoršuje, vezmeme-li v úvahu chyby měření SOC u JK-BMS. Firmware JK-BMS by měl být upraven, protože je to nejjednodušší a nejhospodárnější způsob, jak vylepšit výpočet stavu nabití (SOC) bez nutnosti nového hardwaru. Existují 2 hlavní metody pro odhad hodnoty SOC: 1) Coulometr monitoruje nabíjecí a vybíjecí proud a integruje jej v průběhu času. Existují však i určité nevýhody: - Přesnost měření proudu je omezena přesností ADC. ADC s rozlišením větším než 12 bitů jsou poměrně rozsáhlé a výrazně by zvýšily výrobní náklady. Měření proudu muselo být navíc kalibrováno individuálně, aby se využila plná kapacita 16-ti bitového ADC, což také zvyšuje výrobní náklady. - Vysoké vybíjecí proudy vyžadují velmi nízké hodnoty odporu bočníku, aby se zabránilo velkým ztrátám a zahřívání. To snižuje měřené napětí na bočníku, a proto se měření stává náchylným k rušení. - A co je nejdůležitější, v průběhu času se přidávají integrační chyby. I při velkém úsilí o ADC převod se hodnota SOC bude stále více a více odchylovat od správné hodnoty. 2) Měření napětí pomocí vyhledávací tabulky přepětí SOC. - Přesnost této metody je omezena kvůli ploché křivce nabíjení a vybíjení (napětí vs. kapacita). - Kvůli vyhledávací tabulce je tato metoda omezena na specifickou technologii baterie (lifepo). - Hodnoty SOC z této metody se však nemění, a proto se jedná o preferovaný postup odhadu SOC po dlouhou dobu bez resetování. 3) Proč však tyto metody nekombinovat: - Po resetování (3,6 V = 100 % SOC nebo 2,5 V = 0 % SOC) začít s coulometrovou metodou po dobu max. 5 dnů. Poté se drift stane znatelným. - Po 5 dnech vypočítat jednou denně korekční hodnotu SOC z vyhledávací tabulky měření napětí, aby se eliminoval drift SOC. 4) Odhad korekční hodnoty SOC (jednou denně): a) počkat 20 hodin od poslední korekce (vyhnout se zbytečným výpočtům) b) počkat, dokud proud neklesne pod 0,5 A (za přesně specifikovaných podmínek při měření napětí se tento stav pravděpodobně vyskytne dvakrát denně za soumraku a večer) c) spustit kontinuální měření napětí a uložit posledních 16 hodnot (pro lepší přesnost ADC) d) opakovat bod c), dokud proud opět nestoupne nad 0,5 A (aby napětí mělo maximální čas k dosažení konstantní hodnoty) e) odhadnout průměrnou hodnotu z posledních 16 hodnot napětí (pro lepší přesnost ADC) f) z vyhledávací tabulky získat hodnotu SOC (na základě křivky napětí vs. kapacity) z naměřené hodnoty napětí g) odhadnout korekční hodnotu SOC z rozdílu mezi SOC coulometru a SOC z vyhledávací tabulky. (asi 10 % rozdílu?) h) přičíst tuto korekční hodnotu k SOC coulometru a použít tuto hodnotu jako novou hodnotu SOC coulometru. i) díky denní korekci hodnoty SOC lze kompenzovat drift Coulometru. Pro tento výpočetní postup nejsou nutné žádné hardwarové úpravy, Měření proudu i napětí je již implementováno. Navrhované hodnoty pro korekci proudu a stavu nabití (SOC) by měly být před konečnou implementací ověřeny.

Ja az to dovoli pocasi termiku sundam a dam FVE protoze ted v zime to chybi kdyz sviti🤣

ne, vzdy vsechno zavrene

Dlouhé období tmy umožnilo ověřit, jak významně narůstá chyba, když SOC nechám počítat v HA integrací proudů do a z baterie, měřených modulem INA226 na bočníku 300A/75mV. SOC integrací prudu INA 226 v HA.png Rekalibrace na 100% naposled proběhla 13.11.2025, tedy před téměř 50 dny. Teď jsou dny krátké, tak se za těch pár hodin nepodaří baterie dobít, výpočet ukazuje SOC = 94% a i podle napětí na nich už moc nechybí. Je to podezřele dobrý výsledek. Na jednotlivých bateriích tři JK-BMS hodnotu SOC nadhodnocují (takže už včera se rekalibrovaly na 100% a i pak jimi tekly proudy do baterií) a jedna JK-BMS podhodnocuje (ta dosáhla 89%).

Nebo tady https://www.victronenergy.cz/mppt-calculator

Caute. Kto mi pomôže rozbehať komunikaciu s JK bms V11 4-8S s Cerbo GX Mk1 ? Nedarí sa mi to. Na mojej zostave by to malo fungovat. Prosím SZ. Už si začinam myslieť že problém je v meniči. Mám Phoenix 12/3000 2609 s posledným soft. Ktorý už má podporovať DVCC.

SONOFF ovlada 3 stupne vytezovani bojleru a akumulace;)

To jsem zvĕdavý a není od komunistů: https://www.techzpravy.cz/baterie-ktera-vam-usetri-miliony-nabije-se-za-9-minut-a-najedete-s-ni-1000-kilometru/#dop_ab_variant=0&dop_source_zone_name=hpfeed.sznhp.box

Nejprve musím sdělit že jsem byl znechucen příspěvky zde jako reakce a potom jsem litoval toho a byl bych rád, kdybych příště umělou inteligenci neposlechl a dal bych toto téma jako podtéma Energie jako taková. Protože toto téma přímo ovlivňuje energetickou bilanci a pohyb a různé formy energie v krajině. Dále jsem rád a díky za odkazy na zajímavé přednášky a povzbuzující reakce. V souvisloti s přednášlou okolo lesního vlivu a náhradního stroje imitující lesní porost jako řešení zadržování vody a ochlazování mne napadaly nápady že FVE je vlastně elegantní řešení pro pole, které se má ekonomicky využít a navíc ho dát do klidu jako půdu, kterou je možné vidět ve vícepolním hospodaření. Takže proč nezařadit na zemědělskou půdu s aktivně vodou zadržující FVE jako sezonní prvek? (sezona nemusí být jen jedno vegetační období u vícepol) Dále mne napadá, že část elektrické energie z FVE osazení na polích může být převedeno na podobnou statickou elektřinu kterou mají rostliny a kterou zadržují vlhko. Nesouhlasím s tím, že strom jen tak bezladu a skladu vypouští vodu do ovzduší. (snímek v parku) Každý pěstitel ví, že rostlina ty průduchy v případě sucha zavírá a zároveň přestane vypouštět kyslík a vodní páry v těch největších vedrech. Neudělal v přednášce Bohužel příkladný denní chronologický snímky luk, došel s termokamerou ve vedru okolo poledne a začal děla snímky. To co vidím já je přesně to co výše popisuje, že horká tráva je proto, že má podobnou funkci zadržovat a vydávat vodu a ochlazovat jako les, jenže ta vysoká teplota právě signalizuje uzavřené průduchy rostlin pro vodní páru a jeho nízkou akumulaci a nulový výdej vody. Kdyby snímky dělal v chronologii, tak by viděl i setrvačnost akumulace vypařování vody z luk, v která funguje stejně jako ten les ale jen po určitou dobu kdy je voda v oběhu od rozbřesku po soumrak. Pokud by to tak nebylo a nefungovalo a on viděl teplotu nízkou v pravé poledne jako měl les vedle, tak by viděl obrovskou energetickou hodnotu představující vodní výdej trávy která byla např. zavlažená závlahou. Pokud by to tak nefugovalo jak má a jak ukazuje, tak by tráva při vysoké teplotě plošně ihned u nás vyschla jak na poušti. Proto takové ochlazování neumí ani nízký les což zmiňuje také. Zápasí s nedostatkem vodní páry která je někde hodně vysoko tvoří skleníkový plyn. Vysoký les prostě oplývá větší akumulací vody. Šipky vypařující vody jsou špatně, kumulus mrak na lesem se tvoří podle několika podmínek, nestačí jen les, ale musí být jednak voda a jednak pohyb všemi směry, tz. i směrem k zakončení rostlin které po zavření a proschnutí umí vygenerovat měřitelnou statickou elektřinu vedle elektromagnetických vln. Je to prostě živá příroda která generuje pohyb energie a ten pohyb je výsledkem mnoha času a sociálního vývoje rostlin. Pokud by okolo hotelu v poušti prostě přikryli půdu s tou výsadbu se závlahou, případně přikryli FVE a agrotextilií, bilance výparu by se snížila natolik, že by ani nepotřebovali do dvou let aktivní závlahu. (vlastní zkušenost ze saharou co mám na jednom malém pozemku na JM ve svahu) To zakrývání půdy jsem zde kdysi popisoval ale opět nějaká reakce byla, že agrotextilie se rozpadnou, nejsou eko a blabla kecy. Což není pravda, Plasty typu agrotextilije byly v koloběhu kdysi také rostlinou, která se stala pod tíhou plynem nebo ropou, z které se přepracování materiálu člověkem znovu stal jak nazýváme plast. Hodně plastů jkteré známe se prostě vyrábí z plynu. Nerozpadly se u mne za 6 let. Protože nepoužívám herbicidy a etylén rozkládající jiné látky na svým pozemku. Přitom nani kondenzuje voda, dokáže zvýšit příjem vody do půdy, snižuje vysychání a v podstatě umí nahradit traktor, tz. obdělávání půdy do určité míry a navíc i prostředky a uhlíkovou stopu. A je relativně docela využívána na JM např. u zelinářů v bílé formě zadržující vodu pro přísadby. Světe div se kvůli vodní bilanci pro zakořenění košťálovin. Takže poslední myšlenka okolo FVE elektrárny a funkcí lesa je taková, že vidím řešení zadržování vody na pouštích formou kondenzace vodních par vysokými (jako les) kondenzátory vyrobené z několika komponent o tvaru vhodným pro kondenzaci vodních par, nebo by byly samotným FVE panelem s upraveným obrovským povrchem svádějící vodu pod panely do půdního systému. Prostě plocha půdy, na které je FVE by každé ráno dokázala svou statickou elektřinou a svou morfologií nejen zadržovat vodu pod sebou, ale také vytvářet mraky nad sebou. Dále by část energetického zisku mohl být investován do vyšší účinosti takového soustrojí udržující vodní páry u země a ne někde vysoko kvůli zmíněným gradientům teplot zapříčiňující ty tornáda záplavy atp. Protože účinnost je základním hnacím prvkem u energie jako takové. Jediná věc kterou toto téma by pro všeobecnou atraktivitu muselo mít jsou efektivně investované prostředky. A jejich zisk vedle zlepšení životního prostředí. Jenže z ekologie a krásna životního prostředí se stal nevídaný a často odporný byznys, nesmyslná politika a státní trafikanství. Což ukazuje na omezování právě těch potřebných peněz které by měly jít směrem k účinnosti. Což je i o zpětné vazbě a měřitelnosti takových účinků spotřebovaných peněz co dělají greendýlovci.

Dovolím si nesouhlasit. Diskutovalo se to celkem často. Navíc (podle mě) je to důležitější problematika než ty neustálé posty jestli nastavit napětí na 55.40V nebo 55.45V (nebo na kolik to vy nízkovolťáci nabíjíte). Takže já osobně jsem opravdu rád, že se toho kolega ujal. Zvlášť pokud má vybavení na přesné nastavení tlakové síly a na následné přesné změření i malých odchylek rozměru.

Fungovat to bude, ale verit muzes akorat te, ze ktere to budes cist. A jeste si over, jestli dane baterie najedou i bez komunikace.

Lokalitu ma napsanou Holubice u Brna a cenu na domluve, tj. aukce. Tak zacnete treba na stovce 😉

https://forum.mypower.cz/viewtopic.php?t=14707 Woltair 9 kW, Čína ako sa patrí. Stačilo by asi aj 6 kW.

je inzerát ještě aktuální?

Je to po 3/4 roce ještě aktuální?

Zdravím, pro těch 7 bych si byl schopen přijet, kdyby byly za 8000,- všechny

Trochu mě to děsí, sám mám Pylontech... :? . Ale co jsem kde četl, balancéry v HV baterkách jsou na velmi malé proudy a je potřeba balancovat třeba 20x na plné napětí, protože ten nejvyšší článek vyskočí, tím přes BMS zastaví dodávku proudu a pak po několika hodinách poklesne a dalo by se zase balancovat - ale v zimě k tomu nedojde, protože proudu je málo a tak je to horší a horší. Většinou se to lidem právě stane v zimě. Ale nemám žádnou pořádnou zpětnou vazbu, kdy a komu to opravdu pomohlo a kdy už ne.

Takhle ta čísla sedí dobře, se zapnutým zobrazením DC spotřeby (Modrásci) a plus-mínus sedi pak i ta vlastní spotřeba. Snímek obrazovky_26-12-2025_164013_vrm.victronenergy.com.jpeg Pokud by bylo takhle celou zimu, jako poslední dva dny, tak by to šlo.... Voda ohřátá, baterka na 92% a barák ohřátý dřevem :D protože nikdo nemusel do práce a celý den se přikládá... Snímek obrazovky_26-12-2025_163413_vrm.victronenergy.jpg Odhaduju že bude velmi mrazivá noc, uvidíme kam až to zajde (kdy se pustí záložní topení a ohřev z DS) - test jen FV takhle v zimě jsem ani nečekal :D

Taky všem přeju pěkné svátky a hodně zdraví a solárních úspěchů v roce 2026🙂

Takže aktualizaci přes HA budu používat jen výjimečně. Hromadně to budu dělat z PC (windows). Je to rychlejší a snáze si vytvářím zálohy předešlých firmware. Co je k tomu potřeba? 1. Nainstaluji si ESPHome na dané PC podle návodu na https://esphome.io/guides/installing_esphome/#windows (python + wheel + esphome). 2. Soubory *.yaml pro všechna ESP zařízení si stáhnu z HA do PC: esphome1.jpg 3. Soubory yaml (2) přesunu do složky, ve které mám nainstalováno .esphome (1): esphome2.jpg 4. Nezapomenu tam přemístit i stažený soubor secret.yaml (3) s hesly pro wifi, která bych jinak musel psát do každého yaml. 5. Teď už se to dá používat, ale já jsem si ještě v dané složce vytvořil bat soubor (ESPHome_update_all.bat), který spouštím a který provede aktualizaci jednotlivých ESP zařízení a vytvořená firmware přejmenuje názvem zařízení + přidá datum + zkopíruje do této složky pro zálohování těchto firmware (4). Začíná takto: Tím mám aktuální bin soubory na jednom místě a pokud by se něco nepovedlo, snáze pošlu do zlobivého espmodulu předchozí verzi firmware.

Konkrétně k Victron Mutiplus s připojeným AC IN a AC ignore + ATS: Změřil jsem L-fve/L-grid a potvrzuji, není to synchronní, napětí lítá, ale kdo to chce provozovat odděleně, řešení existuje s node red. V momentě kdy sepnou transfer relé (např dle SOC), externím relé 1 Cerba přes AUX, v ten moment VE.BUS zahlásí status GRID ENABLED. (Já to používám pro odepínání modráska na AC OUT.) To může Relém 2 přepnout ATS na AC OUT FVE/GRID. Přepíná sfázovanou = tutéž síť, bezpečné, čisté, rychlé...

Elektroerozivní obrábění vypadá opravdu jako budoucnost. https://www.youtube.com/watch?v=nqOpcFBhjW4

Připojuji se s přáním dvou vlasů Děda Vševěda. Hlavně ať Slunečník i Větrník značnou konečně pořádně makat. 😃👍

Dnes 2,3 kWh.

V prvom rade chcem vsetkym zazelat pokojne sviatky v kruhu svojich blizkych, vela zdravia, stastia a konecne aj slnka. Neska som aj ja opet prepol naspet na FV. Koncom tyzdna by sa malo ukazat to slnko a v predpovedi sa to nezmenilo uz par dni tak snad to vyjde. Baterka sa postupne dobila aj ked nie na sto percent ale uz to staci natolko, aby sme do toho *sun* vydrzali. Momentalne ma baterka realne nejakych cca 80% SoC aj ked ukazuje 90%. Je tu taka oblacnost, no po dlhej dobe je konecne vidiet nejaka vyraznejsia vyroba. IMG_9441.jpeg Nabita nebola veru velmi dlho.Zatial som ju externe s eltekom este nedobijal teraz... (Ten drift SoC je tam mozno aj okolo 15% )

me spise vadi, ze nejde nastavit libovona podminka pro ocisteni mopiku, 5m2 mi prijde strasne moc (a ocisteni po mistnosti mi prijde extrem). Ale jinak spokojenost, uz ma za sebou 66h a 4000 m2 xD ...

Pokud někdo něco nepochopil, tak velmi rád upřesním. V tomto případě ale stačí odkaz na již napsané. Dostupnost Abych to řekl rovnou: WHIP momentálně není na prodej a není open source. Tato série je o sdílení technických informací pro ty, které to zajímá. A hlavně znám své My-Pappenheim-powerské. Takže vím, že ten system nikdo nezkritizuje - pardon: podá zpětnou vazbu - tak dobře jako zde. ;-) Možná bych ale požádal, abyste mě tady nechali štěbetat a diskuzi o či dotazy k systému řešili v jiném vláknu? Nicméně - pokud máte v šuplíku STM32 Blue Pill nebo Nucleo a chtěli byste si firmware vyzkoušet, binárku a nějaké skripta vám můžu dát. A pokud plánujete stavět Vilu-C, D, E... možnost získat WHIP je na stole. V tuto chvíli to není ani OSS, ani komerční projekt (t.j. není cena). Je to "informační dárek" pro ty, které to zajímá. Doufal jsem, že symbolické zveřejnění 24.12. napomůže tuto intenci odhalit. Ale pokud někomu bude lépe, když to vezme, že jsem se chtěl "jen pochlubit", fajn. Koho to nezajímá, může to ignorovat asi stejně jako já "Arduino", "MyPower MicroLog", nebo "PLC Tecomat Foxtrot". Pokud si to přečte někdo, kdo si myslí, že šmrdlání s Arduinem není vrchol všeho, tak mu tyto články poskytnou třeba - já nevím - naději? Dále koukám, že mé žádosti nemohlo být vyhověno, ale tak s tím se muselo počítat. Krásné vánoce všem.

Schvalne aku diodu si tam chcel dat?

Lucifer: Nadřazená inteligence pro DALI V minulém díle jsem popsal SELV-DALI infrastrukturu - bezpečné nízkonapěťové osvětlení běžící přímo z bateriového úložiště. Teď se podíváme na to, co přidává Lucifer - hub pro "vyšší inteligenci" osvětlení. Co funguje bez Lucifera DALI je decentralizovaný protokol. Spínač může přímo ovládat svítidlo - žádný hub, žádný server, žádná síť. Stisknu tlačítko, rozsvítí se světlo. Takhle jednoduché. Základní scénáře bez hubu: Spínač A zapne/vypne/stmívá světlo B PIR senzor rozsvítí světlo na chodbě Skupiny světel reagují na jeden spínač Uložené scény se aktivují tlačítkem Tohle vše je naprogramované přímo v DALI zařízeních. Když Lucifer spadne, když spadne síť, když spadne server - základní ovládání funguje dál. To je ten princip "vyšší vrstvy jsou doplněk, ne podmínka". Co přidává Lucifer Takže proč ho mám? Protože základní DALI konfigurace je... základní. Pro cokoliv složitějšího potřebuju něco víc. 1. Pohodlná konfigurace DALI zařízení se konfigurují přes DALI příkazy přímo na zařízeních. Chci změnit, který spínač ovládá které světlo? Musím k tomu spínači - vyndat ho ze zdi nebo z podhledu - a tam ho překonfigurovat. Titěrná práce s hex kódy a DALI specifikací. S Luciferem to řeším přes webové rozhraní. Z gauče. S Luciferem: Změna konfigurace = editace YAML, reload. Žádné hex kódy, žádné ruční počítání adres. 2. Simulace přítomnosti Když odjíždím na dovolenou, nechci aby dům vypadal prázdně. Lucifer si pamatuje typické vzorce používání světel - kdy se rozsvěcí obývák, kdy koupelna, kdy ložnice. A pak je přehrává s náhodnou variací. Zloděj vidí normálně vypadající aktivitu. Já mám klid. 3. Režimy domu Různé situace vyžadují různé chování světel: Normální režim: Spínač v obýváku ovládá stropní světlo. Party režim: Stejný spínač přepíná mezi barevnými scénami. PIR senzory ignorovány (nechci aby se světla měnila když někdo projde). Noční režim: PIR na chodbě rozsvítí tlumené světlo (10%), ne plný jas. Bezpečnostní režim: Při alarmu blikají všechna světla. Případně se rozsvítí exteriér na maximum. Změna režimu = jeden příkaz z aplikace nebo automaticky podle času/stavu. 4. Logování Kolik hodin denně svítí které světlo? Kdy se typicky rozsvěcí koupelna? Lucifer všechno loguje do InfluxDB. K čemu to je: Optimalizace spotřeby - které světlo svítí zbytečně dlouho? Detekce anomálií - světlo v garáži svítí ve 3 ráno? Podezřelé. Plánování údržby - LED po 50000 hodinách degraduje, vím kdy měnit Podklady pro simulaci přítomnosti - reálná data místo odhadů 5. Automatické zhasínání Zapomenuté světlo v prádelně? Po 2 hodinách se samo vypne. Světlo na WC? Po 30 minutách. Obývák? Nikdy automaticky - tam chci mít kontrolu. 6. Vzdálené ovládání Ležím v posteli a uvědomím si že svítí v kuchyni. Bez Lucifera musím vstát. S ním otevřu aplikaci a zhasnu. Nebo řeknu Bragimu (audio hub) a ten pošle příkaz Luciferovi. REST API: 7. DALI-DALI gateway Mám 4 DALI sběrnice (suterén, přízemí, patro, exteriér). Bez Lucifera jsou izolované - spínač na jedné sběrnici nemůže ovládat světlo na jiné. S Luciferem můžu: Hlavní vypínač u vchodu zhasne celý dům (všechny 4 sběrnice) Scéna "dobrou noc" vypne přízemí a patro, nechá noční světlo v chodbě suterénu Pohyb na PIR v exteriéru rozsvítí světlo v předsíni (jiná sběrnice) Hardware: ATX LED AL-DALI-HAT-I4 Lucifer používá DALI HAT od ATX LED: 4 opto-izolované DALI sběrnice Real-time koprocesor - zpracovává DALI timing (1200 baud Manchester) Sériová komunikace s RasPi na 19200 baud (16× rychlejší než DALI) Monitoring všech DALI zpráv na všech sběrnicích Vyžaduje externí DALI napájecí zdroj (16V, ~260mA na sběrnici) Koprocesor je klíčový - DALI timing je kritický a Linux není real-time OS. HAT tohle řeší hardwarově. Architektura Shrnutí: Co je "nadřazená inteligence" Bez Lucifera: Světla fungují. Spínače ovládají světla. Základní automatizace běží. S Luciferem: Pohodlná konfigurace, simulace přítomnosti, režimy, logování, automatické zhasínání, vzdálené ovládání, cross-bus koordinace. Lucifer není nutný. Ale dělá život pohodlnější. A když spadne - nic kritického se nestane. Prostě se vrátím k základnímu ovládání. To je ten princip celého WHIP: každá vrstva přidává hodnotu, ale žádná není single point of failure.

Vsuvka: SELV-DALI - světlo bez sítě V předchozím díle jsem představil Lucifera - hub pro řízení osvětlení přes DALI. Ale abych vysvětlil, kde Lucifer sedí a proč, musím nejdřív popsat infrastrukturu pod ním. Protože DALI v mém domě není obyčejný DALI. Co je SELV SELV = Safety Extra Low Voltage. Napětí pod 60 V DC, které je bezpečné i při přímém dotyku. Žádný zásah elektrickým proudem, ani když se dotknete holého vodiče. Žádné nebezpečí, ani když kabel poškodíte. To má praktické důsledky: Vypínač přímo vedle umyvadla? Žádný problém. Svítidlo ve sprše bez speciálního krytí? Ano. Instalace bez elektrikáře? Legálně ano (v rámci SELV). Děti, domácí mazlíčci, vlhkost - bez rizika. DALI není SELV Tady je háček. DALI sběrnice sama běží na 16 V - to je bezpečné. Ale standardní DALI instalace používá LED drivery napájené 230 V AC. Uvnitř driveru je transformátor, ale stačí jediná porucha izolace a na "bezpečné" DALI sběrnici máte síťové napětí. Proto je DALI oficiálně klasifikováno jako FELV (Functional Extra Low Voltage), nikoli SELV. Funkčně nízké napětí - ale ne bezpečnostně. Skutečný SELV-DALI Řešení: galvanická izolace. Žádných 230 V AC nikde v osvětlovacím řetězci. Celý systém běží na DC z bateriového úložiště. Výsledek: celý osvětlovací systém je SELV. Od baterie přes měniče až po poslední LED. Maximální napětí v systému je 48 V (baterie), typicky 24 V (svítidla) a 16 V (DALI). Vše pod hranicí 60 V. Proč 24 V? Baterie jsou 48 V (16S LiFePO4). Proč nepřejít rovnou na 48 V svítidla? Dostupnost - 24 V LED pásky, moduly, drivery jsou všude. 48 V je vzácné. Proudy - při 24 V teče poloviční proud než při 12 V. Tenčí kabely, menší ztráty. Standard - 24 V je průmyslový standard pro nízkonapěťové systémy. Bezpečnost - stále hluboko pod 60 V SELV hranicí. DC/DC měnič 48 V → 24 V je jednoduchý a efektivní (95%+ účinnost). Co to znamená v praxi Výpadek AC infrastruktury: Při běžném výpadku sítě (ne že by Villa-A byla připojena k síti) drží Victron systém (Multiplus-II + MultiRS záloha) AC napájení z baterií. Ale co když selžou i střídače? SELV-DALI běží přímo z DC bateriového úložiště - obchází celou AC vrstvu. Dokud jsou baterie nabité, svítím. Žádný přechod, žádné bliknutí - systém už je "mimo AC" od začátku. Bezpečnost: V koupelně mám vypínače kde chci, ne kde mi dovolí norma pro 230 V zóny. Svítidla bez IP67 krytí v mokrých prostorech. Flexibilita: Přidat svítidlo = připojit 24 V a DALI. Žádné tahání silových kabelů, žádné revize. Kde sedí Lucifer DALI sběrnice funguje decentralizovaně - spínače a drivery spolu komunikují přímo. Můžu rozsvítit světlo tlačítkem bez jakéhokoliv hubu. To je základní vrstva, která funguje vždy. Lucifer přidává vyšší inteligenci: ETH/CAN ↔ DALI gateway - ovládání z IP sítě, z nodů, z aplikace DALI ↔ DALI gateway - koordinace mezi 4 sběrnicemi (suterén, přízemí, patro, exteriér) Scény - přednastavené kombinace světel Časové programy - automatické rozsvěcení/zhasínání Simulace přítomnosti - když jsem pryč, dům vypadá obydleně Když Lucifer vypadne, základní ovládání funguje dál. Ztratím jen "chytré" funkce - ale to je přijatelná degradace. Komponenty DALI zdroj: Generuje 16 V pro DALI sběrnici z 24 V DC. Napájí spínače, senzory, a DALI část driverů. LED drivery: 24 V DC vstup, konstantní proud nebo napětí na výstupu pro LED. DALI rozhraní pro stmívání a adresaci. Používám mix DT6 (single channel) a DT8 (tunable white/RGBW). Spínače: DALI tlačítkové moduly. Napájené z DALI sběrnice, posílají příkazy přímo driverům nebo přes Lucifera pro složitější scény. Svítidla: Běžné 24 V LED pásky, moduly, panely. Nic speciálního - díky SELV můžu použít cokoliv. Má to smysl? SELV-DALI má smysl pouze pokud už máte bateriové úložiště. Bez baterií byste potřebovali AC/DC zdroj na 230 V - a celá pointa SELV je pryč. Pro dům s FVE a úložištěm (což je můj případ) jsou DC/DC měnič a DALI zdroj přehledné dodatečné náklady oproti klasické instalaci. A získám: Maximální bezpečnost Nezávislost na síti Flexibilitu bez elektrikáře Čistou integraci s WHIP Zpět k hubům Teď když víte, jak vypadá osvětlovací infrastruktura, dává Lucifer větší smysl. Není to master systému - je to rozšíření, které přidává inteligenci nad decentralizovanou DALI vrstvu. Stejný princip platí pro všechny WHIP huby: nejsou nutné pro základní funkci, ale přidávají hodnotu tam, kde ji potřebuju.

WHIP Hub: Raspberry Pi jako páteř chytré domácnosti V minulých dílech jsem popsal nody - STM32 s FreeRTOS, moduly, CAN bus, Ganglion. Nody zvládají lokální automatizaci, ale pro agregaci dat, vizualizaci a napojení na vnější svět potřebuji něco víc. To je Hub. Co je Hub Hub je Raspberry Pi s rozšiřujícími HAT moduly. Funguje jako: Gateway mezi CAN sběrnicí a IP sítí Agregátor dat ze všech nodů Most k externím zařízením (Modbus, DALI) API middleware pro server a frontendové aplikace Klíčový princip: hub není nutný pro základní funkce. Nody běží autonomně díky Ganglionu. Hub přidává vizualizaci (Grafana), historii (InfluxDB), integraci s externími systémy a vzdálený přístup. Jeden hub na všechno? Ne. Původně jsem uvažoval o jednom univerzálním hubu - CAN, DALI, Modbus, vše na jednom RasPi. Rychle jsem zjistil, že to není dobrý nápad: Různé domény mají různé požadavky na dostupnost Debugging je noční můra když všechno běží na jednom stroji Selhání jednoho subsystému nesmí shodit ostatní Různé protokoly mají různé HAT moduly - a stackování HATů má limity Řešení: specializované huby. Každý hub má jednu primární odpovědnost. A aby bylo jasné, kdo co dělá, mají jména z mytologie - ne náhodně, ale podle funkce. Pantheon hubů Raijin (雷神) - japonský bůh hromu a blesku. Tento hub má na starosti energetiku: monitoring BMS (ECS LiPro), integraci s Victron GX, sledování toků energie. Když potřebuju vědět, kolik mám v baterkách nebo co dělá střídač - ptám se Raijina. Lucifer - latinské "nositel světla". Kdo jiný by měl řídit osvětlení? Celý dům je na DALI - od technické místnosti po obývák. Důležité: DALI je decentralizovaný protokol, podobně jako CAN. Spínače a LED drivery spolu komunikují i bez nadřazeného systému. Když Lucifer vypadne, světla nezhasnou - jen ztratím "vyšší inteligenci": simulaci přítomnosti, scény přes API, gateway do IP sítě. A proč vlastně DALI a ne CAN pro osvětlení? Pamatujete na "NIH" z prvního dílu? DALI existuje, je ověřený, má široký ekosystém produktů. CAN-based svítidla pro rezidence prakticky neexistují - a DIY řešení by zabralo další roky vývoje. Pragmatismus nad purismem. Lucifer obsluhuje 4 nezávislé DALI sběrnice - funguje tedy i jako DALI-DALI gateway mezi zónami, nejen jako ETH/CAN-DALI bridge. Bragi - severský bůh poezie a hudby. Multiroom audio, rozpoznávání hlasu, AI asistence. RasPi 5 s HiFiBerry ADC+DAC pro kvalitní zvuk. Gaia - řecká bohyně Země. Skleník, zahrada, jezírko. Vše co roste a žije venku. Senzory vlhkosti půdy, teploty, zavlažování, filtrace. A pak je tu Tyr - severský bůh války a spravedlnosti. Co má na starosti? To si domyslíte. ;-) Hardware Základem je Raspberry Pi 4 nebo 5. K tomu HAT moduly podle potřeby: Waveshare 2-CH CAN HAT: 2 izolované CAN kanály MCP2515 kontroler přes SPI Integrované 120 Ω zakončení (jumper) Každý kanál = až 30 nodů na 20 m ATX LED DALI HAT: 4 nezávislé DALI sběrnice Každá sběrnice = až 64 DALI zařízení DALI-DALI gateway mezi sběrnicemi Waveshare Relay HAT: Přímé relé výstupy z hubu Pro lokální aktuátory bez CAN nodu Škálování Více hubů pod jedním serverem: Dům 20 × 10 × 10 m (3 podlaží: suterén, přízemí, patro) s desítkami nodů a desítkami DALI svítidel. Každý hub má svoji doménu, žádný není single point of failure pro celý systém. Komunikační protokoly Hub mluví několika jazyky: CAN: Primární spojení s nody. 1 Mbit/s, 29-bit extended ID. Hub je jen další účastník na sběrnici, není master. Modbus: Pro integraci externích zařízení - BMS baterií, měniče, tepelná čerpadla. Plná implementace: TCP i RTU (RS485) 17 z 21 function codes (81%) 869 testů, 91% pokrytí kódu Produkčně ověřeno na ECS LiPro BMS DALI: Pro osvětlení. Digitální protokol, 64 adres na sběrnici, 16-bit příkazy. Přímo řízeno z hubu bez CAN nodů. MQTT: Pro IoT integraci. Publish/subscribe model, JSON payloady. SNMP: Pro monitoring síťové infrastruktury (UPS, switche). Software architektura Hub běží na Mojolicious - Perl web framework. Proč Perl? Mojolicious je async/non-blocking - ideální pro I/O-bound úlohy Skvělá práce s textem a protokoly Moje hlavní doména (viz první díl) Dlouhodobě udržitelné - žádné zásadní změny každý rok Vrstvy: Protocol Layer: Daemon Layer: Controller Layer (REST API): Raijin v akci: ECS BMS monitoring Praktický příklad - Raijin monitoruje dva stacky LiFePO4 baterií s ECS LiPro Active V2 BMS přes Modbus RTU: Výsledek na Grafana dashboardu: Raijin v akci: Victron integrace Victron CerboGX komunikuje přes Modbus TCP. Raijin se připojuje a čte: Stav střídačů (Multiplus-II) - VE.Bus unit 227 SmartShunt data (SOC, napětí, proud) - unit 223 PV inverter (Fronius Symo) - unit 20 Druhý kanál: VRM API pro dlouhodobou historii a vzdálený monitoring. Data pipeline Každý hub má lokální InfluxDB + Grafana. Server agreguje z více hubů. Typické metriky: Teploty, vlhkosti, tlaky (BME280, SHT4x) Proudy a napětí (INA226, ACS758) Průtoky (pp-flow) Stav relé, žaluzií Spotřeba, výroba, SOC baterií Proč tato architektura Decentralizace - žádný hub není single point of failure. Nody běží i bez hubů, každý hub běží nezávisle na ostatních. Specializace - každý hub dělá jednu věc dobře. Raijin = energie, Lucifer = světlo, Bragi = zvuk. Srozumitelnost - když něco nefunguje, vím kam se podívat. Problém se světlem? Lucifer. Problém s BMS? Raijin. Škálovatelnost - nová doména = nový hub. Žádné přetěžování existujících. Co dál? Tím jsou pokryté nody i huby. V příštím díle půjde o server - top-level orchestrace, agregace dat z více hubů, a frontendové aplikace.

CAN bus a Ganglion: Jak spolu nody mluví V předchozích dílech jsem představil architekturu nodů a ukázal několik modulů. Nody ale neexistují izolovaně - jsou propojené sběrnicí CAN. Dnes se podíváme na to, jak funguje komunikace a co je Ganglion. CAN bus v kostce Controller Area Network vznikl v 80. letech pro automotive. Dnes je všude - od aut přes průmyslovou automatizaci až po smart home. Proč? Fyzická vrstva: Dva vodiče: CAN_H a CAN_L, diferenciální signál Dva stavy: dominantní (logická 0) a recesivní (logická 1) Když dva nody vysílají současně, dominantní stav přebije recesivní (wired-AND) Zakončení 120 Ω na obou koncích sběrnice Rychlost vs. délka: WHIP používá 1 Mbit/s. V rozvaděčích není problém, celková délka je typicky do 20 m. Arbitrace (CSMA/CR): Tohle je klíčové. Když dva nody začnou vysílat současně: Oba vysílají své ID bit po bitu, od nejvýznamnějšího Monitorují sběrnici Node, který vyslal recesivní bit ale čte dominantní, prohrál - přestane vysílat a stane se příjemcem Vítěz pokračuje, zpráva není poškozená Nižší ID = vyšší priorita. Žádné kolize, žádné ztráty, deterministické chování. Formát zprávy (29-bit extended): WHIP používá rozšířený formát s 29-bitovým identifikátorem: Maximálně 8 bajtů dat na zprávu. Při 1 Mbit/s je nejhorší případ ~160 µs na zprávu, typicky ~130 µs. Teoreticky ~7600 zpráv/s, prakticky počítám s max. 70% využitím. Možná kromě hromadné palby při firmware upgrade. Detekce chyb: 15-bitové CRC Bit stuffing (po 5 stejných bitech se vloží opačný) Acknowledgement od příjemců Chybové čítače (TEC/REC) - vadný node se postupně odpojí Tohle vše řeší hardware. STM32 má integrovaný bxCAN kontroler - já jen posílám zprávy a přijímám je, o zbytek se stará čip. CAN handlery v modulech Každý modul má funkci handleCAN. Dispatcher v jádře firmware přijme zprávu, dekóduje modul a subpříkaz z CAN ID, a zavolá příslušný handler. Příklad z buzzer modulu: Podobně switch-core: Vzor je stejný: subcmd (4 bity) určuje operaci data obsahují parametry Handler provede akci a/nebo vrátí odpověď Z hubu nebo z nástroje Wcancmd na PC pošlu zprávu, node ji zpracuje. Ale co když chci automatizaci přímo na nodu, bez hubu? Ganglion: Lokální inteligence GANGLION = "GANG of Lightweight Input/Output Nodes" Název je z biologie. Hmyz nemá centrální mozek, ale ganglia - shluky neuronů distribuované v těle. I s minimální složitostí jsou vysoce funkční. Stejná filozofie: i když vypadne hub, server, internet - nody by měly zvládat základní automatizaci samy. Co Ganglion umí: IF-THEN pravidla vyhodnocovaná periodicky Časovače (countdown v sekundách) Lokální proměnné (bajty, wordy, integery) Komunikace s ostatními nody přes CAN Klíčový princip: Znovupoužití CAN handlerů Ganglion NEVYTVÁŘÍ paralelní cestu. Používá stejné handlery jako CAN zprávy: Pro "tento node" Ganglion sestaví data a zavolá handler přímo. Pro "jiný node" sestaví CAN zprávu a pošle ji na sběrnici. Výsledek je stejný - handler nepozná rozdíl. Syntaxe Adresy: IF-THEN pravidla: Definice konstant: Časovače: Logické operátory: Příklady Termostat s hysterezí: Světlo s časovačem: Koordinace mezi nody: Stavový automat: Kompilace a nasazení Ganglion skripty (.tgc) se kompilují do bajtkódu (.bgc): Bajtkód je typicky 10-50 bajtů. Nahraje se do flash paměti nodu a interpret ho periodicky vyhodnocuje (každých 500 ms). Proč to funguje Jednoduchost - pravidla jsou IF-THEN, nic složitějšího Lokální prediktabilita - pro operace na tomto nodu je chování předvídatelné. Jakmile se zapojí vzdálené nody, záleží na jejich stavu a dostupnosti - to už tak jednoduché není. Robustnost - když vypadne hub, lokální pravidla běží dál Znovupoužití - Ganglion volá stejné handlery jako CAN zprávy Nody tak nejsou jen "hloupé" I/O - mají základní inteligenci. Na jedné CAN sběrnici spolu nody komunikují přímo. A když hub běží, může Ganglion koordinovat i mezi CAN sběrnicemi. Co dál? To je asi tak vše, co mě napadá k node vrstvě. V příštím díle půjde o úroveň výš - Hub: Raspberry Pi jako agregátor, gateway, a middleware mezi CAN a IP světem.

WHIP Nodes: Sedm vybraných modulů v detailu V minulém díle jsem představil modulární architekturu nodů - přes 115 modulů, kombinatoriku závislostí, a jak to celé drží pohromadě. Nyní se podíváme na sedm konkrétních modulů podrobněji. 1. bootloader - firmware přes CAN Asi nejdůležitější "neviditelný" modul. Node visí v rozvaděči za uzavřenými dveřmi, a já nechci pokaždé tahat programátor. Řešení: vlastní bootloader v prvních 8 KB flash paměti. Aplikace začíná na adrese 0x08002000. Když potřebuju aktualizovat firmware: Pošlu CAN příkaz "enterBootloader" Firmware odpoví potvrzením, nastaví příznak v záložních registrech a provede reset Po resetu bootloader najde příznak a zůstane aktivní (jinak ihned předá řízení firmware) Nahraju nový firmware přes WBTP-XL protokol (Witty Bootloader Transfer Protocol - XL) Bootloader předá řízení nové aplikaci Celý proces trvá asi 30 sekund pro 120 KB firmware. Bez fyzického přístupu, bez otevírání rozvaděče. Bootloader také uchovává počítadlo bootů a verzi aplikace v záložních registrech STM32. Když se nová verze nespustí, můžu to zjistit vzdáleně. 2. switch-core - jednotné řízení výstupů Tohle je nástupce původního relay_base, relay_blinds a mosfet_duty. Místo tří oddělených modulů jeden s konfigurovatelnou rolí pro každý kanál. Podporované role: simple - prosté relé zapnuto/vypnuto (hodnota 0 nebo 1) duty - PWM/časově-proporcionální řízení (0-100%), Bresenhamův algoritmus pro rovnoměrné rozložení blind - dvojité relé pro žaluzie (0=stop, 1=nahoru, 2=dolů), s ochrannou prodlevou při změně směru water - dvojité relé pro vodní ventil (0=zavřít, 1=otevřít), s bezpečnostním timeoutem air - dvojité relé pro vzduchovou klapku (0=zavřeno, 1=přívod, 2=odvod) Příklad konfigurace v YAML: Pro role blind a water je implementovaná ochrana: před změnou směru se oba výstupy nejdřív vypnou a počká se reversal_delay_ms (typicky 500 ms). U vodních ventilů je povinný bezpečnostní časový limit - když nepřijde příkaz k zavření, ventil se zavře sám. Modul vyžaduje PCF8574 nebo PCF8575 I/O expandér - ten resolver automaticky zkontroluje při buildu. 3. bme280 - prostředí plus rosný bod Bosch BME280 je oblíbený senzor pro teplotu, vlhkost a atmosférický tlak. Na tom není nic zvláštního. Zajímavé je, co se děje s daty přímo na nodu. Rosný bod - teplota, při které vzduch kondenzuje - se počítá Magnusovou formulí: Kde T je teplota ve °C a RH relativní vlhkost v procentech. Implementace používá celočíselnou aritmetiku (fixed-point) - na MCU bez FPU je to rychlejší a determinističtější. K čemu je to dobré? Mám kapilární stropní topení/chlazení. Když v létě chladím a teplota stropu klesne pod rosný bod vzduchu v místnosti, začne kondenzovat - a já nechci krápníkovou jeskyni. Node musí být schopen lokálně zajistit, že teplota chladicí vody nikdy neklesne pod rosný bod. Bez čekání na hub, bez latence, deterministicky. Modul podporuje až 2 BME280 na jedné I2C sběrnici (adresy 0x76 a 0x77). Kompenzuje také tlak podle nadmořské výšky nodu (konfigurovatelné). 4. buzzer - melodie na piezu Signalizace přes bzučák. Ne jen "píp" - ale skutečné melodie. Hodí se pro: Potvrzení příkazu (krátká melodie) Alarm (opakující se motiv) Identifikace nodu ("Zahraj Imperial March" - a vím, který node hledám) Vestavěné melodie: In the Hall of Mountain King (Grieg) Happy Birthday Close Encounters of the Third Kind Imperial March (Star Wars) Westminster Chimes Přehrávání je plně konfigurovatelné přes CAN: loudness (0-255) - hlasitost speedup (1-15) - rychlost přehrávání transpose (-127 až +128) - transpozice v půltónech start, end - přehrát jen část melodie repeat - jednorázově nebo ve smyčce Zvuk generuje TIM3 v PWM režimu. Frekvenční tabulka pokrývá rozsah A2 až A7 (110 Hz až 3520 Hz) - 61 tónů. Časování je odvozeno ze 72 MHz systémových hodin: prescaler 9 dává 7,2 MHz, TIM_ARR pak určuje frekvenci tónu. Modul může sdílet TIM3 s heartbeat modulem - heartbeat pak má prioritu (signalizace stavu je důležitější než melodie). 5. heartbeat - tep nodu Základní diagnostika: node žije, nebo ne? Heartbeat to signalizuje třemi nezávislými kanály: Vizuální (LED): Morseovka - konfigurovatelný řetězec (max 8 znaků). Výchozí je "OK". Při chybě můžu nastavit třeba "E1" nebo "FAULT". Jednoduché blikání - 200 ms zapnuto, 800 ms vypnuto, opakování. Audio (bzučák): Krátký pípnutí jednou za sekundu (100 ms @ 2,5 kHz). Užitečné, když hledám fyzický node v rozvaděči plném desek. CAN broadcast: Každou sekundu posílá zprávu s 32-bitovým počítadlem beatů. Hub tak vidí, které nody jsou aktivní, a jak dlouho běží od posledního restartu. Morseovka(! :-)) je kompletně implementovaná na nodu - tabulka 43 znaků (0-9, A-Z) s kompaktním kódováním: 5 bitů pro dits/dahs, 3 bity pro délku. Časování: dit = 100 ms, dah = 300 ms, mezera mezi znaky = 300 ms, mezera po slově = 700 ms. 6. pp-flow - pulsní průtokoměry Měření průtoku vody pro topení, TČ, solár. Levné Hall-effect průtokoměry generují pulsy - typicky 5-10 pulsů na litr. Modul je počítá a přepočítává na l/min. Architektura: Až 16 kanálů (PCF8575) nebo 2×8 kanálů (2× PCF8574) Vzorkování každé 2 ms pro přesnou detekci pulsů 60-sekundový klouzavý průměr pro vyhlazení Volitelně CD74HC4067 multiplexor pro rozšíření Závislosti: Modul potřebuje I/O expandér a ADC jádro. Multiplexor je doporučený, ale volitelný - resolver to správně interpretuje. Typické použití: monitoring okruhů tepelného čerpadla. Jeden node měří průtok solanky, teplé vody, topné vody - a lokálně počítá průměry. Hub dostává už zpracovaná data. 7. ws281x - adresovatelné LED WS2812B, SK6812, WS2814A - všechny ty barevné LED pásky. Modul podporuje: Až 512 LED na pásek RGB i RGBW varianty GRB a RGB pořadí barev 16 uložených scén Vestavěné efekty (rainbow, fade, ...) Příkazy přes CAN: setBrightness - globální jas (0-255) setColorAll - všechny LED stejná barva setColorRange - rozsah LED setColorSingle - jednotlivá LED setEffect - animovaný efekt loadScene/saveScene - práce se scénami Generování signálu využívá DMA + Timer PWM. WS281x protokol vyžaduje přesné časování (800 kHz, 1,25 µs na bit) - s DMA to běží na pozadí bez zatížení CPU. Pro větší instalace (více pásků, více LED) používám RasPi Pico jako inteligentní periferii. Pico má PIO (Programmable I/O) - hardwarové stavové automaty, které generují WS281x signál perfektně. Jeden Pico zvládne 4 nezávislé pásky, a komunikuje s nodem přes SPI nebo I2C. Node pak jen posílá příkazy, Pico řeší timing. Společné vzory Když se na ty moduly podíváte jako celek, je vidět několik opakujících se vzorů: 1. Lokální inteligence BME280 počítá rosný bod. PP-flow počítá průměry. Switch-core hlídá bezpečnostní timeouty. Data se zpracovávají tam, kde vznikají. 2. Odolnost vůči selhání (graceful degradation - systém při selhání části nezkolabuje, jen omezí funkcionalitu) Heartbeat funguje i bez hubu. Switch-core dokončí pohyb žaluzie i když vypadne komunikace. Bootloader může obnovit firmware i po špatném update. 3. Hierarchická konfigurace cfg.yaml definuje rozhraní modulu. Node YAML konfiguruje konkrétní použití. Generátor vytváří C kód. Žádné ruční úpravy v kompilovaném kódu. 4. CAN jako univerzální rozhraní Každý modul má handleCAN. Stejný protokol pro čtení, zápis, konfiguraci. Hub neví (a nepotřebuje vědět), jak modul interně funguje - jen posílá příkazy a přijímá odpovědi. Co dál? Zatím jsem se díval na nody izolovaně. V příštím díle: jak spolu mluví - CAN bus v praxi, Ganglion protokol, a jak funguje distribuovaný systém bez centrálního řízení.

WHIP Nodes: Mikrokontroléry v chytré domácnosti V prvním díle jsem představil WHIP jako celek. Nyní se podíváme na nejnižší vrstvu - nodes. Ty malé STM32 desky, co sedí v rozvaděčích a starají se o skutečnou práci. Hardware: Proč STM32? Na Arduino jsem se díval v rámci MySensors evaluace. Výsledek: za stejnou cenu dostanu 10x výkonnější STM32 + FreeRTOS místo "while(1) loop + mišmaš". RasPi Pico mám taky - ten WHIP umí integrovat jako celkem inteligentní a výkonnou periferii, ale ne jako hlavní node. Plus potřebuju: Integrovaný CAN kontroler (ne externí modul) Deterministické real-time chování Průmyslovou kvalitu a dlouhodobou dostupnost Rozumnou cenu při větších objemech STM32 tohle všechno splňuje. Konkrétně používám dvě rodiny: STM32F103 (Cortex-M3, 72 MHz) 128 KB flash, 20 KB RAM Obě rodiny mají nativní bxCAN kontroler - žádný externí MCP2515, žádné SPI bottlenecky STM32F303 (Cortex-M4F, 72 MHz) FPU pro floating-point operace Lepší ADC (dual simultaneous sampling) Používám ho tam, kde potřebuju víc výkonu nebo přesnější měření Podporované desky: Nucleo-F103RB - reference pro F103 Blue Pill - levné, ale pozor na kvalitu RobotDyn Black Pill - kvalitnější varianta Blue Pill Green Pill - vlastní PCB od PetaJoule, přesně pro WHIP potřeby STM32F3Discovery - reference pro F303 Nucleo-F303K8 - kompaktní F303 varianta Tenhle výčet ukazuje genericitu - firmware běží na různých deskách od různých výrobců, stačí změnit konfiguraci. Software: FreeRTOS + libopencm3 Mohl jsem psát bare-metal, ale proč? FreeRTOS mi dává: Přepínání úloh - každý modul běží ve vlastní úloze Timery a synchronizaci Soft real-time garantie (milisekundová přesnost stačí) Pro HAL používám libopencm3 místo STM32Cube. Důvody: Transparentní - vidím, co se generuje Žádná vendor lock-in magie Open source, dlouhodobě udržitelné Funguje napříč STM32 rodinami STM32Cube je fajn pro prototypování, ale nechci být závislý na ST code generatoru pro systém, co má běžet 50 let. Modulární architektura Tady to začíná být zajímavé. Firmware není monolitický blob - je složený z modulů. Momentálně jich mám přes 115: Kategorie: Senzory: teplota/vlhkost (BME280, SHT4x, DHT), světlo (BH1750, TSL256x), proud/napětí (INA2xx), vzdálenost (VL53Lxx, HCSR04)... Expandéry: PCF8574, PCF8575, MCP230xx, PCA9548 (I2C mux) Displeje: SSD1306, SH110x, ST7789, HD44780, TM1637, MAX72xx Aktory: switch-core, buzzer, ws281x, steppery (A4988, DRV8825) Paměti: AT24Cxx (EEPROM), MB85RCxx (FRAM), W25Qxx (SPI flash) 1-Wire: DS18x20, DS2401, DS2408, DS2413, DS2431, DS2438, DS2450 Komunikace: ganglion (CAN), NRF24L01, SX1276 (LoRa) Každý modul má: cfg.yaml - metadata, závislosti, CAN příkazy src/*.c, *.h - implementace doc/README.md - dokumentace Kombinatorika: Závislosti a konfigurace Tady to začíná být zajímavé. 115 modulů. Teoreticky 2^115 možných kombinací - číslo s 35 číslicemi. Samozřejmě ne každá kombinace má smysl a ne každá se vejde do paměti. Ale prakticky? Na F103 se vejde tak 10 modulů, na F303 třeba 20. To je pořád C(115,10) respektive C(115,20) - miliardy až biliony reálných konfigurací. Jeden node může mít BME280 (teplota/vlhkost/tlak) + INA226 (proud/napětí) + PCF8574 (8 relé) + SSD1306 (displej) + buzzer. Jiný jen DS18B20 a switch_core pro žaluzie. Každá kombinace je jiný firmware, automaticky sestavený ze stejných stavebních bloků. K tomu závislosti mezi moduly. Každý modul v cfg.yaml deklaruje: Resolver funguje jako strážce. Když povolím switch_core: Podívá se na requires - potřebuje (pcf8574 | pcf8575) Zkontroluje, že uživatel povolil alespoň jeden z nich Pokud ne → chyba, build selže s jasnou hláškou Rekurzivně zkontroluje závislosti všech povolených modulů Topologicky seřadí inicializační pořadí Vygeneruje směrovací tabulky pro CAN příkazy Systém nevybírá za vás - hlídá, že vaše volba dává smysl. Trochu jako konfigurace linuxového jádra, kterou jsem se nechal inspirovat. Z tohohle build systém vygeneruje: Makefile definice (které moduly kompilovat) Hlavičky s výčty (kódy CAN příkazů) Směrovací tabulky (směrování CAN zpráv) Inicializační sekvenci (topologicky seřazenou) Výsledek: Jeden YAML soubor definuje celý node. Zbytek je automatický. Build systém Centrální nástroj je wm_generator (Perl). Jeden příkaz: ...a máte zkompilovaný firmware. Co se děje pod kapotou: Načte konfiguraci nodu + všechny cfg.yaml modulů Vyřeší závislosti Vygeneruje hlavičky a Makefile definice Spustí make (arm-none-eabi-gcc) Archivuje sestavení s časovým razítkem Vývoj běží pod gitem na vlastním GitLabu. Od roku 2024 s pomocí AI, ale pod mým přísným dohledem - AI generuje dle mé specifikace, já reviduju a rozhoduju. Žádné slepé copy-paste. Jinak na sebe i AI šiju neustále bič. Testy testy testy testy! Hlavně proti regresi. Pro CI/CD mám i test kombinatoriky: Tohle zkompiluje všechny kombinace zadaných modulů a reportuje, které projdou a které ne (přetečení paměti, konflikty, atd.). Co dál? Není realistické zde představit veškeré moduly, ale pár zajímavých modulů bych v příštím článku rád představil v detailu: bootloader - vlastní CAN bootloader, nody se dají flashovat přes CAN bez fyzického přístupu switch-core - centrální modul pro řízení výstupů: relé, žaluzie, PWM, vše jednotně bme280 - teplota/vlhkost/tlak, plus výpočet rosného bodu přes Magnusovu formuli přímo na nodu buzzer - melodie a signalizace heartbeat - "tep" signalizace stavu node pp-flow - měření průtoku (pulsní průtokoměry) ws281x - adresovatelné LED pásky. Pro víc pásků najednou může RasPi Pico jako inteligentní periferie řídit až 4 stringy.

A pak tam někdo přidá checker, který hlídá, aby tam bylo jedno písmeno malé, jedno velké, jeden speciální znak a jedno číslo a že se to heslo musí měnit každých x dní a že se nesmí dvakrát opakovat stejné a je z toho naprostá paralýza 😃

A to si vem, že někde existují ještě funkční instalace, které by novou revizí (v případě velkého zásahu) neprošly ani před 50 lety, natož teď. Holt se to v čase mění. Dříve také nikoho nezajímalo, jestli máš nebo nemáš papír na instalaci FV. Pak přišly papíry na montéry, a teď už to může udělat jen firma. Když to čtu, tak by ztoho měl jeden depresi. V sibiřských mrazech mi jeden string přeleze na 130V, nemám extra zem na konstrukci, všechno mám ze střechy stažený ve svazku jednou KG trubkou, jsem odepsanej. 😲 Teď co bude dělat soused, co má podobným způsobem udělanou dotační FVE s 750V trolejovým napětím, Goodwe meničem a třema neustále problémovýma Pylontechama. Ale revizi nemám já a nikdy mít nebudu. 😂 Hele, právě že sousedovi to dělala firma, zrovna jedna z těch známých a frajeři se po telefonu ptali maníka, kam co přijde zapojit. Byli úplně mimo. A revizák se je ani neobtěžoval navštívit, revize přišla poštou. Při tom počtu instalací se divím, že něco nehoří každý den.

A tento výrobce? https://www.mivvyenergy.cz/cs/bateriove-clanky/clanek-lifepo4-222ah-32v-svolt-grade-a.html?SubmitCurrency=1&id_currency=1

Tohle chodí korektně a má galvanické oddělení I just found this on AliExpress: CZK115.76 | USB To RS485 Converter Isolate Module Upgrade Industrial TVS ESD Protection Original CH340E Standard RS-485 Connector Board https://a.aliexpress.com/_m03v6GV Taky pouzivam tyhle a bez problemu.

On ten posun technicky není po celou dobu křivky, ale jen v nějakou její část... Typicky kapacitní zátěž, jako je kondenzátor za usměrňovačem, má konec odběru proudu na vrcholu napětí, takže ano, tam je to 90 stupňů. Nicméně pokud by jste měli třeba elektronicky řízenou kompenzaci účiníku, tak ano, je klidně možné odebírat proud s ještě větším předstihem, protože indukční motor má účiník cca 0,9 v zátěži, ale na prázdno klidně 0,2 a tyto korekce musí být schopny toto kompenzovat. Tím tedy netvrdím, že v praxi je možné 3... asi by to byla spíš závada korekce účiníku, než nějaká možná realita - nicméně je to teoretické maximum, kterého lze nějak dosáhnout. Jako reálné maximum tedy vidím indukční motor zatížený tak, že bude proudově ve fázi s kapacitní zátěží jiné fáze a k tomu 3. f odporová (která nebude v přesném zákrytu), nebo indukční motor, zatížený tak, že bude ve fázi s odporovou zátěží a k tomu bude na poslední fázi kapacitní zátěž (která nebude v přesném zákrytu). Proud N vodičem v takových případech bude někde kolem 2,5 násobku (2 až 3 - nechce se mi přesně počítat kolik).

Už vyřešeno. Nakonec se povedlo...

https://eshop.neosolar.cz/aktualita/zaruka-5-let-s-moznosti-rozsireni/

Ta větší deska (Kincony A8) má relátka na 12V, jestli se dobře dívám. Ta malá má 5V relé. Obecně relé na 12V bývají spolehlivější. Přece jen už je tam větší prostor pro fluktuaci napětí, kdy ještě relé spolehlivě spíná. A samozřejmě i proudová špička je na 5V nepříjemně velká. Těch 5V je (podle mě) pro silnější relé taková trochu nouzovka.

dovod je taky ze mam panley na dome aktualne vychod /zapad a ani to optimalne umiestnene (musel som to dat na dom cerpam dotaciu a uradnik je "moc mudry clovek " tak ine vychodisko nebolo aktualne mam orientacu 6kwp vychod azimut 60 sklon 17 st. a 6kwp zapad azimut 240 sklon 13 st. a zena sa stazuje ze sklad dreva nie je moc pekny tak ma napadlo 2 streny zakryt fve panelmy sklad ze len taky pristresok zo zeleznej konstrukcie len stlpy plan je taky ze na stlpy by som priprvnil panty a take dver e kde by boly upevnene panely (inspiracia youtube) vojde tam 6kwp 2kwp azimut 240 a 4kwp azimut 150 a napojene na deye 10kw na gen port ako microinvertor

freecad je docela peklo. Zkousel jsme to pred lety, doklepal jsme v tom co jsem chtel ale tech bugu co jsem tam potkal. Fusion je proti tomu raj. Nekdy to zkus. Principy tam jsou uplne stejne. Tak jsem se dokopal stáhnout Fusion pro porovnání. Pro 3D používám Onshape, který mi docela vyhovuje a je taktéž zdarma pro soukromé účely - víceméně klon SolidWorks, který ovšem pro hobby stojí 1500Kč/rok. U Onshape mi vadí pouze webový běh a cloudová závislost - mám raději data v PC. Takže díky za tip, vyzkouším.

S inzeráty to sice nesouvisí, ale dnes mi přišel podvodný e-mail jakože od ČEZu Snímek obrazovky 2025-12-21 180232.jpg

Taková malá reakce na současné počasí 😃 WhatsApp Image 2025-12-21 at 11.24.56.jpeg

Opakovana zavada, rekni, ze chces novy kus.

Ok díky...

Ale Ty ho máš jako UPS ne ? Třeba je to tím, já měl při testu zaplý jen Power assist, UPS jsem nezapínal. Jinak co se týká toho měření, tak vycházím z dat co vytáhnu z měniče nebo BMV a SmartShuntu ... protože řešit waty na kleštáku je utopie.

Problém, který zmiňuješ zde ve 2 roky starém vlákně, se řešil tady: https://forum.mypower.cz/viewtopic.php?p=279642#p279642 Byl odstraněn, ale když jsi na něj narazil i teď, celé jsem to prošel znovu a našel ještě jednu chybku. Chybová hláška nemá nic společného s videem. Sekvence \xF0\x9F\x98\x82 = 😂. 4bytový unicode znak (emoji). Chybová hláška z phpBB je matoucí, protože reflektuje problém u sloupce, kde to již bylo opravené, ono to v tvém případě exlo v tabulce, která loguje offtopic příspěvky, a tam ten problém nebyl opraven. Teď již je, převedl jsem do utf8mb4 všechny tabulky, které AI moderátor používá. A více nemá smysl se v tomto vlákně rozepisovat, protože tato chyba nemá nic společného s novým vzhledem fóra.

I když jen nabíjí? Vím že čeká korekce když běží střídač ale pro čistém nabíjení bych si tom moc jistý nebyl ale nevím. Vyzkouším to u sebe, jestli dostanu účiník z citronu smartmeteru.Protože musí jako nabíječka zvyšovat, tak to neumí jinak, než být sfázovaný. A proto musí mít dobrý účiník.

Fotovoltaika by měla být předehřev, v létě ohřev - aby mohlo být TČ vypnuté a šetřilo se tak jeho opotřebení - životnost. TČ nebo AC ze sítě by měl být ohřev záložní - až teprve po 15-16h - aby to dohřálo na teplotu, kterou nezvládne FV. Ten elektrokotel tam nemá pak žádný smysl, ano - pryč s ním - pokud se doplní do bojleru spirála - která může běžet na FV a po 16h se zapnout na síť na jednom zařízení a TČ jako předehřev pak taky nedává smysl. Pokud mám 2kWp panelů - tak ohřeju 200-250Litrů za den od konce dubná do půlky září - pak mě dává smysl doplnit jen druhý bojler - to nejlevnější co lze najít - říjen a půl listopadu + březen a duben - to tytéž panely zvládnou na jeden z těch bojlerů a kupovat kvůli 2-3 měsícům bojler s TČ pak nemá smysl. Za ušetřené peníze víc a víc a víc panelů smysl dává 😂😂😂 IMG_0502.jpg Edit : co je to za elektrokotel ? Třeba by šla přípojit jedna ze spirál elektrokotle a udělat z toho fotovoltaický průtokáč a pak by se ani ta spirála kupovat a doplňovat do stávajícího bojleru nemusela a šlo by to použít tak - jak to je - a přepojit jen elektricky na FV-ohřev ;) NEBO varianta B (méně ekonomická) : panely a měnič na ten bojler s TČ v pivnici a ze stávajícího bojleru mít jen rezervu teplé vody (a opět zcela bez zásahu jen vyhodit ten elektrokotel) :D Méně ekonomická proto, že se může dohřát voda dopoledne, když slunce nesvítí z DS a po obědě vykoukne sluníčko - ALE voda už je ohřátá... škoda IMG_0502 B.jpg

Ne, emane, problém daně nikdy nespočívá v tom, že ji někdo nezaplatí celou. Ten korporát nepůjde nikdy ani na drahou operaci, ani do důchodu, čili nepotřebuje ani zdravotnictví, ani sociální péči, to je fikce, ty státní služby potřebují konkrétní lidé a měli by je nějak, ať už přímo nebo nepřímo, platit ze svých příjmů oni sami. Zdanění zisků firem je dvojím (nebo i vícenásobným) zřetězeným zdaněním, protože ze zisku nejprve platí DPPO ta firma, která ten zisk vytvořila a pak po jeho rozdělení ještě jednou daň z příjmu fyzických osob její koneční vlastníci (a to se týká i toho, co jim přiteče třeba z Irska nebo z Kypru). Vůbec se nelze divit tomu, že se to jejich vlastníci snaží různě obcházet. Valdano ovšem taky nemá pravdu, protože počítá-li zdanění, nemůže počítat jen to, jak jsou zdaněny peníze na vstupu, tedy na výplatní pásce (i když tam správně zahrne odvody zaměstnavatele), ale musí tam přidat i zdanění na výstupu, to, že ten člověk bude ty daně platit i když si za ty peníze půjde něco koupit. Pokud půjde a za ty peníze nakoupí jenom benzín do svého auta, ta daňová zátěž bude činit výrazně přes 70 % (a to se nebavím o tom, že by za to šel nakoupit nejlevnější vodku nebo starorežnou, pak by to bylo ještě víc). Reálně je tedy potřeba do daňové zátěže připočítat i DPH a spotřební daně a počítat to proti nějakému spotřebnímu koši.