WHIP

[PetaJoule]

WHIP: Když vám běžný smart home nestačí

Zdravím,

chci vám představit projekt, na kterém pracuji už několik let - WHIP
(Witty House Infrastructure Processor).

Nikdy jsem neplánoval psát vlastní smart home systém. "Not Invented
Here" syndrom a znovuvynalézání kola jsou věci, kterým se snažím
vyhýbat. Když existuje funkční řešení, použiju ho.

Jenže když jsem v roce 2019 začal řešit automatizaci pro novostavbu,
žádné jsem nenašel. FHEM, MySensors, HomeAssistant, Loxone, KNX... COVID lockdown 2020 mi dal dost
času na opravdu důkladné testování. Výsledek? Všechno bylo daleko pod
mými požadavky - buď architektonicky, nebo z hlediska spolehlivosti,
nebo obojí. Většinou obojí.

Teprve když jsem vyčerpal všechny rozumné alternativy, došel jsem k
závěru: pokud chci systém, kterému můžu věřit na příštích 50 let (nebo
dokud mi doběhne trvanlivost), musím si ho napsat sám. Ne proto, že
bych chtěl - ale proto, že nic vhodného neexistovalo.

Co to je?

WHIP je třívrstvá architektura pro řízení chalupy/domu/residence/hradu/letiště/...:

1. Nodes - STM32 mikrokontroléry s FreeRTOS, propojené 1Mbit CAN sběrnicí. Starají se o senzory, relé, měření, lokální automatiku.
2. Hub - Raspberry Pi jako agregátor a gateway. Překládá CAN na IP, běží na něm Modbus, DALI, integrace s externími systémy.
3. Server - Linux server pro vyšší logiku, vizualizaci, napojení na cloud služby (volitelně).

Klíčový princip: vyšší inteligence je vždy doplněk, nikdy
podmínka. Když vypadne server, hub funguje dál. Když vypadne hub,
nodes běží autonomně. Žádná cloud závislost.

Co to umí dnes?

• Energetický management - kompletní integrace Victron systému (3f Multiplus-II 10kVA + MultiRS záloha, dost MPPT trackerů, 120 kWh baterií). Dům je kompletně off-grid - žádná přípojka, žádné tarify. Benzínová elektrocentrála pro nouzi, V2L z elektromobilu jako koncept.
• Tepelné čerpadlo - monitoring a řízení MasterTherm přes Modbus
• Osvětlení - DALI řízení přes ATX LED HAT na RasPi
• Modbus - plná implementace TCP i RTU (17 z 21 function codes, 869 testů, 91% pokrytí)
• cca. 116 modulů senzorů/aktorů - od BME280 přes PCF857x expandéry až po AS3935
• 30+ externích integrací - Victron VRM, PVGIS, Discord, Nextcloud, Proxmox, UniFi...

Proč CAN bus a ne WiFi/Zigbee?

Drátová sběrnice. Žádné interference, žádné vybité baterie v
senzorech, žádné "mesh se rozpadl". CAN je průmyslový standard -
stejná technologie, co řídí komponenty vášeho auta. 1Mbit rychlost,
diferenciální signál, 40m dosah na segment, až 60 nodů na hub.

Ano, znamená to kabeláž. Ale stavím dům na 50+ let, ne na 5.

Proč CAN bus a ne jiné drátovačky?

RS485/Modbus: Fyzická vrstva bez arbitrace. Dva nody vysílají
současně = kolize = garbage. Proto Modbus funguje jen jako
master-slave (master se ptá, slave odpovídá). Žádná peer-to-peer
komunikace mezi nody. (WHIP Hub má plnou Modbus implementaci - pro
integraci zařízení třetích stran nezbytné.)

KNX (dříve EIB): Má arbitraci podobnou CANu, je
multi-master. Ale 9600 baudů - návrh z 90. let. Plus drahé
certifikované komponenty a uzavřený ekosystém.

LIN: Jednodráťová automotive sběrnice, master-slave only, max
20 kbaud. Pro okna a zrcátka v autě OK, pro smart home pomalé a
omezené.

1-Wire: Pomalé, omezená topologie. Výborné pro teplotní senzory
DS18x20 a.j., ale ne jako hlavní sběrnice. (WHIP ho podporuje jako modul -
proč ne, když to funguje.)

CAN má hardwarovou arbitraci (CSMA/CR) - když dva nody vysílají
současně, nižší ID vyhraje, druhý automaticky ustoupí, žádná ztráta
dat. True multi-master, 1 Mbit, diferenciální signál. Průmyslový
standard s dostupnými čipy.

Pro koho to je?

Buďme upřímní - tohle není pro každého. Pokud chcete
plug-and-play, HomeAssistant nebo Loxone vám poslouží líp.

Aktuální stav

Projekt je navržen pro dvě vily - Villa-A (CZ) a Villa-B (DE) s
podobnou koncepcí (ale jinou konfigurací a komponenty) - což vynutilo
generické řešení, ne jednorázový hack.

Systém běží v reálném nasazení - Villa-A v Praze má kompletní
energetický management, monitoring TČ, distribuovanou síť nodů v
rozvaděčích. Není to prototyp na stole, je to funkční instalace.

WHIP je pro ty, kdo:

• Staví nebo zásadně rekonstruují
• Preferují drátovou spolehlivost před bezdrátovým komfortem
• Jsou technicky zdatní (nebo mají někoho, kdo je)
• Chtějí plnou kontrolu bez vendor lock-in

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.

Kde najdete víc?

No, samozřejmě tady.

Na webu divis.petajoule.eu (chytrá domácnost)
jsou přehledové články spíš pro "širší" publikum.

Tato série na fóru může být techničtější - v dalších dílech se
podíváme na CAN bus v praxi, návrh nodů, integraci Victronu,
zkušenosti s Modbus, a další.

[PetaJoule]

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:

Kód: Vybrat vše

a4988       at24cxx     ccs811       ds2401     gateway     ht16k33     lis3mdl
adc-core    bh1750      cd74hc4067   ds2408     global      hx711       lm75
ads111x     bme280      core         ds2413     graphics    icm20948    lsm303xx
aht2x       bmi088      dac-core     ds2431     hcsr04      ina2xx      lsm6dso
apa102      bmi1xx      dali-slave   ds2438     hd44780     ina3221     max30102
apds9960    bmp390      dhtxx        ds2450     hdc1xxx     ir-remote   max31855
as3935      bno055      dps310       ds-rtc     hdc2xxx     l3gd20      max31865
as5047      bootloader  drv8825      ft6x06     heartbeat   lightshow   max72xx
as5600      buzzer      ds18x20      ganglion   hmc5883l

mb85rcxx    mpu6xxx     pcd8544      rtc-core   sht4x       sx1276      watchdog
mcp230xx    mpu9xxx     pcf8563      scd4x      shtc3       tm1637      ws281x
mcp980x     ms5611      pcf8574      sd2405al   si5351      tmp1xx      x9cxxx
mem-core    nrf24l01    pcf8575      serial     ssd1306     tsl256x
mfrc522     onewire     pcf8591      sgp4x      st7789      veml7700
mlx90614    opt3001     pca9548      sh110x     stm32-eeprom vl53lxx
mmc5603     pca955x     pca9685      sht1x      stm32-nvm   vl6180x
mpr121      pp-flow     qmc5883l     sht2x      switch-core w25qxx
            relay-base  rotary-encoder sht3x

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:

Kód: Vybrat vše

requires: '(pcf8574 | pcf8575), adc_core'   # potřebuje: (A nebo B) a C
provides: 'gpio_expander'                    # poskytuje virtuální schopnost
suggests: 'heartbeat'                        # doporučuje (volitelné)
conflicts: 'legacy_relay'                    # vzájemně se vylučuje

Resolver funguje jako strážce. Když povolím switch_core:

1. Podívá se na requires - potřebuje (pcf8574 | pcf8575)
2. Zkontroluje, že uživatel povolil alespoň jeden z nich
3. Pokud ne → chyba, build selže s jasnou hláškou
4. Rekurzivně zkontroluje závislosti všech povolených modulů
5. Topologicky seřadí inicializační pořadí
6. 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.

Kód: Vybrat vše

# Konfigurace nodu (YAML)
mods:
  - heartbeat
  - switch_core:
      channels:
        - { channel: 1, role: simple, out: [1, 1] }
        - { channel: 2, role: blind, out_up: [1, 3], out_down: [2, 3] }

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:

Kód: Vybrat vše

tools/wm_generator c dev-nucleo-f103rb

...a máte zkompilovaný firmware. Co se děje pod kapotou:

1. Načte konfiguraci nodu + všechny cfg.yaml modulů
2. Vyřeší závislosti
3. Vygeneruje hlavičky a Makefile definice
4. Spustí make (arm-none-eabi-gcc)
5. 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:

Kód: Vybrat vše

tools/test_node_combinatorics -m bme280 -m switch_core -m heartbeat

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.

[PetaJoule]

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:

1. Pošlu CAN příkaz "enterBootloader"
2. Firmware odpoví potvrzením, nastaví příznak v záložních registrech a provede reset
3. Po resetu bootloader najde příznak a zůstane aktivní (jinak ihned předá řízení firmware)
4. Nahraju nový firmware přes WBTP-XL protokol (Witty Bootloader Transfer Protocol - XL)
5. 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:

Kód: Vybrat vše

switch_core:
  channels:
    - name: "Žaluzie obývák"
      role: blind
      out_up: [1, 3]      # expandér 1, kanál 3
      out_down: [1, 4]    # expandér 1, kanál 4
      reversal_delay_ms: 500

    - name: "Světlo kuchyň"
      role: simple
      out: [1, 1]

    - name: "Termoventil"
      role: duty
      out: [2, 1]
      period_sec: 100     # perioda pro 1% granularitu

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í:

Kód: Vybrat vše

γ = (0.1762 × T / (243.12 + T)) + ln(RH / 100)
rosný_bod = (243.12 × γ) / (17.62 - γ)

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:

Kód: Vybrat vše

requires: '(pcf8574 | pcf8575), adc_core'
suggests: 'cd74hc4067'

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í.

[PetaJoule]

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:

Kód: Vybrat vše

Rychlost      Max. délka
1 Mbit/s      30 m
500 kbit/s    100 m
250 kbit/s    250 m
125 kbit/s    500 m

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ě:

1. Oba vysílají své ID bit po bitu, od nejvýznamnějšího
2. Monitorují sběrnici
3. Node, který vyslal recesivní bit ale čte dominantní, prohrál - přestane vysílat a stane se příjemcem
4. 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:

Kód: Vybrat vše

| SOF | Arbitrace (32b) | Ctrl (6b) | Data (0-64b) | CRC (16b) | ACK (2b) | EOF (7b) |

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:

Kód: Vybrat vše

void
whip_audio_buzzer_handleCAN(CANmsg_t* cmsg_rx, uint8_t subcmd) {
    CANmsg_t cmsg_tx;
    uint8_t  dlc = 0;

    switch(subcmd) {
    case WMSC_BUZZER_query:
        // Sestavit odpověď se stavem modulu
        cmsg_tx.data[dlc++] = Buzzer.paused | Buzzer.repeat << 1 | Buzzer.speedup << 2;
        cmsg_tx.data[dlc++] = Buzzer.loudness;
        cmsg_tx.data[dlc++] = Buzzer.transpose;
        // ... poslat odpověď
        break;

    case WMSC_BUZZER_set:
        // Zpracovat příchozí parametry
        Buzzer.paused  =  cmsg_rx->data[0] & 0b000001;
        Buzzer.repeat  = (cmsg_rx->data[0] & 0b000010) >> 1;
        Buzzer.loudness  = cmsg_rx->data[1];
        // ...
        break;
    }
}

Podobně switch-core:

Kód: Vybrat vše

void
whip_switch_handleCAN(CANmsg_t* cmsg_rx, uint8_t subcmd) {
    switch (subcmd) {
    case WMSC_SWITCHCORE_set:
        uint8_t  channel = cmsg_rx->data[0];
        uint8_t  value = cmsg_rx->data[1];
        uint16_t duration = (cmsg_rx->data[2] << 8) | cmsg_rx->data[3];
        whip_switch_set(channel, value, duration);
        break;

    case WMSC_SWITCHCORE_stop:
        uint8_t channel = cmsg_rx->data[0];
        if (channel == 0xFF) {
            whip_switch_stop_all();
        } else {
            whip_switch_stop(channel);
        }
        break;
    // ...
    }
}

Vzor je stejný:

• subcmd (4 bity) určuje operaci
• data[0..7] 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:

Kód: Vybrat vše

                      whip_<modul>_handleCAN(frame)
                               ^
              +----------------+----------------+
              |                |                |
        CAN zpráva        Ganglion          Ganglion
        ze sběrnice       (tento node)      (jiný node)
              |                |                |
           Wcancmd       lokální volání     odeslat CAN

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:

Kód: Vybrat vše

modul:subprikaz(parametry)              # tento node
node:modul:subprikaz(parametry)         # jiný node na lokální sběrnici
node@CANx:modul:subprikaz(parametry)    # node na vzdálené sběrnici (přes hub)

IF-THEN pravidla:

Kód: Vybrat vše

IF podmínka THEN akce
IF podmínka THEN akce1; akce2; akce3

IF bme280:temp > 280 THEN relay:set(1, 1)
IF button:pressed == 1 AND light:level < 50 THEN lights:on

Definice konstant:

Kód: Vybrat vše

DEF THRESHOLD_HIGH = 280    # 28.0°C
DEF THRESHOLD_LOW = 260     # 26.0°C (hystereze)
DEF FAN_RELAY = 2

Časovače:

Kód: Vybrat vše

SET $T_0 = 300                    # Start časovače (300 sekund)
IF !$T_0 THEN lights:off          # Když časovač vyprší

Logické operátory:

Kód: Vybrat vše

IF cond1 AND cond2 THEN akce
IF cond1 OR cond2 THEN akce
IF cond1 XOR cond2 THEN akce

Příklady

Termostat s hysterezí:

Kód: Vybrat vše

DEF SETPOINT_HIGH = 280
DEF SETPOINT_LOW = 260

IF bme280:temp >= SETPOINT_HIGH THEN relay:set(1, 1)
IF bme280:temp < SETPOINT_LOW THEN relay:set(1, 0)

Světlo s časovačem:

Kód: Vybrat vše

DEF LightTimeout = 300

IF motion:detected THEN lights:on; SET $T_0 = LightTimeout
IF !$T_0 THEN lights:off

Koordinace mezi nody:

Kód: Vybrat vše

DEF Kitchen = 42
DEF LivingRoom = 43

# Kouřový detektor v kuchyni spustí alarm všude
IF Kitchen:smoke:detected THEN buzzer:alarm(1)
IF Kitchen:smoke:detected THEN LivingRoom:buzzer:alarm(1)

Stavový automat:

Kód: Vybrat vše

SET $B_0 = 0    # Stav: 0=idle, 1=active, 2=cooldown

IDLE:
    IF motion:detected == 1 THEN SET $B_0 = 1; SET $T_0 = 30; GOTO ACTIVE
    GOTO IDLE

ACTIVE:
    lights:on
    IF $T_0 == 0 THEN SET $B_0 = 2; SET $T_0 = 10; GOTO COOLDOWN
    IF motion:detected == 1 THEN SET $T_0 = 30
    GOTO ACTIVE

COOLDOWN:
    lights:dim(50)
    IF $T_0 == 0 THEN SET $B_0 = 0; lights:off; GOTO IDLE
    GOTO COOLDOWN

Kompilace a nasazení

Ganglion skripty (.tgc) se kompilují do bajtkódu (.bgc):

Kód: Vybrat vše

tools/Wgc script.tgc           # kompilace
tools/Wgs script.tgc           # simulace

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.

[PetaJoule]

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.

Kód: Vybrat vše

Raijin (RasPi 4B, technická místnost)
   +-- USB-RS485 adaptéry
   |      +-- BMS Stack 1 (16S LiFePO4)
   |      +-- BMS Stack 2 (16S LiFePO4)
   +-- Ethernet
   |      +-- Victron CerboGX (Modbus TCP)
   +-- Relay HAT (lokální spínání)
   +-- InfluxDB + Grafana (vizualizace energie)

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.

Kód: Vybrat vše

Lucifer (RasPi 4B, technická místnost)
   +-- DALI HAT (4 sběrnice)
         +-- bus 0: suterén
         +-- bus 1: přízemí
         +-- bus 2: patro
         +-- bus 3: exteriér

Bragi - severský bůh poezie a hudby. Multiroom audio, rozpoznávání
hlasu, AI asistence. RasPi 5 s HiFiBerry ADC+DAC pro kvalitní zvuk.

Kód: Vybrat vše

Bragi (RasPi 5, suterén)
   +-- HiFiBerry ADC (vstup)
   +-- HiFiBerry DAC (výstup)
   +-- Reproduktorové zóny

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:

Kód: Vybrat vše

              /--- Raijin (energie)
             /--- Lucifer (světlo)
server --- ETH --- Bragi (audio)
             \--- Gaia (zahrada)
              \--- Tyr (...)

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:

Kód: Vybrat vše

WHIP::Protocol::CAN
WHIP::Protocol::DALI
WHIP::Protocol::Modbus
WHIP::Protocol::MQTT
WHIP::Protocol::SNMP

Daemon Layer:

Kód: Vybrat vše

WHIP::Model::Daemon::Base    # životní cyklus, polling, cache, health
WHIP::Model::Daemon::Modbus  # Modbus TCP/RTU daemon

Controller Layer (REST API):

Kód: Vybrat vše

WHIP::Controller::Modbus::Device   # CRUD pro zařízení
WHIP::Controller::Modbus::Health   # monitoring
WHIP::Controller::Victron::*       # Victron integrace
WHIP::Controller::ECS::LiPro       # BMS integrace

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:

Kód: Vybrat vše

# Konfigurace v raijin.yaml
devices:
  ecs:
    lipro:
      bms1:
        type:   RTU
        port:   /dev/ttyUSB0
        speed:  57600
        parity: even
        cells:  16
      bms2:
        type:   RTU
        port:   /dev/ttyUSB1
        speed:  57600
        parity: even
        cells:  16

Výsledek na Grafana dashboardu:

Kód: Vybrat vše

Id  Voltage    Min/Max        Temp    Balancing
 1  3.280 V  (3.239/3.459)   16.9°C     0
 2  3.278 V  (3.241/3.457)   17.1°C     0
...
16  3.278 V  (3.239/3.456)   18.8°C     0
────────────────────────────────────────
MinV: 3.272 V  MaxV: 3.281 V  Spread: 0.009 V
Avg temp: 17.5°C

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

Kód: Vybrat vše

CAN nody ──┐
           ├── Hub ── InfluxDB ── Grafana
Modbus ────┤         (time-series) (vizualizace)
DALI ──────┘

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.

[PetaJoule]

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ě.

Kód: Vybrat vše

Bateriové úložiště (48V LiFePO4)
         |
    DC/DC měnič
         |
    24V DC sběrnice ──────────────────────┐
         |                                |
    LED svítidla (24V)              DALI zdroj
                                          |
                                   DALI sběrnice (16V)
                                          |
                              ┌───────────┼───────────┐
                              |           |           |
                          spínače    senzory    drivery

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.

[PetaJoule]

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:

Kód: Vybrat vše

# Konfigurace v YAML
switches:
  obyvak_vstup:
    address: 12
    short_press:
      - light: obyvak_strop
        action: toggle
    long_press:
      - scene: obyvak_relax

lights:
  obyvak_strop:
    address: 5
    bus: 1
    type: DT8_TW    # tunable white

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í.

Kód: Vybrat vše

presence_simulation:
  enabled: true
  variation_minutes: 15
  exclude_rooms: [garaz, sklep]
  active_hours: [18:00, 23:00]

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.

Kód: Vybrat vše

modes:
  party:
    pir_enabled: false
    switch_obyvak:
      action: cycle_scenes
      scenes: [party_red, party_blue, party_rainbow]

  night:
    pir_corridor:
      brightness: 10
      timeout: 60

  security_breach:
    all_lights:
      action: flash
      interval: 500

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.

Kód: Vybrat vše

auto_off:
  pradelna: 120    # minuty
  wc: 30
  spiz: 60
  obyvak: disabled
  loznice: disabled

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:

Kód: Vybrat vše

POST /dali/lights/kuchyn/off
POST /dali/scenes/vse_zhasnout
GET  /dali/lights/status

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

Kód: Vybrat vše

                    ┌─────────────────────────────┐
                    │         Lucifer             │
                    │      (RasPi 4B)             │
                    │                             │
                    │  ┌─────────────────────┐    │
                    │  │   WHIP::Protocol    │    │
   ETH/CAN ◄────────┼──┤      ::DALI         │    │
                    │  └─────────────────────┘    │
                    │            │                │
                    │  ┌─────────────────────┐    │
                    │  │  ATX LED HAT-I4     │    │
                    │  │   (koprocesor)      │    │
                    │  └─────────────────────┘    │
                    └───────────┬─────────────────┘
                                │ Serial 19200
              ┌─────────┬───────┴───────┬─────────┐
              │         │               │         │
         DALI bus 0  bus 1          bus 2     bus 3
          suterén   přízemí         patro    exteriér
              │         │               │         │
           ┌──┴────┐ ┌──┴────┐      ┌───┴───┐ ┌───┴───┐
           │světla │ │světla │      │světla │ │světla │
           │spínače│ │spínače│      │spínače│ │spínače│
           │PIR    │ │PIR    │      │PIR    │ │PIR    │
           └───────┘ └───────┘      └───────┘ └───────┘

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.

[Mex]

Pěkné.
Nepochopil jsem ale z toho, co je to za typ projektu.

Je to otevřený open-source projekt? Pak jsem ale neviděl žádný odkaz na zdrojáky a dokumentaci.
Nebo to je komerční projekt, který nabízíš a prodáváš? Pak tu schází cenové relace a mělo by to možná být spíš v nějaké inzertní sekci.
Případně sis to postavil jen pro sebe a tady ses jen pochlubil?