Browsed by
Tag: virtualni vstupy

Instalace a propojení HomeAssistant a Loxone

Instalace a propojení HomeAssistant a Loxone

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:

rest_command:
loxone_vi:
url: “http://admin:[email protected]/dev/sps/io/{{ vi_name }}/{{ vi_value }}”
method: GET

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

vi_name: solax_inverter_house_load
vi_value: “{{ states(‘sensor.solax_inverter_house_load’) }}”

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

 

Migrace NodeRED z node-red-contrib-loxone na UDP/HTTP vstupy/výstupy

Migrace NodeRED z node-red-contrib-loxone na UDP/HTTP vstupy/výstupy

Tohle bude trochu víc technický článek a hodim si ho sem hlavně i pro sebe, abych po čase zas věděl, jak mám ty vstupy a výstupy konfigurovat :). Už tentokrát mi dost pomohl tento můj historický článek, kde sem podobný problém jednou řešil.

Důvod celé migrace byl, že tento na první pohled skvělý plugin se občas odpojil od Loxone a už se nedokázal sám připojit zpět. Většinou se odpojil v situaci, kdy se Loxone svévolně zrestartoval a nebo když jsem dělal nějaké změny a vícekrát za sebou do něj nahrával nový LoxConfig. Bohužel, komponenta nejen že se neumí nějak snadno sama připojit, ale nemá ani žádný vstup/příkaz na to, aby se reconnect dal ručně vyvolat. Zkoušel jsem bug párkrát reportovat na githubu, ale bohužel marně. Poslední verze je rok a půl stará, takže to vypadá, že je možná plugin i lehce opuštěný.

Jediné řešení vždy bylo připojit se do NodeREDu, pohnout nějakým prvkem a dát znovu deployment. V tu chvíli se prvek krásně znovu připojil. Drobnost, ale vysvětlovat ženě, jak se má připojit k NodeRED, nebo večer před koupáním vždy běžet k počítači, protože nefungují světla nebylo úplně to pravé ořechové.

A tak i díky podnětům z komentářů pod minulým článkům jsem to hecl a rozhodl se včera zkusit pár zásuvek/světel předělat na UDP/HTTP vstupy/výstupy. Celý proces by trval určitě o dost kratší dobu, kdyby můj MS1 nedělal upload každého LoxConfigu cca minutu a hlavně, kdyby LoxConfig měl pořádně zdokumentované parametry vstupů + k nim měl nějaký debugging. Ale to už jsou spíš mokré sny 🙂

A tak pro sebe i ostatní sem nahážu pár ukázek, jak UDP/HTTP vstupy natavit na straně Loxone i NodeRED, ať to příště už nemusím zas složitě dohledávat. Pojďme na to:

Loxone Virtual UDP input / Virtuální UDP vstupy

Vytvořit Virtuální UDP vstup, nastavit mu unikátní UDP port:

Do něj pak vložit Virtual UDP input command, nastavit “Command recognition”. Pro On/Off jen samotnou hodnotu:

V případě potřeby načítat hodnotu, vložit do recognition \v pro “value”. (tady je to chyták, u vstupů se používá \v zatímco u výstupů <v>).

Loxone Virtual UDP/HTTP output / Virtuální UDP/HTTP výstupy

Vytvořit Virtual Output. V případě HTTP NESMÍ být v adrese celá cesta, ale vždy jen název serveru. Koumáci z Loxone to sice pojmenovali address, ale není to tak. Pokud je tam pak jakákoli URI, loxone dle logů padá na tom, že ji neumí přes DNS přeložit.

Do něj vložit Virtual output command. Pro on/off vyplnit Command for ON, Command for OFF (to je v případě HTTP URL za doménou zadanou v Address)

HTTP extensions je opět blbě pojmenované, jde o HTTP headers, které se mají vložit k požadavku. HTTP post command zvládli v Loxone pojmenovat správně a HTTP method také. V případě, že chceme zasílat při zapnutí i vypnutí různé data, vyplní se oboje, pokud chceme zasílat jen při zapnutí/změně hodnoty, vyplní se jen atributy pro ON.

Pokud potřebuje odeslat nejen ON/OFF, ale právě nějakou hodnotu, použijeme značku <v> (pozor, nikoli \v jako v případě vstupů).

Značku <v> můžeme použít i kdekoli uvnitř textu, tzn například “value:<v>” a podobně. Údajně jde takto poslat i textový výstup. Nemám to ale vyzkoušené.

NodeRED příjem dat

Vložit http-in (nebo UDP-ip), nastavit URL nebo port pro daný příkaz. Co je důležité, krom HTTP-in je potřeba také vložit a propojit HTTP response, aby po zavolání požadavku NodeRED požadavek ukončil a odeslal OK response.

Z prvku pak leze textový řetězec, který jsme do něj poslali. Pokud bychom posílali JSON, je potřeba vložit ještě “JSON parse” prvek, který text převede na objekt.

NodeRED odeslální dat

Vložit UDP-out prvek, nastavit cílovou adresu a port, na který se májí UDP data odeslat

Do prvku pak už jen krmíme data a on je odesílá směr Loxone

 

Závěr

A to je vše, takto lze propojit vstupy i výstupy z Loxone s NodeRED bez nutnosti použít nodered-contrib-loxone knihovnu. Je to škoda, protože jinak se knihovna používala parádně, ale bohužel absence automatického reconnectu ji dost vylučuje pro reálné použití (minimálně u nás doma 🙂 ).