MyPower.CZ

Problém bude asi v tom v Tvém očekávání :-) Já žádný technik nejsem. A elektrotechnik už vůbec ne. Je to jen snímnutá obrazovka (printscreen), takže se všemi předešlými chybami. Bylo by možné v těchto svátečních dnech přihmouřit oko 😉 a spíše se radovat, případně si zaťukat na čelo a považovat mě klidně za "de...la", než si zvyšovat tlak? Vadit mě to fakt nebude. 😂

Dej ty hodiny do pryc, to je prece nesmysl. A strasne to taha oci. Jsi technik, tak se vyjadruj presne!

Porovnávám tyto pložky. To co leze přes klešťák u Multiplusu a to co skutečně vyleze z AC Out. Ty další dvě vypočítané položky jsou VRM bludy. Nebo to počítám špatně?

Když podĕlim 795/734 tak to jsou ztráty okolo 8%.Ty máš v tabulce 15%.

Vyměnil jsem BMS za původní a zase vypnuto. Overkill to nahodil a fičí to taky. Uff, BMS jedou, čína aplikace monitoruje ale nejde to s ní nahodit. Overkill pomohl. Už jsem se bál, že je problém v baterce. Hledal jsem manuály k BMS kde se dalo ale nic. Přitom to má zvuková i světelná hlášení ale bez manuálu to je k 💩

Škoda, že nemám na stejný test i 5kVa. Možná bychom se divili i u něj :-) Multiplus II 5000 testoval Franta2776 při nabíjení EV a psal o tom v jiném tématu. Akorát on při tom tehdy neměřil účinnost, ale jen omezování výkonu ve spojitosti s chytrým Wallboxem také od Victronu. Multiplus II 5000 mu po nějaké době provozu viz citace níže po komunikaci vůči Wallboxu omezoval nabíjení na 3400W zřejmě proto, že interní větrák v Multiplus II 5000 to nestačil chladit. Hodnoty toho mého jsou při 20st C skutečně tyto: 1) 4100W 45minut 2) 3700W 180minut 3) 3400W trvale, ale neovĕřeno třeba 10 hodinami provozu Po ukončení nabíjení bĕží ventilátor mĕniče ještě 30minut... ...on mi nepadne do přehřáti, nebliká kontrolka temperature a neodstaví se, ale řekne wallboxu po komunikaci uber proud mám toho dost je mi horko a zeslabí nabíjení, vychladí se a řekne znovu wallboxu přidej nabíjení, už jsem OK. Při těch 3400W už nezpomaluje nabíjení a jede pak s tím výkonem už kontinuelnĕ.

Když se podívám do BMSky od JK, je tam 40 velkých mosfetů na 100V/180A. Na Aliexpresu stojí jeden 60Kč. To je 2400 Kč. Za stejnou cenu si tam můžu objednat celou BMSku. A to nepočítám tranzistory balanceru, procesor, kondenzátory, komunikaci, tišťák, chladiče, konektory s kablíkama a hromadu dalších věcí. Tohle se prostě nemůže vyplatit u nás vyvíjet a vyrábět, když se to dá takhle levně koupit hotové a funguje to dobře. I kdybych se chtěl vyhnout čínskému softwaru, pořád se mi vyplatí koupit tu jejich BMSku a napsat si svůj. Totéž platí u střídačů od Voltronicu. Té ceně, za kterou oni to vyrobí, se nedá ani zdaleka přiblížit.

I u článků, které nejsou úplně rovné mohou být z hlediska další životnosti pružiny lepší než nic nebo než pevná komprese bez pružin.

Ja zatim tisknu bez problemu se zavrenou, kdyby nahodou nastal problem tak otevru. Ldyz je zavrena je tissi🤣

Já žádné android aplikace nepoužívám takže v tomto neporadím. (Pouze pro nastavení BMS přes BT.)

Tak jsem neodolal panelům za nízkou cenu a našel jsem místo na jeden string na zahradě - pro zimní posílení. Jsou to sice jiné panely, než mám na střeše ale parametry jsou stejné, jen max. výkon mají psaný o 5W větší... K 5 stringům na střeše (JVV/SZZ - nedobrá poloha na zimu) jsem připojil paralelně šestý. Čistý jih, sklon odhaduji tak na 30%, víc to nejde, abych nedráždil sousedku a úřady. Jen tak na stavební latě. Kabel vyšel asi 22 metrů. Nárůst výroby je hodně zajímavý. Celá původní střecha dala v plně slunečný den předevčírem 5kWh (to je její maximum v prosinci, musí být nebe bez mráčku celý den). Vylepšená sestava dala DNES 7,66 kWh, a to chodily mráčky (poloha na jih se projevila). To se mě líbí :-) Na léto je budu muset odpojit, nebo mě exploduje regulátor :D 251228-M1234567_PridavnePanely.jpg Ani jsem neměl doma Omega sponky, tak to šlo metodou, co dům dal...

Venku každý den excelentní počasí a zisk každy den o něco vyšší :) Po dlouhém období temna - každodenní radost :D Snímek obrazovky_28-12-2025_164953_vrm.victronenergy.com.jpeg

Přestal mi fungovat Xcom-232. Myslel jsem si, že zabloudil vnitřní firmware. Dělal jsem před tím update firmwaru celého systému a měnil z Xcom-LAN na Xcom-232 a zpět.... Zkoušel jsem tedy upgrady, downgrady, resety atd. Divné mi bylo, že při commandu na reset systému zabral, ale neposlal už odpověď že příkaz provedl. Nakonec jsem na něj zaútočil ošklivoskopem a bylo jasno hned: Umřel ten vysoce integrovaný galvanický izolátor / budič RS232 - ADM3251E. Protože takhle obskurní integráč doma nemám, vzal jsem čínský modulek s jednoduchým ADUMem a nadrátoval na divoko. Komunikace už zase běží. Náhradní chip si objednám a časem vyměním. Můj Xcom-232 je ze SecondSolu z roku 2014. Za tohle asi nemůže Studer, ale Analog Devices. Máte někdo podobnou zkušenost?

Měřím proteklé Ah baterií. Zuby souvisí s navýšením kapacity, popřípadě změřením aktuální kapacity, popřípadě vyřazením nejstarších článků. Jo a bateriemi protéká zhruba 1/3 spotřeby domácnosti. O ty zbylé 2/3 se dělí distributor a dodávka přímo z fv panelů. Počet cyklů baterie.jpg

Sice to asi nebude úplně v souladu s normou, ale stále ten nulák jde zdvojit i dalším vodičem mimo ten kabel.

Nová aktualizace firmwaru JK BMS v19.21 vydaná v prosinci 2025 (video z 23.12.2025). Autor videa zmiňuje, že je k této aktualizaci až příliš kritický, protože Jikong neposkytl žádné další informace o některých nových funkcích a vlastně se mu hlavní funkce této aktualizace ani nelíbí. Podle jeho názoru tato verze ubírá na pohodlí, které bylo k dispozici v předchozích verzích. Jeho stezovani na to, ze tam nevidi napeti te dane baterie mi prijde zbytecne. Pokud jsou baterie spojene a komunikuji, je na nich prakticky stejne napeti. Pokud by se komunikace rozpadla, uvidim tam napeti te baterie. Me to osobne prijde lepsi. Ale tyhle bms nemam a nemam ani display :)

Jó srandičky. Tu hračku i s 4S Lipol 7,8Ah bude parkovat ať už doma nebo v garáži třeba někde na polici a parkování zdarma a možná i bez frflání bude mít schváleno od manželky/partnerky apod.

Tak u stažení už mám jasno - pružiny. Závitovky M6, na to jako kluzná mezivrstva plastová pneumatická hadička 8/6 mm, a pak 10 nebo 12 talířových pružin s vnitřním průměrem 8 mm. Nemáte nějaký dobrý tip na pružné propojky mezi články? Mám hubené články, jen 36 mm. Ale zato jich mám hodně, tak by to nemělo stát majlant. Kolega to udělal tak, že použil kabelová oka a mezi ně kousíček svářečského kabelu. Měla by to být hodně měkká licna. V nejhorším bych to udělal taky tak, ale musel bych ta oka dát našikmo. A představa lisování 160 ok mě teda netěší. Nejvíc by se mi asi líbila nějaká pletená měděná licna v plochém provedení. Konce pocínovat a vyrazit do ní díry pro šroub. Nemáte prosím nějaký dobrý tip? Díky.

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 😃

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

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%).

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.

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

Ok díky...