MyPower.CZ

Já to ještě 2x ověřil - a je to pravda... Co jsem tehdy napsal. ( v této bílé tmě s výrobou mezi 1,5 - 2,5kWh ) Pokud vypnu Multiplusy a běží jen MPPT a Shunt - Cerbo a topení pro baterky nechám běžet ze sítě, mám cca 1,5-2,0 kWh denně navíc - protože jinak to sežere navíc v těch svých vlastních spotřebách a ani vlastní ohřev baterek neutáhne a baterka pomalu a jistě stále klesá... Možná později, až si dodělám ohřev přímo na 48V aby nemuseli běžet multiplusy... (to by šlo vlastně i teď se suchou spirálou - hm,hm promyslím to...) Ale teď jdu dělat náš český bramborový salát (protože moje ženuška je z jiného regionu a tam mají jiný... :D ) Snímek obrazovky_24-12-2025_94730_vrm.victronenergy.jpg

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.

Pak asi nerozumím kde a co to přepíná. Je to AC ignore? Pokud ne, měnič bez Power Assist neinvertuje vůbec, pokud je PA zapnutý, invertuje až u AC in current limit. Pokud AC ignore ano, umí síť na vstup synchronne propojit vnitrni transfer relé. Jediné co mě napadá, že by asi šlo přepínat bezpečne AC OUT mezi měničem a gridem, který je na AC in ignorován, protože je Multiplus zřejmě synchronizován, grid je na AC in přítomna, ale ke galvanickému spojení sítě s měničem nedojde..

za prvé 3 týždne decembra poslané do VB závratné 3,5kWh 😎 , vytiahnutých 500kWh

Grid mam pripojeny bez toho by jel menic porad v rezimu invertor. Prepina to Cerbo a zaroven tam je jeste napetove rele co hlida vypadek fazi L1,L2,L3 kdyz jakakoliv z nich vypadne prepnou se stykace

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 😃

Jj dáva to smysl: https://www.facebook.com/share/r/15uNjKKLWc/

Nemusí, nechám si poradit. Určitě nemusí. Podstatě budu mít tři trojice směrem na východ a 9trojic jz. Takže v kombiboxu mohu spojit vícero trojic. A je dost možné že se mi na střechu nevejde jedna trojice tím bych měl 1x 3s3p a 2x 3s4p.

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/

Tak to tam uvádějí ještě nebezpečnější příkaz: Ta tečka na konci není chyba. Tímto se provede update všech zařízení, která mají yaml soubor v dané složce.

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

Si tam dej wattmetr, a ten ti to všechno ukáže. Proč asi Victron nepodporuje zapojení wattmetru na výstupu 😡

Na JK-BMS mám převodník posílající data do HA. Podle návodu https://github.com/syssi/esphome-jk-bms. Funguje to dlouhodobě bez problému, ale poslední dobou nemůžu provést aktualizaci přes esphome v HA. Vyskočí následující hláška: HA - esphome chyba.jpg Ten překrytý kód hláškou je: Přitom espHome mám nainstalovaný ještě na jiném PC a tam stejný yaml zkompiluji a pošlu do zařízení bez problému. Takže z jiného PC vše funguje, ale z integrace esphome v HA to nejde. Nesetkal se s tím někdo?

Opakovana zavada, rekni, ze chces novy kus.

Ok díky...

Skúšal som aj Tolerance coin, iba 0.10 nešla pohnúť, 0.15 bola ľahko zalepená, zvyšok voľný. PETG 245°C. Zkus i pla, petg je hrozná svině

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

Jj, 16 za sebou

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.

No já to mám takto: Počet_cyklů_FVE.JPG Tzn. 58-74 cyklů za rok

sewa neviete mi niekto náhodou povedať prečo sa už z baterky nevybíja ale ide zo siete , a ešte čo to znamená grid start čo je tím myslene? vid foto

No dobře, nó, tak snižuju cenu na 900 Kč. 😉

vsak tam mas ohnuti pres 5.6mm (staci jen cist) , ano neni tam zapocitana samotna konstrukce, sklo (obyc ci bifacial) atd, dost jinych veci na to ma vliv ... muj post je spis neutralni, kazdy se musi sam rozhodnout, jakou montaz zvoli ... Je tam 0 až 5.6mm - stačí jen číst. To vím. Není tam nikde -1mm nebo tak. Končí to na 0. Pokud máš převis, a ten modul se ti uvnitř prohne, převis MUSÍ nahoru (obvykle tedy záporný ohyb). Ten chybí. Mě se ta vizualizace líbí. Taková heatmap vždy dobrá. Ale asi to nebude úplně realistická simulace. Správně by musela ukázat takový ovál, protože střed (jakožto i střed od dlouhých stran) bude víc v průhybu než kraje. No a tam kde je podpěra konzole dochází k maximálnímu a zlomovému momentu - viz dokument co poslal (ale špatně interpretoval) rva. pruhyb.jpg Jak jsem zmínil, je mi u zadnice, kdo a jak si montuje panely (kazdyho vec), ale popravdě mi stačí jen ta levá simulace "uchycení hned na kraji", zadnej previs (tim padem zadnaj pruhyb presahu nosniku). Simulaci jsem delal jen ze zvedavosti a pokud vidim, ze je max pruhyb 13mm, tak to je pro me uz moc na delce 2m. Pro tebe je to treba ok, a ten "treti", kdo se na to diva, at se rozhodne sam. 13 mm že je moc? A co most https://youtu.be/CX1MwNEpYZc

Pokud potřebuješ napájet jenom lednici, vyber si typ s invertorem a interním napětím 48V, což jsou třeba některé typy od Bosche. Ideálně po záruce, abys o ní nepřišel zásahem do zapojení. Pak to jde docela hezky bez střídače. A můžeme to vidět, takové ty lednice na 12 nebo 48V robotu za normální peníz (nemyslím ty cestovní krabice malé do auta / karavanu). To by bylo skvělé kdyby něco takového existovalo, vůbec to neznám

Ano bylo to v noci. Neuvědomuju si že bych ho zapojil jinak než jindy:-( Do Kladna ho klidně přivezu:-) To by bylo fajn, kdyby jsi se na něj podíval.

No hlavně se ten nadproud řeší ne kvůli tabulkovým hodnotám panelů, ale kvůli odolnosti přepěťové ochrany v závěrném směru v tom MPTT. Ten "transil" tam má určitou výdrž, co zvládne "stáhnout", když se vstup přepóluje. Tedy, a už to tu kdysi bylo, kdo nemá v plánu přepólovat vstup mppt, tak může hodnoty zkratového proudu brát jako doporučené. Kdo to je schopen přepólovat (a to jsme asi všichni, schválně, komu se ještě nepodařilo něco připojit opačně), tak by ty hodnoty měl brát jako závazné. Ale čistě technicky, pokud bude proud ve správném směru, tak to není třeba dodržet, protože si to ten regl udrží sám.

Ako nevyhodu mozno vnimam to, ze tie vystupne svorky su prilis blizko seba.Pri mojich prstoch je to to trochu na 💩.Ale dobre! Za tie peniaze je to celkom dobry stroj, postacujuci na vacsinu mojich aplikacii. Však tam miesto tých farebných podložiek vraz obrezané vrchnáky z PET 8-)

Asi preventivně zdvihnu spodní hranici vypnutí měniče. Teď mám 49,5V. Jen se připravuju než budu připojovat nový regulátor :) Překvapilo mne, když jsme hledal na netu, že umí tyto mppt regulátory při připojení takhle spadnout z baterky a nějakých 80a není málo..

Zdravím , škoda že se situace změnila k horšímu . Odvezu je do sběrného dvora ;) . Elektronům zdar *cloud*

Ahoj. Vdaka za ponuku,ale už nie,už zanikla možnosť výmen a podobne,síce recyklacia pokračuje,ale už tam nenosím nič... PS: prosím neber to tak že mi dlhuješ niečo za ten menič...budem len rád,ak poslúži na niečo ;)

Moc nám tu návratnost neulehčují 😢 Teď to vychází na 31Kč za 1kWh.

Ja mám předchozí a levnější verzi W1209 a ta si nastavení pamatuje. Tady očekávám to samé.

bere se z recenze na aliexpresu od nejakeho cloveka, asi treti recenze od shoraDíky, ta čínská recenze nedávná smysl ani v angličtině ani přeložená do češtiny. Může to být cokoliv, nebudu spekulovat. K tématu. Tyhle balancery jsou vcelku povedené, ale mají pouze Bluetooth. Připojit k domácí automatizaci například HA jdou. Okamžité hodnoty nemusí být vypovídající, je lepší koukat na grafy.

Rozdíl mezi HC a R spočívá v tom, že HC má konektor pro vyhřívací podložku a rozhraní CAN, zatímco R má pouze RS485. Tak je to v popisu na Nkonu.

Omlouvam se, uz jsou prodane oba dva.

Prodám tento jistič, nepoužitý, blbě objednaný. Cena 700,-Kč. (nový kolem 4000,-). Pouze osobní odběr u Litomyšle. JISTIČ OEZ 120A DC.jpg

Prodávám jen z důvodu, že jsem měl oddělený systém, zvlášť ohřev vody a zvlášť domácí síť a sloučil jsem to, jinak naprostá spokojenost, v provozu cca rok. šířka 26,8cm délka 47,4cm výška 10,5cm Cena 3500,-Kč

Ne, přesně naopak. Já kromě chození do práce musím stíhat i tohle. Když by to mělo být, jak píšeš, tak už tu nejsem, protože pojdu hladem. Zkušenosti v reálném provozu ukazují zajímavé věci a motivují mě k dalším úpravám. AI se má ještě hodně co učit. To, co chápou zde místní, to zaručeně nepochopí ani případní návštěvníci, když i AI v některých věcech plave.