Nevím, zda to víte, já to vím jen pár dní. Od 1. července 2026 končí bezcelní zasílání drobných zásilek z Číny do EU. Díky reformě unijního celního kodexu (EU Customs Reform 2026) se mění pravidla:
– Ruší se bezcelní limit pro zásilky do 150 EUR
– Nové fixní clo: 3 EUR za každou položku (ne za zásilku, ale za každý druh zboží v ní)
V praxi to znamená, že když si objednáte různé drobnosti, co Vás zrovna napadnou, že Vám chybí, zaplatíte za každý typ zboží 3 EUR. Děkuji pěkně.
Takže, když budete mít v zásilce 2× konektor, 2× čidlo a 1× kabel, máte to hned za 3× 3 EUR navíc :-(.
A jako bonus, někdy kolem listopadu 2026 by k tomu měl přibýt ještě manipulační poplatek za celní odbavení. Takže nejenže zaplatíte výpalné za každou položku, ale ještě si připlatíte za to, že Vám to někdo počítal. No není to úžasné?
Zbývají “nám” poslední dva měsíce, abychom se zásobili na tuhou zimu. Pak už budeme objednávat zřejmě vše po 100 ks, aby se tohle výpalné nějak rozložilo. Případně pak snad z evropských skladů, kde jdou zásilky z Evropy, takže se jich nové clo netýká. Jenže, většina elektronických serepetiček v evropských skladech často nebývá, takže štěstí :).
A abych Vám s těma nákupama na poslední chvíli pomohl, updatl jsem po letech můj AliExpress monster list a udělal verzi 2026 :). Třeba Vám to pomůže vzpomenout si, co všechno potřebujete nakoupit, než nás EU začne chránit proti těm zlým drobným balíčkům.
Rok se nám opět chýlí ke konci a máme tu zas Vánoce. Čas, který můžeme trávit s rodinou, přáteli, ale hlavně v naší technické místnosti doladit všechny ty resty, které celý rok odkládáme :))).
Přejeme Vám proto za nás svátky plné pohody, odpočinku a radosti. Ať pod stromečkem najdete spoustu dárků, hlavně pak nové technologické hračky nebo věci na bastlení, a během svátků si pak najdete alespoň trochu času si s nimi pohrát :).
Díky Vám všem, našim čtenářům, přispěvatelům a komunitě. I díky Vám je tento blog stále aktivní a nápomocný i ostatním. Děkujeme Vám za každé sdílení zkušeností i pomoc druhým.
Krásné svátky.
Notifikace výpadku elektřiny pomocí Solax + Home Assistant + Pushover
Tak, dneska si dáme návod na Home Assistant. V něm stále dost plavu, tak si tu budu postovat i tyhle jednodušší věci, ať se k tomu můžu vracet. Jelikož nám dnes opět 2x vypadla elektřina a já chci vědět, kdy se to děje, chci si posílat notifikaci z Home Assistantu, který je připojený k Solaxu, pomocí Pushoveru na mobil. Tentokrát to dáme bez NodeRedu a dalších systémů :).
Toto je velmi snadné, Pushover je podporován přímo čistým Home Assistantem, tak není potřeba dělat žádné skopičiny. Setting – Devices & Services – Add Integration – Pushover. Po instalaci je potřeba zadat Application ID a User ID, které jste získali při minulém kroku.
Pokud si nyní chcete otestovat, že Vám Pushover funguje, běžte do Developer tools – Actions, vyberte “Send a notification with pushover”, a do message dejte třeba “Test”. Pak “Perform action” a zpráva by na Vás už měla koukat z mobilu.
3) Povolení “Grid Status” hodnoty pro HA
Tento krok je trochu zvláštní, ale musíte v nastavení Solaxu pro HA povolit hodnotu “Grid Status”, která tam defaultně je vypnutá. To uděláte v Settings – Devices & services – Solax Inverter Modbus – Solax Inverter (jen kliknout na řádek) – zascrolovat dolu na seznam, kde bude “+ 57 disabled entities”. Tam najít “Grid status” a pomocí oka povolit jeho zobrazení.
4) Vytvoření automatizace – jednoduchá varianta
Nyní běžte do Settings – Automations & scenes, tam “Create Automation”. Tam vyrobíme jednu automatizaci, která Vám pošle notifikaci vždy, když se změní stav “Grid Status”. To uděláme následně:
When
Do when vyberte nejprve Entity – State, a tam vybrat “Grid Status”. Vše ostatní nechat prázdné, dát Save
Then do
Druhé je “Then do”. Tam dejte “Add action” a “Pushover”. Do Message pak zadáme zprávu ve tvaru “Změna stavu elektriky z X na Y v Z hodin”. To uděláme tak, že do “Message” dáme:
Změna stavu přívodu elektriky do domu z
"{{ trigger.from_state.state }}"
na
"{{ trigger.to_state.state }}"
v {{ now().strftime('%H:%M:%S') }}.
Pak zase save, a hotovo. Teď si buď můžete jít shodit jističe, nebo to místo “Grid Status” dejte na “House Load” a ona Vám notifikace přijde pokaždé, když se změní odběr domu. Na vyzkoušení dobré, pak to zas přehoďte zpět.
4b) Vylepšená notifikace dle toho, jestli elektřina vypadla nebo se zpět nahodila, včetně různých zvuků
Uděláme dvě různé notifikace. Jednu pro shození, jednu pro nahození. Ať máme různé zvuky (šlo by i přímo jednou notifikací pomocí choose, ale toto je snazší).
Do “Then To” pak přidáme zas rovnou “Send a notification with pushover”. Abychom to ještě trochu vylepšili, nastavíme custom zvuk pro výpadek
Tzn, do message nějakou zprávu, která zároveň vypíše i nový stav: Výpadek elektriky, aktuální stav měniče {{trigger.to_state.state}}. A do data pak { sound: "alien" } a nebo zkráceně sound : alien. (seznam zvuků najdete tady, můžete si dokonce nahrát zvuky svoje).
Druhý je pak už vcelku jednoduchý. Můžete dát “Duplicate” původního pravidla, a jen změnit ve “When” z “From” na “To”. Tzn, From vymazat, a do To dát “OnGrid”. Dále pak vyeditovat Push over notifikaci, změnit text, zvuk. A hotovo.
Poznámky pod čarou
Proč používám Grid status a ne Run Mode? Protože run mode ma mraky stavu, zatímco Grid status jen 4?
Jak simulovat stavy lépe? Pomocí fake helpers. V Settings – Helpers – Create helper. Tam si vyrobte dropdown, dejte hodnoty které potřebujete simulovat, a pak v senzoru napojte na tento fake dropdown.
Změna fake stavu se pak dělá v Developer tools – States – Set State. Aktuální stav entity pak vidíte dole v seznamu Entity, kde můžete i filtrovat dle názvu.
A na závěr, pokud chcete fakt cool zvuk, když Vám vypadne elektrika, tak tady máte Sad Trombone :). Ten si nahrajte do PushOveru pod sad_trombone a pak ho pomoci sound : sad_trombone aktivujte 🙂
Třetí den, třetí článek, třetí změna v plánu a další pokusy :).
Po včerejšku a hraní si s HomeAssistantem a NodeRed stále promýšlím, jak to celé ve finále uchopit. A čím víc o tom přemýšlím, tím víc se mi to zas celé vrací k Loxone, což má bohužel i některá negativa, jako to, že zjišťuju, kde/jak sehnat nejlevnější Miniserver V2 :).
Ale jedno po druhém, protože problém číslo jedna je….
Kam s přebytky
Tohle jsem fakt nečekal, že se mi s FVE stane, ale je neskutečně frustrující vidět, jak svítí, a není už tu elektrika kam cpát :). Včera první den parádně svítilo, baterky se dobily, I. vyprala a vysušila všechno prádlo, co šlo, a pak už to nebylo co s tím. Hrozný pocit. Jediné co člověk může, je pustit si přímotop venku v pergole, úplně jen tak, protože prostě může :).
A tak jsem začal samozřejmě vymýšlet. Krom ohřevu vody, kterou budeme teprv instalovat, by to chtělo něco dalšího. V létě filtrace bazénu a klimatizace, ale co v zimě. A tak došlo na Acond :)))).
Proč si v době přebytků nenahřát beton pod nohama, aby večer nemuselo jet čerpadlo tak moc. Brilantní nápad. A tak jsem začal dloubat do Loxone.
Rozšíření logiky Acondu v Loxone
A protože už teď Acond přes Loxone řídím, zas tak velký problém to nakonec nebyl. Rozšířil jsem si modbus komunikaci na přepínání režimu Bivalence a Tepelného čerpadla (protože když jsem to přepínal naposledy, na 14 dnů jsem to zapomněl vrátit zpět a vesele jsme jeli za plnou 🙂 ).
Dál jsem pak udělal dočasně “boost” tlačítko, které když přepnu, krom přepnutí na bivalenci se také nastaví požadovaná teplota vratné vody na 45C podobně, jako když klesne teplota domu pod nějakou mez.
Díky tomu se čerpadlo roztočí a dle toho, zda je v režimu TČ nebo BIV roztočí i solanku a nebo jen patronu. Brilantní.
A funguje to skvěle. Do pár sekund je na baráku spotřeba o 4 kW větší, masa betonu se nahřívá a panely nezahálí. Později pak budu muset doladit i logiku samo-zapínání při nabitých bateriích atd. Ale pro teď, pro ten pocit, že to nesvítí zbytečně, mi to stačí.
Miniserver
No a tím se dostáváme k miniserveru. Bohužel, toto jsou věci, co prostě v NodeRedu neudělám. Je to primárně to ovládání/propojení věcí, na které je Loxone super. Jenže, ukládání a restartování miniserveru po změně projektu na verzi v1 je čistý pain. Cca 3-5 minut na restart fakt nezvyšuje mou chuť něco vyvíjet. A tak jsem začal zjišťovat, zda fakt neudělat upgrade.
Zdá se, že miniserver compact by mi měl stačit. Nepotřebuju další vstupy/výstupy, navíc bych dostal jako bonus Tree i Air. Důležité je, zda už jde bez problémů propojit původní MS1 pod tento MS2 a využít ho na vstupy i KNX. To ještě musím dozjistit. No, a pak už zbývá jen cena. Uvidím, zda a za kolik se mi ho kde povede sehnat. Úplně levná sranda to není, ale když bych update udělal, mohl bych po letech přejít na novější verzi a zase více věcí dělat v LoxConfigu a v NodeRedu nechat jen ty složitější, uzavřené věci.
Tak dneska jsem si pro změnu hrál s propojením Home Assistant a NodeRed. Stále prozkoumávám, jak nejlépe to všechno spojit dohromady, a skoro mi začíná vycházet, že se bez NodeRedu neobejdu. Nevýhoda je, že to jsou zas 3 různé systémy, výhoda ale je, že je to s NodeRedem celé o dost snazší (a navíc rychlejší, protože to běží přes websocket).
Takže, aktuální vize je, že stejně jako mám v NodeRedu logiku na zigbee a iKamand, tak tam bude i hlavní logika na FVE. NodeRed si bude sosat data jak z HomeAssistantu, tak z Loxone, případně Loxone bude ty data do NodeRedu předávat on, to ještě doladím. Ale reálně v Loxone zůstane jen nějaká zobrazovací logika + přepínače/tlačítka, která ale budou spouštět věci v NodeRedu.
Je to trochu překombinované, ale pro mě jako vlastníka miniserveru v1 je to celé o dost rychlejší na práci i rozšiřování. Každá změna v LoxConfigu mi trvá v řádu minut, navíc nejde v LoxConfigu pořádně programovat, zatímco v NodeRedu si vyrobím logiku jakou potřebuju a změna trvá sekundu maximálně. Ale, nepředbíhejme, možná to ještě několikrát změním :).
NodeRed a HomeAssistant
Teď už k integraci. Do NodeRedu je potřeba doinstalovat node-red-contrib-home-assistant-websocket. Já jedu NodeRed přes docker, takže do DockerFile jsem si přidal RUN npm install node-red-contrib-home-assistant-websocket a hotovo. Jinde to bude potřeba řešit nějak přes addony v NodeRed UI zřejmě.
Po nainstalování a restartu NodeRedu uvidíte tyto prvky v levé liště. Je jich dost, sám v nich zatím lehce tápu, ale ty základní sem už pochopil :).
Prvotní propojení s HA je taky vcelku snadné, buď přes access token (long-lived access tokens), který vygenerujete v profilu uživatele:
a nebo pokud máte NodeRed přímo v Home Assistantu, tak je tam volba ”
Čtení hodnot z Home Assistantu
Čtení jde udělat dvěma způsoby. Jedno, kdy node red sám dotazuje HA v určitém intervalu a notifikuje hodnoty. Druhé, kdy se hodnota čte až když přijde vstupní signál.
Automatické čtení je realizováno pomocí “Events.: state” nodu:
zatímco čtení na základě eventy pomoci “current state”:
Nastavení obou je pak hodně podobné. Je potřeba node nějak pojmenovat (je fuk jak), vybrat připojený server, zadat entity ID (kterou zjístíme při kliknutí na entitu v HA a kliknutím na ozubené kolečko, viz minulý článek sekce “Bonusový krok, jak zjistit název ID stavu”).
Jako další pak jde zadat, zda má stav mít nějakou hodnotu, jak dlouho jí má mít, a v jakém formátu mají hodnoty z nodu vylézt. Výsledek pak je, že po načtení hodnoty vyleze z nodu něco jako:
{"_msgid":"8de529266cdb5849","payload":"1455","topic":"","data":{"entity_id":"sensor.solax_inverter_pv_power_total","state":"1455","attributes":{"state_class":"measurement","unit_of_measurement":"W","device_class":"power","icon":"mdi:solar-power-variant","friendly_name":"SolaX Inverter PV Power Total"},"context":{"id":"01KABAWW0DS8B1P1X0ACQY69H1","parent_id":null,"user_id":null},"last_changed":"2025-11-18T11:16:45.709Z","last_updated":"2025-11-18T11:16:45.709Z","timeSinceChangedMs":10125}}
kdy hlavní hodnota vyleze v “payload”, ale je tam připojeno i “data”, který obsahuje všechny ostatní informace, který HA vrátil.
Zápis hodnot do Home Assistantu
Zápis samotný mi dal zabrat trochu více, ale ve finále je to taky jednoduché. Jen člověk nesmí číst starší návody, kde se to jmenuje jinak :).
Zápis samotný se dělá pomocí univerzálního nodu “action” (takže až Vám budou návody říkat něco jiného, ignorujte je :)) :
V akci je potřeba opět zvolit název, server, a akci. Akce je, co se má v HA udělat. Může to být klik, může to byt togle, atd. je tam toho mraky. Abyste věděli, jakou akci volat, chce to se podívat zpět do HA a asi i trochu zkoušet. Já například chtěl nastavit % nabíjení baterie. Takže jsem šel opět do HA, do přehledu hodnot, klikl na danou hodnotu a otevřel nastavení:
tam, kde se dá zkopírovat ID entity je zároveň i prefix “number”. Opět, HA v tomto super, že má developer sekci, kde si to rovnou můžete nasimulovat. Otvírám tím pádem “Developer tools” a “Actions”. A stejně, jako když jsme testovali v minulém článku rest command, tentokrát otestujeme number.set_value.
V seznamu akcí vybírám number.set_value a do parametrů zadávám entity_id a value. V případě set_value jde navíc využít i UI režim, takže nemusíte skoro nic psát, jen si to tam naklikáte a pak se podíváte, jak YAML vypadá:
Po vyplnění stačí dát spustit akci a hned vidíte, zda se hodnota změnila či nikoli (pokud ne, zřejmě voláte jinou akci, kdy je tam například input_text.set_value, input_number.set_value` atd). Pokud se Vám hodnota úspěšně změnila, vracíme se do NodeRedu.
V prvku action tím pádem pokračujete vyplněním “action” jako number.set_value (nebo jakékoli jiné akce, kterou jste si vyzkoušeli, že Vám funguje). Jako další pak přidáte targets, kde si z dropdown prvku vyberete odpovídající propertu. v měm případě `number.solax_inverter_backup_nightcharge_upper_soc`.
A jako poslední zbývá zadat hodnotu, která se má poslat. Tady jsem se lehce zasekl, než jsem si všiml dole tlačítka “Load example data”.
Hodnota do “Data” se totiž nesmí zadat jako “30”, ale jako JSON objekt s propertou value a hodnotou “30”. Toto je lehce matoucí, ale když si člověk přečte spodní část obrazovky, kde je navíc tlačítko “Load example data”, které Vám to předvyplní, je to hotové raz dva.
Pak už jen stačí spustit akci a otestovat, že se Vám v Home Assistantu hodnota změnila.
Závěrem
Tak, tím pro dnes zas hotovo. Další způsob komunikace otestovaný. Zítra zkusím ve volné chvíli mrknout znovu na propojení Loxone a NodeRed. Kdysi jsem používal ten fajn addon na přímé propojení Loxonu a NodeRedu, ale blblo tam znovu-navázání spojení po výpadku. Tak mrknu, zda to tam náhodou už není doděláno, protože by to na toto bylo fajn.
Pak by byl Loxone opět jen v roli vizualizátora, NodeRed v roli logiky, a Home assistant jako gateway k zařízení. I když jsou to 3 různé systémy, ve finále to asi zas tak zlé nebude.
S nově nainstalovanou FVE u nás na domě vyvstal klasicky nový problém, jak dané zařízení co nejlépe připojit k Loxone :). A protože jsem líný mapovat celý Solax Modbas do Loxone ručně, nakonec jsem na to šel přes HomeAssistant, který už mapování má hotové. Samotné propojení se pak dá udělat pravděpodobně spousty způsoby, jak se například řeší i u nás na fóru (a protože ani pro NodeRed jsem to nenašel).
Bohužel pro mé účely PyLoxone zřejmě nejde použít, jelikož údajně potřebuje Miniserver V2. Stejně tak sem nakonec narazil na UDP propojení jako slepou větev, jelikož HA přímo UDP nepodporuje a volat linux příkaz pro každý cmd mi přišlo mimo. Nakonec jsem po několika různých pokusech-omylech došel k tomu, že nejsnazší to bude přes virtuální vstupy a HTTP requesty. HomeAssistant to bude volat přes RestAPI v okamžiku, kdy se daná hodnota změní.
Celý postup níže pro ty, kdo by to chtěli řešit touto cestou, stejně tak pro mé budoucí já, až se v tom jednou zas bude hrabat :). Celý návod je testovaný na starém Miniserveru V1 s LoxConfigem 8.3.3.21. Věřím, že přes PyLoxone to bude asi pohodlnější, ale na těch pár hodnot mi to teď stačí a do budoucna se pak uvidí.
Krok 1, virtuální vstupy
Na co jsem během testování přišel, že než používat klasické virtuální vstupy, které jsou po jednom v hlavní složce Virtual Inputs, jdou klidně použít například UDP vstupy, které se pěkně groupují do pod-složky a fungují přes HTTP Rest Api úplně stejně. Takže prvotní příprava vypadala takto:
Krok 2, instalace HomeAssistant
Tady musí každý podlé svého, zřejmě se to bude i místama trochu lišit, ale já jedu nakone HA v dockeru. Config mám pak vyndaný do permanentního storage v docker-compose.yml.
Dockerfile
Dockerfile pro container mám takto, přidávám si tam wget, a při startu loaduju docker-entrypoint.sh, který instaluje HACS
FROM ghcr.io/home-assistant/home-assistant:2025.11
COPY ./backup.sh /
# HACS install script uses bash + wget, make sure they exist
RUN apk add –no-cache bash wget
COPY docker-entrypoint.sh /docker-entrypoint.sh
RUN chmod +x /docker-entrypoint.sh
# Use our entrypoint wrapper, then hand off to the original /init
ENTRYPOINT [“/docker-entrypoint.sh”]
CMD []
docker-entrypoint.sh
V docker-entrypoint pak vytvářím custom_components a instaluju HACS, pokud není dostupný. Nechtěl sem to nechávat na ruční instalaci, protože čim více to udělá samo, tím méně problému při budoucím updatu 🙂
#!/usr/bin/env bash
set -e
# Ensure config dir exists (it will be your mounted volume)
mkdir -p /config/custom_components
if [ ! -d /config/custom_components/hacs ]; then
echo “HACS not found in /config/custom_components, installing…”
cd /config
wget -O – https://get.hacs.xyz | bash –
else
echo “HACS already present, skipping HACS download.”
fi
# Hand over to Home Assistant’s original entrypoint
exec /init
Home Assist instalace doplňků
Po rozjetí HA jsem pak už instaloval jen “Solax Inverter Modbus”, kterému jsem nastavil IP. Tím je defakto HomeAssist hotov. Osobně ho neplánuji více používat jako UI, jen takto jako podružný systém na vyčítání dat. Časem na něj možná zkusím přehodit i zigbee například.
Krok 3, rest_command nastavení v Home Assistant
Jako první krok je potřeba vyrobit rest_command, který pak využívají další kroky. Rest command může mít několik parametru, což je super, jelikož se tak dá vytvořit univerzální příkaz na nastavování hodnot virtuálních vstupů v Loxone. Do configuration.yaml v adresáři /config v HA přidejte sekci rest_command:
po přidání je potřeba provést restart HA, aby si tento command načetl.
Krok 3b, otestování rest commandu
Toto se mi na Ha líbilo, v sekci DeveloperTools->Actionssi můžete otestovat svůj nově vytvořený rest_command. Jako akci vyberete název commandu, v mém případě loxone_vi. Bohužel data nejdou zadat přes UI, ale v YAML je to snadné vyplnit. Takže přepnout do YAML módu a zadat například takto:
action je název akce, tzn rest_command.loxone_vi a do data pak vyplnit za co se má substituovat vi_name a vi_value. Pak už jen tlačítko provést akci a hodnota v Loxone by měla být změněna.
Krok 4, vytvoření automatizačního pravidla
V Settings->Automation&scenes->Automationsdáme vytvořit nové pravidlo. Vybrat Create new automation, tam pak nastavit pravidlo následovně:
Pro zadání triggeru vybrat “Entity” a pak “State”.
do entity pak název hodnoty, v mém případe solax_inverter_pv_power_total
Jako druhé je pak v automatizaci potřeba vyplnit Then do sekce, kde nastavíme, co se má stat. Dáme přidat akci, a v seznamu vyberemé námi vyrobeny loxone_vi rest command. Po jeho vybrání musíme opět pomocí tří teček zvolit YAML editaci
a do Action data vyplníme data podobně, jako jsme to udělali v testeru. Rozdíl je v tom, že nechceme posílat fixní hodnotu, ale dynamickou na základě vstupního stavu. Proto je zápis lehce komplikovanejší:
Tímto zajístíme, že do virtuálního vstupu pojmenovaného solax_inverter_house_load posíláme aktuální hodnotu z tohoto senzoru. Jakmile akci uložíme, začne HA při každé změně stavu volat REST command, který tuto hodnotu přenese do Loxone.
Solax rozšíření vyčítá data co každých 5 sekund, němelo by dojít ani k nějakému spamování loxone. Pokud by to i tak bylo moc rychlé, mělo byt o jít nastavit pomoci for v trigger nastavení (lze asi nastavit zase jen přes YAML):
trigger:
– platform: state
entity_id: sensor.solax_inverter_house_load
for: “00:00:05” # hodnota musí být stejná 5s, než se automat spustí
Bonusový krok, jak zjistit název ID stavu
Zjištění názvu této proměnné jde udělat tak, že v Overview na hlavní obrazovce kliknete na danou hodnotu, kterou byste chtěli přenášet, dáte nastavení vpravo nahoře, a pak vykopírujete entity ID:
Závěrem
To je pro dnes vše. Zatím mám propojené jen tyto dvě hodnoty. Pokračovat pak budu se směrem Loxone->HA, kde budu jednou za 3 týdny řešit plné nabití baterií. A další pak bude, až doinstalujeme elektropatronu do boileru a já začnu programovat spínání patrony, případně pak až začnu řešit i další spotřebiče v případě přebytku. Ale to bude reálně až na jaře / v létě, až začne svítit :).
Ahoj, tak dneska si dáme jeden gadget článek. Dorazila mi z Aliny další hračka, která je vlastně fakt jen pro radost, ale zato pro velkou radost :).
Jde o chytrý budík (dá li se tomu vlastně tak říkat), který jde flashnout lepším firmwarem a pak napojit na MQTT nebo REST API, takže pak ve finále z něj vlastně budík ani hodiny být nemusí :). Zařízení se jmenuje ULANZI TC001 a je fakt skvělé. Narozdíl od jeho dražšího (a zřejmě původně originálního) bráchy stojí jen 50usd (originál 200usd) a přitom podle mě funguje stejně skvěle (ale originál nemám, viděl jsem jen videa).
Zařízení se dodává s originálním čínským firmware, který sice také jde nějak někam napojit,ale cílová apka už není dále vyvíjená a jelikož je potřeba zařízení připojit do vlastní sítě, doporučuju raději flashnout pomocí open source firmwaru. Alternativní firmware se jmenuje AWTRIX 3, informace o něm najdete zde, a samotný flash pak probíhá plně automaticky z prostředí webové stránky pomocí připojeného USB kabelu do zařízení.
Po naflashování Vám zařízení ukáže svou IP adresu a vytvoří wifi síť. Na tu se připojíte, nastavíte wifi credentials do Vaší sítě a hotovo. Zbytek už budete konfigurovat v rámci vlastní sítě přímo na zařízení.
ULANZI TC001 má jednak 4 zabudované vlastní apky, a to čas, kalendář, teplotu a vlhkost, která se může střídat s Vašimi apkami, které mu nahrajete přes API, případně je můžete přes zařízení vypnout a nechat ukazovat jen Vaše data.
Možnosti jsou opravdu impozantní, jde se zařízením dělat spousta psích kusů. To hlavní je, že buď do zařízení nahrajete aplikaci pod nějakým jménem, pod kterým ji pak zas můžete odebrat, a nebo tam pošlete jen notifikaci, která se zobrazí jednorázově a pak zmizí. To se dělá pomocí příkazů /api/custom a /api/notify
Samotná zpráva pak může obsahovat (odhadem) tak 50 nastavitelných parametrů od barev, pozic, ikonek, progres barů, animaci, či třeba i vlastního kreslení po pixelu atd.
Na testování jsem zařízení narychlo propojil s NodeRED, kde jsem si udělal pár pokusů a rovnou začal sepisovat tento článek :). Proto jak vidíte je i samotný NodeRED dost ohavný, navíc v němčině, protože jsem si na první nastavení pomohl z repozitářů příkladů zde: https://flows.blueforcer.de/search?provider=node_red
Samotný kód není nijak složitý. Pomocí funkce se připraví datový balík a ten pak pomocí REST api odešle:
Takto můžete své drahé udělat na valentýna radost. To prostě musí ocenit :))).
A to je vše. Až bude o víkendu (nevím teda kterém) trochu víc času, pohraju si s tím víc. Pokud někoho zařízení zaujalo a budete kupovat, pošlete pak fotky co všechno na něm zobrazujete :).
Program je určen pro síťovou ETH (ethernet) verzi, pro kterou není potřeba dokupovat další RS232/RS485 extension (za další 4598 Kč), která je jinak vyžadována pro připojení Quida či jiného modulu přes klasický Modbus protokol.
Program funguje tak, že dekóduje UDP signály z Quida a nastavuje stav předdefinovaným značkám (v základu pojmenované jako Quido-1 až Quido-100). Ty pak můžete v Loxone configu použít jako klasické digitální vstupy Loxone.
Pro výstupy pak funguje tak, že přes vzorec se slučuje až 32 hodnot do vstupů programu, který poté zapíná/vypíná relátka.
Jak to celé funguje
V základním režimu funguje modul Quido s protokolem Modbus. Ten má ale svá omezení, a to především v rychosti a nutnosti dotazování místo notifikování (oznamování) změn. To pak zatěžuje Loxone miniserver a díky omezené rychlosti dotazování není schopen vždy správně vyhodnotit například stisknutí tlačítek.
Nabízený PicoC program pro Loxone tento problém řeší tak, že namísto dotazovacího Modbusu se využije notifikace změn vstupů pomocí UDP paketů a jejich následné dekódování na straně Loxone.
Z pohledu uživatele, tedy Vás, to znamená jen zakoupit Quido, nastavit správně Quido (viz návod níž) a do Loxone překopírovat bloky z dodaného Loxone souboru spolu s dodaným PicoC programem.
Jak získám přístup k nabízenému programu
Jelikož implementace mne stála nemálo času a nervů, rozhodl jsem se program nedat úplně zdarma. Cenu jsem nastavil tak, aby se Vám to ještě nevyplatilo lopotit se s tím sami a zároveň mně se vyplatilo tomu dělat stránky a nějakou podporu (o program se starám již více než čtyři roky a již čtyři roky průběžně vše aktualizuji tak, aby vše jelo jak na původním Miniserveru, tak novém).
Proto jsem cenu nastavil na 2000Kč. Za tuto cenu získáte přístup k této i všem budoucím verzím programu.
Částku lze zaplatit buď přes PayPal nebo převodem na účet. Před samotnou transakcí mne kontaktujte na email [email protected], kde se pak domluvíme na zaslání souborů a případně dalších technických detailech.
Stav implementace
Nabízený program je kompatabilní se všemi ethernetovými (síťovými) variantami Quida od firmy Papouch a podporuje jak původní tak nový Loxone Miniserver.
Můstek funguje na všech variantách Miniserveru (MS1,MS2,Mini,Go) a všech LoxConfig verzích od verze v8 po aktuální verzi v15.
Podporováno
podpora až 100 vstupového modulu
podpora modulu s až 32 výstupy
automatický refresh stavu vstupů pro případ ztráty paketu (konfigurovatelné)
v případě restartu Quida automatická obnova spojení i stavu vstupů
v případe restartu Loxone automatická obnova spojení i stavu vstupů
kontrola UDP paketů pomoci CRC součtů pro zamezení zpracování poškozených paketů z Quida vlivem chyb v síti
Omezení programu
nelze pracovat s hodnotou teploměru
V případě, že vlastníte starý miniserver (původní s KNX portem), je potřeba si pohlídat zátěž můstku. Bohužel díky nejnovejším aktualizacím se miniserver stále více a více zpomaluje. Zatímco ve verzi LoxConfigu v8 zvládal můstek až 100-200 signálů za sekundu, s poslední aktualizací již starý Miniserve zvládá jen 1-2 impulzy za sekundu. Z tohoto důvodu není doporučeno na Quido zavěšovat různé elektroměry a vodoměry, jelikož by mohlo dojít k přetížení miniserveru a jeho restartu. Toto omezení se netýká nového Miniservreu, který má zatím výkonu dostatek. Více info o této situaci zde https://www.vodnici.net/community/loxone-a-arduino/quido-a-novy-loxone-config
Záruka
Záruka je na funkčnost v době nákupu. Pokud se Vám můstek nepodaří rozchodit, tak Vám s tím pomohu.
Bohužel, ale není možné dát jakoukoli záruku na to, že bude můstek fungovat s další budoucí verzí. Loxone si může usmyslet cokoli a stejně jako ze dne na den striktně omezil Modbus (nastavil tvrdé limity na počet jeden příkaz za 5 sekund), teoreticky by mohl omezit i UDP (což by bylo asi už hodně za hranou, ale stát se může cokoli). Pokud chcete záruku, kupte si proto originální Loxone příslušenství. Řešením samozřejmě je rozchodit můstek a pak již nadále neupdatovat nové verze Loxone. Za ty roky co Loxone mám tak stejně mohu říct, že každá nová verze jen zpomaluje systém a přináší podporu pro jejich vlastní HW prvky, ale nějaké zlepšování LoxConfigu nebo základní funkcionality se moc neděje (pokud nepočítám z mého pohledu nepovedený přechod ze zeleného stylu na černé velké dlaždice).
Ohlášené a nevyřešené problémy programu
v současnosti nejsou známy žádné problémy
Návod
Pro rozchození komunikace je potřeba nastavit zvlášť modul Quido a zvlášť Loxone miniserver. Jako první nastavte například Quido, jako druhé Loxone (pořadí nehraje žádnou roli). Po nastavení obou zařízení začne komunikace okamžitě fungovat.
Návod nastavení Quida
Pro správné propojení Quida a Loxone je potřeba nastavit Quido modul do režimu UDP komunikace s fixní IP adresou.
IP adresa zařízení. Zde zadejte IP adresu pro modul Quido. Tuto adresu je pak potřeba nastavit do Loxone programu
Port, na kterém bude Quido naslouchat pro řídící UDP pakety, zde nastavte 10002
Režim Quida. Zde je potřeba nastavit UDP
IP adresa Loxone Vašeho miniserveru
UDP port, na kterém bude Loxone naslouchat. Nastavte 10001
Dejte uložit a vyčkejte na restart Quida
Návod pro nastavení Loxone
ze souboru Quido-loxone.loxone zkopírujte obsah záložky Quido do Vašeho programu
V případě, že máte zájem také o ovládání výstupu, zkopírujte z druhé záložky také bloky pro výstupy
ze souboru Quido-loxone.h zkopírujte obsah do komponenty “Program”.
Stejný program zkopírujte také do bloku program pro ovládání výstupů.
V obou programech upravte hodnotu konstant c_remote_listen_address abyobsahovala IP adresu a port Vašeho Quida tak, jak jste ji nastavili v bodě 1) a 5) v návodu “Jak nastavit Quido”
upravte hodnotu konstanty c_remote_write_address aby obsahovala Vaši IP adresu a port Vašeho Quida tak, jak jste ji nastavili v bodě 1) a 2) v návodu “Jak nastavit Quido”
V případě potřeby můžete změnit hodnotu c_auto_refresh_every_sec, která určuje, jak často se kontroluje stav Quido vstupů.
Dále můžete upravit hodnotu c_relay_check_period_msec, která určuje, jak často se kontrolují stavy vstupů
A jako poslední, pomocí konstanty quido_bridge_mode nastavte, jestli má program běžet v řežimu VSTUPŮ (hodnota 0) nebo VÝSTUPŮ (hodnota 1).
Uložte změny do Miniserveru Loxone a vyčkejte na restart.
Ukázky funkčnosti
Changelog (seznam změn)
Seznam změn a čísla verzí programu QuidoLoxoneBridge.
Ver
Popis změny
Change description
v19 (2020/09/23)
Pridan novy priznak c_enable_debug_log pro lespi debugovani problemu. Mustek pak do logu vypisuje vsechny stavy a prijata data.
New flag c_enable_debug_log for better debuging.
v19 (2020/09/23)
Pri spusteni quida se provede reset masky automatickeho posilani notifikaci. Namisto poheho nastaveni se vse nejprve vypne a az pak zapne.
Reset quido flags when initializing bridge.
v18 (2020/08/29)
Opravena maska vstupů pro Qudio 100/3 se starým firmware (nefungovaly vstupy 53-56).
Fixed bitmask for Quido 100/3 with old firmware (fix for inputs 53-56)
v17 (2020/03/23)
Přidán nový typ synchronizace výstupů pro pomalé miniserver verze 1 (znovuposílání nekompletních stavů).
New synchronization for slow miniservers v1 (resending of relay states)
v16 (2020/02/02)
Oprava padu miniserveru kvuli PicoC nekompatability v novem Miniserveru v2.
Fixed PicoC miniserver crashes because of new issues in PicoC in MS2
v15 (2019/06/27)
Fix bufferu pro prichozi data
v14 (2019/03/14)
Fix masky pro Quido 60/3, optimalizace pro Loxone, možnost vypnout CRC check
Fix for Quido 60/3 in notification mask, optimizations for Loxone, ability to turn CRC check off
v13 (2019/02/26)
Přidána podpora nového typu notifikační masky -1
Added support for notification mask -1
v12 (2018/11/22)
Přidána kontrola CR bytu na konci UDP a kontrola CRC celého paketu kvůli prevenci kolizím
Added check for ending CR byte and calculation of CRC checksum of whole packet
v11 (2018/10/30)
Upravena maska na registraci naslouchacího režimu. Pro 60/3 Quida hlásilo Quido chybu ack3 neplatná data.
Updated bit mask for registration to listening mode. 60/3 quido reports error ack3 error data
v10
Odstraňena kritická chyba v opravě spadlého spojení, která mohla způsobit 100% vytížení CPU
Critical bugfix in connector method. Sometime program can takes 100% cpu
v9
Odstraňeny debug hlášky aby neplnily zbytečně logy
Removed debug outputs to save log sizes
v8
Optimalizace(komprimace) velikosti programu
Optimization of program to reduce memory footprint
v7
Ovládání až 32 výstupů (relé)
Ability to control up to 32 outputs (relays)
v6
Automatická obnova vstupů každých x sekund
Automatic refresh of inputs every x seconds
v5
Rozšíření parseru aby zpracovával jen správné 0x0D události
State parser filtration to only 0x0D notifications
v4
Automatické nastavení Quida aby automaticky notifikoval všech 100 vstupů
Automatic initial setup of inputs to notify over UDP/TCP
v3
Rozšíření na práci se 100 vstupy
Ability to read all 100 inputs
v2
Základní funkce pro čtení stavu vstupu
Basic functions for reading state-change notifications
v1
Testovací verze
Initial test case
Mé články o Quidu
Tady je seznam článků, kde jsem popisoval jak Quida používám u sebe doma:
Tak jsem využil nakonec skoro celou neděli k tomu, abych pokračoval v akci světla. Po diskuzi se zkušenějšími Loxong guru jsem zjistil, že nový LoxConfig opravdu nabízí mnohem více v bloku ovládání osvětlení a umí přesně to, co se snažím udělat ručně v Loxone v8. Bohužel to ale jinak než ručně neudělám.
Ale nevadí, výzva je výzva a tak to dotáhnu. Nový MS2+KNX extension nyní nebudu kupovat, takže si musím poradit takto (a kvůli Quidu a elektroměrům nemohu provést update MS1 na poslední verzi).
Jen zopakuji to, co jsem již psal dříve – po celém domě předělávám osvětlení pomocí Zigbee světel tak, aby první tlačítko v každé místnosti fungovalo jako klasické hloupé – první klik zapne výchozí světlo, druhý klik vypne. Tlačítko vedle něj pak prvním klikem zapne tlumený režim a dále pak už rotuje scény, vypínání se dělá opět tlačítkem jedna. Tedy, když přijde kdokoli neznalý chytrého domu, bude na nic nepřijde a všechno bude fungovat intuitivně.
Po prvních problémech jsem nakonec vše vyřešil pomocí bloku RadioButton. Důvod, proč jsem zvolil RadioButton místo bloku ovládání osvětlení, je ten, že RadioButton reaguje již na vzestupnou hranu signálu, takže pocitově je rozsvícení světla v místnosti rychlejší, než když se rozsvítí až po uvolnění tlačítka.
Celou výše uvedenou logiku jsem pak dal dohromady tak, že na výstupu AQ z RadioButtonu pomocí zpoždění přenáším výstup zpět na vstup, kde ho pomocí AND/NOT prvků porovnávám a dle výstupu provádím buď zhasnutí nebo rozsvícení.
Abych vyřešil případné příliš dlouhé držení tlačítka, používám na vstupu ještě Monoflop, který mi udělá přesně definovaný signál bez ohledu na délku držení.
Třeba se to bude hodit někomu, kdo má také v8 a chtěl by něco podobného řešit.
Jako další výzva pak bylo přenést několik různých scén do Zigbee. Tady bych si zase rád poslechl, jak to řešíte ostatní. Já jsem to udělal pomocí NodeRED následovně:
Pomocí výstupu AZ vyčítám z RadioButtonu aktuálně zvolený výstup, který pak přenáším do prvku “Stav”. V prvku Stav pak pomocí jednoduché porovnávací tabulky převádím jednotlivé stavy na příkaz, který ukládám do “Text status”.
Příkaz má jednoduchou formu “Cílové světlo/Cílová světla oddělená čárkou” | “color_temp”/”color_xy” | brightness. Hodnoty vycházejí z hodnot podporovaných Zigbee2Mqtt.
Tyto hodnoty pak dále parsuji a zpracovávám už v NodeRED. Toto řešení jsem zvolil nakonec proto, že mi umožňuje přímo v LoxConfigu editovat různé profily, přidávat další profily, upravovat jas a celé nastavení je tak pohromadě. A až samotné zpracování je mimo.
Původně jsem zkoušel to řešit třeba přes značky nebo načítat přímo hodnotu RadioButtonu do NodeRED, ale vadilo mi, že logika nebyla uceleně na jednom místě.
Jediný rozdíl je v přidané funkci “TransformLightCommands”, která bere obsah příkazu z volání z Loxone a překlápí ho na msg zprávu, kterou již podporuje můj stávající NodeRED systém, tzn. takový, který to pak pošle přes MQTT do Zigbee2Mqtt.
Jediné, co mi na tom ještě trochu nevyhovuje, je nutnost přidat pro každý status prvek samostatný Loxone-control-in prvek. Ale tomu se bohužel nijak nevyhnu. Aspoň je to zase přehledné, odkud všude se hodnoty vyčítají.
Zatím mám na tento systém překlopenou cca polovinu domu a vše vypadá, že funguje jak má. Budu to teď přes týden testovat a sledovat a pokud se to osvědčí, příští víkend překlopím zbytek.
Celý zdrojový kód k překladu Loxone příkazů do Zigbee2Mqtt formátu je k dispozici pro podporovatele blogu zde. Jak jsem avizoval v předchozím článku, kompletní kódy budou nově dostupné jako benefity pro podporovatele blogu.
Zatím je tam jen JavaScriptový kód na převod, ale pokud by byl zájem, přidám i celý NodeRED projekt na propojení Loxone-Zigbee2Mqtt do této sekce.
A to je pro dnes vše. Až bude zase chvilka, tak dám dohromady ještě článek o světlech samotných, protože se mi už množí dotazy, jaká světla s podporou Zigbee jsme vybrali.
Edit: Vytvořil jsem konečně článek, kde je nasdílený komplet projekt na ovládání Zigbee z Loxone, jak vstupy, tak výstupy. Nejen světla, ale i chytré zasuvky a integrace Ikea Round buttonu. Článek je dostupný pro všechny, kteří nějakým způsobem podpořili náš web.
Pokud někdo posílal nějaký donate a nejede mu to, napište mi prosím na [email protected], pošlete info kdy/jak jste posílali nějaký donate a já Vám oprávnění nastvím.
Ještě jsem to zatím nepsal, ale přes zimu jsem konečně dořešil veškerá světla v domě. Dlouhé roky odkládání a nechuti to řešit jsem nakonec hecl, a udělal vše najednou. Hlavní důvod, proč se mi to nechtělo řešit a na čem se to vždy zaseklo byla svítivost. Aby to nesvítilo ani málo ani moc, aby to mělo správný odstín atd. A tak jsem to nakonec vyřešil tak, že jsem všude koupil Zigbee regulovatelná světla, která jsou buď plno barevná, nebo alespoň regulace jasu a bílé.
Světla jsou namontovaná a tak přichází ta na řadu SW část. A tady momentálně trochu klopýtám, a tak jsme si říkal, že z toho udělám postupně sérii článků na téma “Jaké všechny způsoby jsou a co z toho nakonec vyleze :)”.
Můj momentální use-case, který se na světla snažím napojit je, že každá místnost bude mít většinou 3 režimy. Plné svícení žlutou barvou na běžné používání, plné svícení bílou barvou když je potřeba extra světlo, a tlumené noční svícení žlutou barvou na noc. A ovládat tuto kombinaci chci ideálně dvěma tlačítky na zdi, s tím že nechci žádné multi-kliky a jiná zvěrstva, která Loxone nabízí.
Moje vize je, že první, hlavní a podsvícené tlačítko v místnosti rozsvítí vždy výchozí režim a druhý klik vždy zhasne. Zatímco druhé tlačítko bude sloužit v prvním kliku k rozsvícení nočního režimu, druhým klikem k přepnutí na bílý, třetí pak klidně na žlutý a čtvrtý na vypnuto například (to mi je celkem jedno). Ale důležité je, aby první tlačítko vždy zhaslo světla, pokud svítí jakýkoli režim. A tady je s Loxone problém (alespoň v mé v8 verzi, ale dle dokumentace se to asi ani v dalších verzích nezměnilo).
Co bych potřeboval, aby (+) vstup fungoval tak jak funguje, ale S2 vstup měl možnost zadat, že když je režim 0, tak zapni režim S2, ale když svítí jakýkoli režim, tak S2 přepne světlo do režimu 0, tzn. ho vypne. A to samozřejmě nejde. A tak jsem začal vymýšlet.
První, vcelku logická úvaha byla, vyčítat výstup AQs a když je výstup 0, tak pošli signál na S2 a když je nenulový, pošli na vstup R.
Tzn. něco takového. Jenže, toto nefunguje. Problém je, že zatímco S2 vstup se spíná až se sestupnou hranou, tak R se spíná se vzestupnou hranou. Takže v okamžiku, kdy člověk namáčkne tlačítko, tak v případě rozsvíceného režimu správně uvede prvek Ovládání osvětlení do vypnutého stavu, jenže při uvolnění kliku ho pak rovnou i zpátky zapne. Jen proto, že se S2 chová jinak než R a nelze to nastavit (v mé v8 verzi, nevím jak dále, klidně piště, jestli už je to někde fixnuto). Další problém jsou pak nevzhledné čáry v diagramu, kdy s nimi nelze jakkoli hýbat, ale to už je možná v dalších verzích opraveno, to jsem nezkoušel.
Každopádně zpět k problému. Jednoduchým řešením tohoto problému by bylo mít buď možnost přepnout Sx nebo R, aby fungovaly nastejno. To jsem nikde nenašel, že by šlo. Druhým řešením by byl prvek, který by konvertoval vzestupnou hranu na vzestupnou, tzn. něco, co by vyslalo impulz poté, co je vstupní impulz ukončen. Bohužel, to se mi rovněž nepovedlo najít, ačkoli mi to připadá jako běžný usecase a možná jsme něco přehlédl (a proto sem i psal post na fórum, ale zatím bez odpovědi).
A tak jsem došel k tomuto řešení. Vychází z předchozí úvahy, jen řeší problém přenesení již změněného stavu znovu na začátek tím, že do cesty vkládá ještě prvek “zpoždění vstupu a výstupu”, takže poté, co člověk přepne, tak ještě 1-2s je na výstupu původní stav, takže to během kliku nezpůsobí vypnutí a zapnutí zároveň. Nevýhoda tohoto řešení je, že pokud člověk podrží tlačítko déle než nastavené zpoždění, tak se cyklus opět provede, a naopak pokud klikne na tlačítko 2x za sebou rychleji než je teoo zpoždění, tak se nic nestane. Tzn nelze rozsvítit a hned zhasnout.
Oba případy sice nejsou nic častého, ale není to zrovna elegantní řešení. Navíc to znamená mít v každé místnosti toto diagramové monstrum, což se mi taky ještě úplně moc nepozdává. Bohužel, zatím sem na nic lepšího nepřišel. Teoretické možnosti jsou buď napsat si logiku bokem v NodeRED, ale to moc nechci. Toto mi přijde, že by mělo byt komplet na straně Loxone.
A tím pro dnešek skončím. Pokud jste něco podobného řešili, ať už způsob ovládání více režimů nějak více tlačítky, nebo problém s ovládáním osvětlení, dejte prosím vědět. Stejně tak, pokud novější verze LoxConfigu něco z toho nějak řeší lépe. Sám pak dám v dalším článku vědět, jak jsem to vyřešil, stejně tak bude ještě článek o tom, jak jsem nakonec vymyslel přenos režimů z Ovládání osvětlení do NodeRED a Zigbee. To má asi taky mraky různých řešení, tak mě bude zajímat, jak jste to řešili ostatní :).
