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 🙂
Pokud někdo vyčkáváte nebo zvažujete upgrade domácího Unifi, tak mám pro Vás dobrou zprávu. Unifi má black friday a na některých věcech je to docela povedené. Sám jsem na to čekal už pár měsíců, jelikož plánuji svůj starý USG vyměnit za Cloud Gateway Max (kvůli rychlosti, kvůli VPN, kvůli kamerám, ….)
A dnes jsem se dočkal. Na Unifi.eu běží black friday se vším všudy. Například Cloud Gateway Max bez disku zlevněný ze 185eur na 145eur, s 512GB pak z 259eur na 160eur!.
Mají v akci i DreamRouter, některé AC Pro talíře a další. Tak mrknětě, třeba se Vám to bude taky hodit.
PS2: Bohužel kamery mají v akci jen G5 Pro a AI Pro, stejně tak PoE switch mají jen nějaký enterprise. Takže ty zkusím “uloupit” ve slevě zas jinde :).
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 :).
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í :).
Dnešní článek přímo navazuje na minulý článek o ergonomii práce na počítači. Jak jsem už nakousl, ergo klávesnice a myš je jen část toho, co jsem si kvůli bolestem rukou vyrobil. To hlavní Vám chci ukázat dnes.
To, co vidíte vlevo vedle klávesnice, sice vypadá jako numerická klávesnice, ale není to tak :). Je to kouzelná klávesnice :)).
To, o čem dnes chci psát, je způsob, jak z jakékoli další klávesnice (numerické, klasické, gaming,….) udělat speciální ovládací “pult” s naprosto odlišnými akcemi, než jaké klávesy mají dělat. Zní to složitě? Trochu. Pojďme postupně.
Když jsem řešil ergonomii, tak zatímco pravou ruku jsem vyřešil vertikální myší, levá ruka toho při programování (a především pak ladění programů) má spoustu na starosti a bohužel řada z těchto akcí se dělá šílenými kombinacemi, které je ale většinou lepší udělat jednou rukou, než neustále přendávat pravou ruku mezi myší a klávesnicí. A tak levá ruka běžně mačká všechny různé ctrl+shift+xx nebo ctrl+alt+xxx a u toho jí všelijak lámu. A to není dobře :).
První nápad, jak jsem chtěl toto vyřešit, byla koupě nějaké externí mapovatelné kávesnice, kde si budu moct na jednotlivé tlačítka namapovat makra či akce stejně jako u myši. Jenže, toto zní snadněji než to v reálu je. Různé speciální tlačítkové panely, které toto umožňují, jsou většinou za nehorázné peníze a nabízí jen pár kláves. Například tento pěkný StreamDeck vyjde v alze na 4000kč. To je na můj vkus trochu dost :).
Jako další jsem se dostal k externím single-hand gaming klávesnicím. Po projití docela dost z nich jsem došel k závěru, že vlastně jediná rozumná je Razor Tartarus, která umožnuje mapování všech tlačítek na libovolné akce. Jenže cena u nás 3000kč. Sice lepší poměr cena ku počtu tlačítek, ale pořád nic moc.
A tak jsem se dostal k Aliexpressu. Takových klávesnic tam je plný vagón, jenže, mají jednu drobnou odlišnost. Ony už nejsou plně mapovatelné, ale jsou to obyčejné uřízlé půlklávesnice, kde jsou klasická písmena ASDF. Jenže taková klávesnice pak naopak stoji jen $13 místo $150. Ale pro mé účely se úplně nehodila. A tak jsem hledal dál.
Obrázek z fóra hidmacros
Až jsem narazil na fórum HidMacros, kde byl podobný obrázek. Když se podíváte pořádně, uvidíte vlevo a vpravo klasické klávesnice, kdy každá dělá něco jiného. Hmm, tell me more. A tím sem zjistil, jakým směrem dál ubírat mé hledání. Nejde totiž o to, najít klávesnici, co umí vše, ale najít rozumnou klávesnici za rozumné peníze a celou si ji přeprogramovat.
A tím se dostáváme k aplikaci LuaMacros, což je vlastně HidMacros V2. Stojí za ním nějajký čech (nemáme ho třeba i mezi sebou zde? :)), který vyrobil aplikaci umožnující nejen namapovat různé akce na klávesy, ale co je důležitější, umí rozlišit klávesu a usb zařízení, na kterém byla tato klávesa stisknuta. To znamená, že můžete mít klidně 5 různých klávesnic, a vy jste schopni přesně určit, na které klávesnici byl stisk písmene proveden. Famózní.
A tak jsem šel testovat. První, co zjistíte, je že HidMacros aplikace již není podporovaná. To je ze začátku určitě škoda, protože ta měla údajně i GUI, kde si člověk mohl klávesy snadno namapovat. Nevýhoda naopak byla, že uměla jen základní funkce. Autor se pak rozhodl aplikaci předělat a zmodernizovat, ale protože (jeho slovy) nemá rád vývoj GUI a pro své potřeby ho nepotřebuje, rozhodl se celou aplikaci udělat jako skriptovací engine. To znamená, že v nové LuaMacros Vás nepřivítají žádné obrazovky, žádné návody nic, ale jen prázdné scriptovací okno pro Lua script.
Když si otevřete github stránku s projektem, jako první Vás uvítá varování o tom, abyste aplikaci nepoužívali :). To mne pobavilo :). Naprosto ale chápu, proč tam to varování je. Rozchodit appku není úplně snadné a naprosto rozumím autorovi, že dělat zdarma support tisícům lidí, kteří pak neumí ani zmáčknout tlačítko Donate, je složité. Stačí ale investovat trochu času a trochu hledat a po chvilce už budete umět vyrábět vlastní scripty.
Abych Vám s tím trochu pomohl, ukážu Vám zde pár příkladů jak script napsat a jak to mám nastaveno já. Toto jsou tři nejdůležitější linky, které budete potřebovat :
Program není zas tak složitý, ale pojdmě si ho trochu okomentovat. Jako první musíte pojmenovat danou klávesnici nějakým názvem. Nejprve potřebujete zjistit identifikátor dané klávesnice. Na to je funkce lmc_assign_keyboard(‘MACROS’); a lmc_print_devices();
První příkaz Vám v aplikaci ukáže okno, které Vás vyzve ke stisku klávesy na dané klávesnici, druhý příkaz pak vypíše všechny zařízení i s jeho přiřazeným identifikátorem “MACROS”.
Nyní už víte, že Vaše klávesnice má kód 2EFD0B1A a proto použijete příkaz lmc_device_set_name(‘MACROS’, ‘2EFD0B1A ‘).. (toto ID najdete v řetězci cca v první třetině za PID_xxx&MI_xxx&;).
Toto byla defakto ta nesložitější část. Nyní si už jen namapujete akce na klávesy. Jelikož jde o scriptovací jazyk, můžete udělat cokoli. Jednoduchý příklad namapování je například tento:
-- assign logical name to macro keyboard
lmc_assign_keyboard('MACROS');
-- define callback for whole device
lmc_set_handler('MACROS',function(button, direction)
if (direction == 1) then return end -- ignore down
if (button == string.byte('C')) then lmc_spawn("calc")
elseif (button == string.byte('N')) then lmc_spawn("notepad", "C:\\test.txt")
elseif (button == string.byte('H')) then lmc_send_keys('Hello world')
else print('Not yet assigned: ' .. button)
end
end)
Tento script Vám namapuje klávesy C, N a H na spuštění kalkulačky, poznámkového bloku a H na napsání “Hello world”. Jak vidíte, v této podobě zatím script nijak nerozlišuje, která aplikace je aktuálně spuštěná a obsluhuje klávesy vždy stejně. Na to je pak potřeba script rozšířit například o detekci názvu aktuálního okna či jinak zjistit, jaká aplikace zrovna běží. I toto všechno lze udělat a pokud budete na fóru hledat, jsou na to ukázky. Já sám zatím toto rozběhané nemám, jelikož používám zkratky jen ve Visual Studiu, takže je mi jedno, co to dělá v ostatních aplikacích.
Další script je pak mé mapovací schéma pro Visual Studio namapované na numeriku. Význam jednotlivých zkratek najdete v dokumentaci, jak vidíte, mapuji hlavně různé Shift+F10, CTRL+SHIFT+F10 a podobně.
lmc_device_set_name('MACROS', '1B07498')
-- define callback for whole device
lmc_set_handler('MACROS',function(button, direction)
if (direction == 1) then return end -- ignore down
if (button == 103 or button == 36) then lmc_send_keys('+{F11}') --7
elseif (button == 104 or button == 38) then lmc_send_keys('{F10}') --8
elseif (button == 105 or button == 33) then lmc_send_keys('{F11}')--9
elseif (button == 111) then lmc_send_keys('{F5}') -- /
elseif (button == 106) then lmc_send_keys('{F9}') -- *
elseif (button == 109) then lmc_send_keys('^<{F10}') -- -
elseif (button == 107) then lmc_send_keys('^<+<{F10}') -- -
elseif (button == 100 or button == 37) then lmc_send_keys('%<o') --4
elseif (button == 101 or button == 40) then lmc_send_keys('%g') --5
elseif (button == 102 or button == 39) then lmc_send_keys('%t%t') --6
elseif (button == 110) then lmc_send_keys('%<{TAB}') --.
elseif (button == 98 or button == 144) then lmc_send_keys('%<t%<p') --2
elseif (button == 99 or button == 144) then lmc_send_keys('%<t%<n') --3
elseif (button == 144 or button == 96) then lmc_send_keys('%<{TAB}') --0
elseif (button == 13) then lmc_send_keys('{ENTER}') --Enter
elseif (button == 8) then lmc_send_keys('{BACKSPACE}') --BACKSPACE
else print('Not yet assigned: ' .. button)
end
end)
Poslední věc, která by stála za zmínku, je způsob, jak mapovat různé klávesy pro různé aplikace. Jak jsem říkal, sám to ještě nepoužívám. Ale když jsem si s LuaMacros hrál, tak jsem i toto testoval. Toto je zhruba způsob, jak můžete okna od sebe odlišit pomocí titulku okna:
function string.starts(String,Start)
return string.sub(String,1,string.len(Start))==Start
end
-- define callback for whole device
lmc_set_handler('MACROS',function(button, direction)
windowTitle=lmc_get_window_title()
print(windowTitle)
if string.starts(tt,"LuaMacros") then
...
end
end
Tenkrát se mi nepovedlo najít, jestli lze přes script nějak vyčíst také window class, nejen window title. Ale protože jsem to extra nepotřeboval, tak jsem se s tím nezdržoval.
A nyní zpět ke klávesnicím. Jelikož už víme, že lze použít jakoukoli, objednal jsem z Aliexpresu na zkoušku jednak tuto druhou numeriku a pak nahoře ukázanou červeno-černou gaming klávesnici. Zatím mi dorazila jen ta bezdrátová numerická a ta určitě není špatná. Jsou na ni super ty druhé šipky, takže se lze pohybovat v kódu i levou rukou. S větším testem chci ale počkat i na tu gaming klávesnici, abych to otestoval celé najednou.
Co se samotného use-case týká, tak díky této klávesnici je pro mne práce ve Visual Studiu o dost pohodlnější. Co šlo jsem si namapoval na jednotlivé klávesy, takže nyní například celý debugging dělám jen skrz tuto klávesnici. Takže za sebe určitě doporučuji. Chce to ale věnovat tomu čas. Jednak na pochopení celého scriptovacího systému, dále pak hlavně na vymyšlení a zvyknutí si na novou klávesnici a nové rozmístění zkratek. Osobně jsem několikrát celé schéma předělával a stále ho ještě ladím. Investovaný čas se ale rozhodně vyplatí.
Další ukázka úpravy klávesnice z fóra HidMacros
Co se týká využití, tak nemusí jít nutně jen o mnou zmiňované Visual Studio, můžete si takto namapovat jakoukoli jinou aplikaci, kde potřebujete hromadu zkratek (například Photoshop, Ilustrator či cokoli jiného), stejně tak lze použít právě třeba na hry, kdy zde to autor používá na FlightSimulator. K tomu si pak pěkně polepit tlačítka konkrétníma akcemi a klávesnice je naprosto dokonalá :).
Dnešní článek bude jen taková rychlovka na zamyšlení. Díky všem pokusům, co s NodeRED poslední dobou dělam, jsem se rozhodl vytvořit si dvě různé instance NodeRED.
Jedna je produkční, kde bude jen ostrý kód, který běží nonstop. Druhá pak bude developerská, kde budu testovat vše možné a kde bude v záložkách zůstávat i testovací bordel.
Díky docker-compose to není žádný problém. Každá instance používá svoje vlastní úložiště, zbytek mají obě instance naprosto totožné. Pro vývoj nových věcí tak používám developerskou instanci a pak pomocí import-export výsledek přenesu do produkční instance.
Můj aktuální kód pro NodeRED vypadá následovně:
FROM nodered/node-red
RUN npm install bufferutil
RUN npm install utf-8-validate
RUN npm install node-red-node-smooth
RUN npm install node-red-dashboard
RUN npm install node-red-node-ui-list
RUN npm install node-red-contrib-zigbee2mqtt
RUN npm install node-red-contrib-loxone
RUN npm install node-red-contrib-tgr-jsonata
RUN npm install node-red-contrib-xiaomi-sensors
RUN npm audit fix
A to je pro dnešek vše. Přišlo mi to jako dobrý nápad a třeba to inspiruje i někoho dalšího. Příště pak mám v plánu pár ukázek napárování zigbee na Loxone, konkrétně Ikea pětitlačítko, které se mi zatím hodně líbí. Mám na něm v pracovně světla, žaluzie i plachtu pergoly. Dál pak Sonoff tlačítka a chytré zásuvky.
Tak jsem tu zas s dalším Zigbee článkem. Opět navazuje na mé předchozí trable s NodeRED. Dneska to bude o něco méně problémů, ale přeci jen tam jedna drobnost je :).
Dnešním pluginem, který bych chtěl představit, je node-red-contrib-loxone. Ten umožnuje napojení se na Loxone skrz Websocket přímo z NodeRED, takže není potřeba vytvářet žádné virtuální vstupy, složitě posílat UDP a nějak to na straně Loxone parsovat.
Plugin je postaven nad komponentou node-lox-ws-api od Alladdina, který se občas vyskytuje i tady u nás na fóru.
Co se týká funčnosti, komponenty fungují parádně. Umí ovládat v Loxone cokoli, co má svůj viditelný Uuid směrem do vizualizace (webové rozhraní či app). Pokud tedy chci cokoli ovládat, připravím si na to třeba tlačítko a na to se pak napojím z NodeRED.
Plugin opět umožnuje pomocí comboboxů snadný výběr prvků z Loxone, takže není potřeba někde lovit Uuidy prvků, ale jednoduše si člověk pomocí výběru místnost-kategorie-prvek může zvolit přesně co potřebuje.
Drobná nevýhoda je, že do prvku pak člověk musí poslat přesně data, která Loxone očekává. Není zde žádná mezivrstva, která by to udělala za Vás. To je ale pochopitelné, protože těch typů prvků je hromada a musel by zde Alladdin či Zigbee2Mqtt udržovat obrovský seznam všech příkazů. Je proto o dost snazší podívat se do dokumentace pro Websocket API a poslat správný příkaz přes msg.payload.
Jediné, co mi zlobí, tak jakmile je nakonfigurován Loxone miniserver pomocí tohoto pluginu, tak deploy projektu občas trvá i pár sekund. Netuším, jestli je chyba někde na straně Alladdina nebo tvůrce NodeRED pluginu, ale do logu to háže chybu “Close time out”. Jako kdyby se to při deploy nejprve snažilo ukončit spojení s Loxone, což se ale nepodaří do daného časového limitu.
Řešení zatím neznám, ale není to nic, co by bránilo používání. Jen holt občas deploy trvá cca 3-5sekund namísto pár milisekund.
Tak jsem tu s dalším článkem z mé Zigbee minisérie (i když jestli to půjde jako do teď, tak to bude větší série 🙂 ). V minulém článku jsem popisoval problém se Zigbee2MQTT díky staré verzi NodeREDu, dnes se podíváme na další komplikaci v Zigbee2MQTT.
Zigbee2MQTT podruhé
U Zigbee2MQTT ještě zůstaneme. Tentokrát ale (nakonec) ne u pluginu, ale u SW brány samotné. Dalším problémem, který se mi děl a který byl hodně špatný, bylo chybné opakování poslední zprávy při deploy projektu.
V praxi se to chovalo tak, že jsem stiskl zigbee tlačítko, to poslalo MQTT zprávu a provedlo například “toggle” příkaz na světle. Tzn. přehodilo stav ze zaplého do vyplého či naopak.
Problém ale nastal, když jsem udělal změnu v projektu a dal deploy. Po naběhnutí celého projektu se tento “toggle” (a i všechny ostatní) provedly znovu. To znamenalo, že se mi náhodně zapínaly a vypínaly světla či chytré zásuvky. Nic moc.
Původně jsem podezříval opět plugin Zigbee2Mqtt, jenže stejná chyba se děla i při použití základního MQTT prvku. Problém byl tudíž někde v MQTT samotném, případně v Zigbee2MQTT.
MQTT jako takové má vlastnost, že u každé zprávy lze zadat “retain” příznak. Zpráva s tímto příznakem se nejen pošle všem příjemcům v době zaslání, ale zároveň se její stav uchová a pošle se i všem novým posluchačům.
Vše tudíž vypadalo, že by to mohlo být ono. Ale proč se to děje. Podle dokumentace Zigbee2MQTT mají zprávy “retain” defaultně vypnutý (link zde) a v NodeREDu tento příznak taky nikde nenastavuji. Takže, WTF :).
Na pomoc jsem si tedy vzal MQTT Explorer, který je super věc na debugování podobných problémů. Lze realtime sledovat veškeré zprávy i jejich poslední stav. A v případě, kdy má zpráva příznak “Retain”, je tam zobrazen následovně:
No, a co byste řekli. Měl ho tam :). Takže někdo nějak posílal RETAINED zprávy, které zůstávaly viset v MQTT frontě a při restartu NodeRED programu se pak vždy vyhodnotily znovu.
Podobné chování se hodí například u okenních senzorů, či jiných prvků, kdy i po restartu potřebujete v NodeREDu nastavit poslední známý stav. Je to ale dost na h*** u tlačítek, kdy Vám to probliká celým domem :).
Nakonec se ukázalo, že chyba je v samotné Zigbee2MQTT konfiguraci. Z nějakého mně zatím nepochopitelného důvodu se všem nově napárovaným zařízením automaticky nastavuje i retain:true, příznak, ačkoli o tom dokumentace mlčí (NodeRED UI administrace toto nejde nastavit ani se nijak neukazuje). To bohužel pak zůsobuje výše popsané problémy, které mohou být pro spoustu uživatelů asi dost deprimující 🙂
Řešením tudíž je odmazat retain:true příznak z konfiguračního souboru configuration.yaml pro všechna zařízení, kde toto chování nedává smysl (defakto všude krom teploměrů a čidel).
Po odmazání je potřeba restartnout Zigbee2MQTT kontejner či službu, aby se nastavení znovu načetlo. Tím je problém vyřešen a už žádné samozapínání při restartu.
