Browsed by
Tag: loxone

Test propojeni FVE, Loxone a Acond

Test propojeni FVE, Loxone a Acond

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.

 

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

Loxone – propojení s modulem Quido od Papoucha

Loxone – propojení s modulem Quido od Papoucha

Na této stránce najdete návod a Loxone program pro propojení modulu Quido ETH od firmy Papouch s Loxone miniserverem. Díky tomu lze výrazně ušetřit na digitálních vstupech i výstupech. Místo ceny 7.938 Kč za extension se 20 vstupy lze koupit za 10.285 Kč Quido modul se 100 vstupy, případně za 7381Kč modul 2/32 se 32 relátky.

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.

loxoneconfig_2016-09-26_16-05-37

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.

chrome_2016-09-26_16-01-15

  1. IP adresa zařízení. Zde zadejte IP adresu pro modul Quido. Tuto adresu je pak potřeba nastavit do Loxone programu
  2. Port, na kterém bude Quido naslouchat pro řídící UDP pakety, zde nastavte 10002
  3. Režim Quida. Zde je potřeba nastavit UDP
  4. IP adresa Loxone Vašeho miniserveru
  5. UDP port, na kterém bude Loxone naslouchat. Nastavte 10001
  6. Dejte uložit a vyčkejte na restart Quida

Návod pro nastavení Loxone

  1. ze souboru Quido-loxone.loxone zkopírujte obsah záložky Quido do Vašeho programuloxoneconfig_2016-09-26_16-10-03
  2. 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
  3. ze souboru Quido-loxone.h zkopírujte obsah do komponenty “Program”.  chrome_2016-09-26_16-18-32
  4. Stejný program zkopírujte také do bloku program pro ovládání výstupů.
  5. V obou programech upravte hodnotu konstant c_remote_listen_address aby obsahovala IP adresu a port Vašeho Quida tak, jak jste ji nastavili v bodě 1) a 5) v návodu “Jak nastavit Quido”
  6. 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”
  7. 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ů.
  8. Dále můžete upravit hodnotu c_relay_check_period_msec, která určuje, jak často se kontrolují stavy vstupů
  9. 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).
  10. 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:

Loxone-Zigbee světla, den druhý.

Loxone-Zigbee světla, den druhý.

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

Zpracování v NodeRED pak vychází ze systému, který jsem popisoval v minulých článcích například zde: https://www.vodnici.net/2022/09/zigbee-tasmota-a-nodered/

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.

https://www.vodnici.net/2023/11/projekt-pro-nodered-na-zigbee-vstupy-vystupy-vcetne-svetel/

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.

Světla, Zigbee a NodeRED

Světla, Zigbee a NodeRED

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

Zigbee, tasmota a NodeRed

Zigbee, tasmota a NodeRed

Dnešní článek je pokračování mého minulého o migraci ze Zigbee2Mqtt na Tasmotu.https://www.vodnici.net/2022/09/upgrade-zigbee/ ‎. Jak jsem avizoval na závěr minulého článku, postupoval jsem podle návodů od Budulínka až do fáze, kdy jsem potřeboval dostat data z/do Loxone. Jelikož při více zařízeních je už z Tasmota logu dat opravdu hodně, nechtěl jsem svůj miniserver v1 tímto úplně zatěžovat, protože mám určitou představu, jak je asi v miniserveru parsování UDP vstupů optimalizováno a jak funguje :).

Můj plán nakonec byl odchýlit se od přímého napojení na Loxone a využít NodeRed, zároveň se ale vyvarovat MQTT protokolu, který mi na Zigbee přijde krajně nevhodný. Cílem tedy bylo parsovat UDP pakety na úrovni NodeREDu a pak už zpracovaná data dostávat do loxone přes Nodered-contrib-loxone. (Teda, původně jsem si říkal, že by mohl být přímo nějaký plugin na Tasmotu pro NodeRED). Ale od toho jsem velmi rychle upustil, když jsem zjistil, že je postavený opět nad MQTT namísto UDP).

A tak jsem začal vymýšlet, jak si to v NodeRED udělat tak, abych měl co nejméně duplicitního kódu, ideálně mít samostatně část na zpracovaní dat z/do Tasmoty a pak už v ostatních záložkách jen využívat takto předpřipravené prvky. Po chvíli hraní si jsem nakonec vymyslel systém pomocí nodu link-in a link-out, které umí předávat předpřipravené msgs mezi vzdálenými prvky.

Výsledek je, že mám dva typy link-in prvků, jeden, do kterého můžu vkládat předřipravenou zprávu ve formátu { device: XXX, data1:x1, data2:x2 } a druhý, ze kterého už lezou naparsovaná data z Tasmoty v podobném formátu.

Takto například konvertuju 0/1 hodnotu z Loxone control-in prvku do Tasmota formátu { "device":  "MiSmartPlug01",  "Power":"1" }.

To hlavní kouzlo se ale skrývá na poslední záložce. Zde mám dva transformační “programy”. První přijímá UDP záznamy z Logu tasmoty a pomocí JS funkce je rozparsuje a vyrobí z ních JSON objekt zmíněný v předchozím odstavci. Pomocí funkce switch pak tento objekt pošlu na konkrétní link-out. Toto by šlo řešit i tak, že se to pošle na univerzální link-out, ale znamenalo by to pak u každého využití testovat, zda jde o správu určenou danému prvku. Takže mi přišlo lepší si to rozházet už tady a posílat na konkrétně pojmenované výstupy.

Podobně pak funguje i druhý program, který pak naopak ze vstupních objektů udělá příkaz pro tasmotu ve formátu /cm?ZbSend {….} a pošle ho přes HTTP Api do Tasmoty.

A to je veškerá magie :). Díky tomu mohu mít logiku na Tasmotu strčenou bokem na serveru, kde je výkonu násobně více a parsování logů je tam hračka, a předzpracovaná data jsou pak elegantně poslaná do Loxone. Jasně, je potřeba ten NodeRED mezikrok, ale to mi osobně nevadí, naopak, spousta věcí se mi zde dělá lépe, než psát ručně dokola pofidérní parsovací stringy Loxone, které mi přijdou, že ne vždy fungují tak, jak bych čekal :).

Na závěr pak ještě jedno zamyšlení. Možná jste si všimli, že v programu pro ovladače ikea je každý udělaný trochu jinak. Zatímco ovladač pracovny je udělaný tak, že spíná univerzální vstupy vytvořené i v Loxone a až tam se napojuje na logiku, tak ovladač z ložnice je napojený na prvky Loxone napřímo.

Stále totiž hledám nějaký “nejlepší” způsob jak Loxone s ostatními zařízeními propojovat a toto je jeden z pokusů. Zatím musím říct, že první varianta mi přijde lepší. Sice to znamená vytváření vstupů/výstupů i na straně Loxone, ale dává to celému systému takovou lepší kulturu. Je pěkně oddělěno NodeRED zpracování dat, které komunikuje jen s konkrétními vstupy v Loxone na nějakém centrálním místě a až v Loxone se pak těmto vstupům dává konkrétní funkce.

Díky tomu se pak v celém LoxConfigu lépe orientuje a hlavně i po čase, když člověk hledá kde/co se proč děje, tak je to na jednom místě. Zatímco když do toho šahá NodeRED napřímo, je občas dost složíté dohledat, proč se něco zrovna seplo.

Tak to jen takový poznatek na závěr. Klidně napište, jestli máte ještě nějaký jiný sýstém organizace nebo k jakým závěrům jste po čase využívání došli vy.

Upgrade Zigbee

Upgrade Zigbee

Tak jsem si po delší době doma zase trochu zabastlil, dokonce i pájku oprášil, a tak bude dneska i článek :).

Přinucen okolnostmi jsem se musel rozhodnout, zda dát dohromady rozbitý zigbee2mqtt, nebo se dokopat a využít skvělého návodu od Budulínka a přemigrovat celé Zigbee na Tasmotu (donucen proto, že po dvou výpadcích proudu v noci a nouzovém vypnutí serveru se mi rozbil databázový soubor zigbee2mqtt a celá síť se rozpadla).

Bohužel, včera nebyl zřejmě můj den a tak do čehokoli jsem se z toho pustil, tak ani se skvělým návodem mi prostě nefungovalo vlastně nic 🙂

Začal jsem flashováním pomocí Tasmotou doporučeným adaptérem. No, tak ten ani zaboha. Nejprve jsem myslel, že jsem si blbě napájel piny na připojení kablíků, nebo že jsem někde zapojil něco špatně. Ale proste nic. Neustále chyba “Unexpected error: ESP Chip Auto-Detection failed: Failed to connect to Espressif device: No serial data received.”. Když ani několikáté přeměření a překontrolování nepomohlo, zkusil jsem druhý adaptér. Naštěstí jsem totiž tenkrát objednal dle návodu od Budulínka oba dva.

A světe div se, fungoval napoprvé. Takže ponaučení číslo jedna, nespoléhat na oficiálně doporučené adaptéry a brát radši oba 🙂

Připojení do sítě pomocí ethernetu prošlo napoprvé a tak jsem pokračoval v nahrávání firmwaru do už flashnutého zařízení. I to proběhlo dobře a už jsem začínal mít pocit, že už bude jen dobře….

Nebylo :). Po restartu zařízení zahlásilo “zigbee not available” a nazdar. Skvělý. Takže jsem rozbil něco cestou při flashování?

Takže znova flash zpátky původního firmware, znova pokus na nový firmware, stažení i beta firmware…. a nic. Furt to stejné.

Tak jsem šel do logů. V nich nic neříkající hláška “ZGB: timeout, goto 99”. Ok, takže se zigbee zařízení nestihne ohlásit včas? A tak zas půl hodiny googlení.

Trvalo to, inženýři z Tasmoty se to snažili velmi úspěšně maskovat a schovat, ale našel jsem to. Problém není v Zigbee zařízení :).

Problém je (a ukáže se v logu, když dáte maximální detaily logování), že Tasmota se nedokáže připojit k NTP time serverům a synchronizovat čas, a proto zakáže Zigbee… ok.

Takže pokračovalo kolečko, proč se vlastně nedokáže připojit. Ukázalo se, že nefunguje DNS překlad NTP adresy. Ale proč..

No, odpověď pak už byla vcelku snadná. Protože mi výpadek elektriky sestřelil nejen Zigbee2mqtt VM, ale také PiHole DNS server. Takže ten přestal fungovat a zatímco ostatní zařízení umějí pracovat i se sekundárním DNS, které mám nastaveno, tak Tasmota ne.

Takže jsem cestou ještě obnovil zálohy PiHole VM, opravil DNS resolver a pak už tasmota najela včetně Zigbee adaptéru. Párování a nastavení Tasmoty pak šlo už naštěstí jako po másle, takže jsem jen následoval zmiňované návody.

A to až do fáze, kdy jsem začal propojovat Tasmotu s Loxone. Nakonec jsem se rozhodl nepoužít přímé propojení pomoci UDP parsování v Loxone, jelikož když jsem viděl, kolik dat se do Loxone hrne a že každý virtuální vstup musí data znovu a znovu parsovat. Proto jsem se nakonec rozhodl využít NodeRED a data předzpracovat. Přeci jen mám jen původní miniserver a takto jsem ho spamovat úplně nechtěl. Ale o tom v dalším článku.

Závěrem už jen poděkování Budulínkovi za jeho návody, ušetřilo mi to určitě hromadu dalšího času a nervů, a hlavně, celý systém mi teď přijde o dost stabilnější než původní Zigbee2Mqtt.

Seznam odkazů na návody na Tasmotu:

Hydroponie pro každého řízená Loxone

Hydroponie pro každého řízená Loxone

…. tak teda, když ti to v těch trubkách roste dej to příště do celého skleníku ať se s tím nemusím zalévat !

Možná budou pro někoho motivací  slova mojí manželky, když “to” uviděla. Pro mne byla před rokem motivace vyzkoušet, jestli je hydroponie systému NFT tj. pěstování v periodicky tekoucím vodním roztoku vůbec k něčemu a funkční. No a protože jsem měl “nějaký volný” miniserver rozhodl jsem se pro jeho poněkud netradiční využití ovšem s tou podmínkou, že s ním “uřídím celou ptákovinu”. Na internetu najdete sousty článků a ještě více reklam s cílem prodat pěstírnu za “+” 15 tisíc. Základ najdete třeba tadyMůj první pokus stál na trubkách a čerpadle 1.270,- Kč a místo miniserveru můžete klidně použít časovač ke spínání stromečku co se někde každému nudí v šufleti.  Na fóru pak :” Hydroponie s Loxone ? ” .

První informace jak vybudovat hydroponii v jedné větě zní  takto  :

” Vezmi šedou trubku 110 mm, do ní vyvrtej s odstupem 250 mm otvory v jedné řadě průměr 68 mm do nich dej pěstební košíčky, jeden konec zacpi zátkou s otvorem pro 1/4″ trubku na druhý dej spojku 110 mm do ní  vlep přepadovou přepážku s odpadními a odtokovým otvorem, pokračuj zátkou-přechodkou na 40 mm trubku, tu strč do nádrže ve které bude čerpalo a 1/4″ PE trubkou to zaveď na druhý konec, čerpadlo roztoku dej na časovač, nalej vodu s živným roztokem, pH 5,9 nalaď regulátorem, dej tam předpěstované rostlinky a jen se dívej jak to roste.”

Nechci se tady zabývat hydroponií z pohledu “lodyh” toho najdete na netu mraky celkem pěkně ve videu od GARDENIX  ostatní si najdete i jinde jenže … nikdo vám neřekne všechno,  jen kousek pravdy a pak chce prodat řešení.

V první informaci je to co najdete všude  a teď to podstatné v druhé informaci :

” Spád trubky udělej 2-3 mm / 1 m ), nedělej delší sekce trubky v jednom sklonu více jak 4 m, spočítej si objem jedné trubky zaplněné na 85%, vynásob to počtem trubek obsluhovaných jedním čerpadlem (prostě jednu sadu  hydroponie ), vynásob to 2-3x a to je objem tvé nádrže, před odtok do nádrže dej vnitřní přepadovou přepážku, na časovači čerpadla nastav poměr “čerpá / pauza” 2,5 :1.” 

Jednoduché že ? takže asi takto vypadají přepážky :

Nádrž, ve které je vložena ještě přepadová komora, aby čidla pH, TDS a teploty byla v každém stavu cyklu čerpadla  hydroponie zaplněna vypadá takto:

Jen pozor přepad nesmí končit pod hladinou, ale musí volně po zakrytí poklopem padá voda do komory aby se kapalina provzdušnila. Druhý konec pak vypadá takto:

Vřele doporučuji dát tam ty kohouty, abyste mohli regulovat přítok do každé trubky zvlášť, taky je možné dát záložní paralelní čerpadlo z nádrže protože když se jedno zastaví nepřijdete na to hned a lodyhy vám takovou věc neodpustí, manželka prohlásí že “ten krám nefunguje” a máte po p… ( po pátkách samo zřejmě )!

Tak a tady pokud nasadíte stromečkový časovač můžete skončit. Ještě si koupíte pH a TDS měřák, pH regulátor ( kyselina fosforečná 60%) a pěstební roztoky např. URBAN Jungle  no a to je vše.

A nebo ! …. si s tím ještě trochu pohrajete…

Jaké parametry měřím a posílám do MS1  :

  • pH ( 0-10V analog vstup )
  • TDS nasycenost roztoku živinami ( 0-10V analog vstup )
  • teplota roztoku ( 0-10V analog vstup )

Co spínat z MS1:

  • čerpadlo roztoku ( 230 V relé )
  • LED osvětlení  pěstírny ( 230 V relé )
  • cirkulaci vzduchu v pěstírně = větráky mám dva ( 230 V relé )
  • dopouštění vody do nádrže mg. ventil ( 230 V relé )
  • peristaltické čerpadlo dávkování pH regulátoru ( 12 V relé )
  • růstový roztok Jungle A ( 12 V relé )
  • růstový roztok Jungle M ( 12 V relé )
  • růstový roztok Jungle B ( 12 V relé )

Což může vypadat třeba takto :

No a protože v pěstírně – skleníku mám i jiné řízení doporučuji ještě ovládat větrání ( 3 x okna motory ) podle teploty a vlhkosti vzduchu v pěstírně takže:  měřit teplotu vzduchu, vlhkost a intenzitu světla což provozuji přes starší instalaci a ESP32 modul takto:

Dále mám ještě krabičku a tři tlačítka na ruční spouštění cirkulačního čerpadla roztoku,  LED světla a impulzu dopouštění  10l  vody. Na analogových výstupech MS1 dva voltmetry 0-10V co mi ukazují  pH a TDS hodnoty …. je to v podstatě zbytečné, když  už to máte na mobilu v App, ale pro manželku to vyvolává dojem, že se ta p……. dá ovládat ( ptákovina samozřejmě !! ) .

Výsledek v jednotlivých fázích potom :

 

Pokud se týče Loxplánu, tak vůbec nebyla legrace nastavit regulaci pH protože regulátor ( kyselinu fosforečnou 60% )  můžete jen přidávat do roztoku. Princip je, že přepadová nádoba co jsou v ní čidla je předřazena hlavní nádobě, kam se teprve dopouští jednak voda tak regulátor tak i složky Jungle A-M-B. Jinak by to nefungovalo na celý obsah roztoku. Navíc dávku ( čas chodu ) peristaltického čerpadla musíte brzdit čím více se blížíte nastavené kýžené hodnotě . To by mělo být pH 5,9.

Loxplán neodpovídá zdaleka dvou dnům pokusů:

 

Další téma je dávkování jednotlivých složek JUNGLE roztoků a to tak, aby byla v nádrži správná koncentrace ( nastaveno 1200 jednotek ) a také podle toho v jaké fázi se pěstírna ( lodyhy )  nacházejí. To jsou režimy dávkování  RŮST / KVĚT / PLOD. Přepínané ručně v App ale na příští rok chystám kameru ( zatím je jen pro přehled a záznam ) s analýzou obrazu, tím budu vyhodnocovat fázi růstu a následně míchání poměru jednotlivých složek JUNGLE 🙂 . To teprve bude ta správná automatizace !

Zatím to vypadá takto :

V App jsou jednak hodnoty čidel, tak historie pH, TDS, teplot vlhkosti , doplňování vody atd… nějak takto:

Co se všechno dá v té p……. ( ptákovině !!! ) pěstovat  ?

Saláty, okurky, rajčata, papriky … zatím:

Aby se měly lodyhy typu okurky a rajčata po čem plazit vzhůru k LED panelům s růstovými světly mají tam natahány u stropu ocelová lanka a k mim připoutané provázky. Pro papriky pak slouží plůtek s bambusovými tyčkami.

Zbývá dodat že všechny rostliny na fotkách jsou samozřejmě pěstovány v pěstebníku se stejným roztokem JUNGLE ale v koncentracích zcela jiných….

Co dodat  ( ?) … to prostě ” musí bavit” a navíc, když odjedete na dovču stará se vám o lodyhy Loxone … jaké jsou s tím spojeny výhody ?

  • nediskutuje o tom co “by se mělo sadit do skelníku”
  • nevyjadřuje se ke způsobu zalévání rostlin
  • nenadává že se o skleník nestaráte
  • prostě se to toho ne…. !!!!!

Video na YouTube je zde:

Na závěr děkuji všem co to dočetli až k tomuto řádku. Pokud bude zájem dám další článek nejen o HW hydroponie ale taky o tom čeho se vyvarovat při pěstování .

P.S. a výhru ze soutěžní otázky co to je :

vyhrává :  @_petr_  ! paprika je to a připravte se že kořenů je v trubkách opravdu dost a dost …  pokud máš zájem pošlu vzorce a nastavení do Loxplánu regulace pH

(c) Dalibor 2022

Netio PowerDIN 4PZ

Netio PowerDIN 4PZ

Tak dneska tu mám představení nové hračky. Dostal jsem ji zase od firmy Netio, od které jsem dříve dostal chytré zásuvky na otestování. Tentokrát jde o jejich nový kompaktní chytrý prvek na Din lištu PowerDIN 4PZ, který ale umí opět všechny naše oblíbené protokoly 🙂

Když jsem byl osloven, jestli bych produkt nechtěl k otestování a k něčemu se mi nehodil, měl jsem vcelku jasno…… bazén :). Letos je v plánu dodělat ovládání našeho bazénu, zakopat všechny hadice a přepojit čerpadlo z prodlužky na venkovní rozvaděč.

Takže malý prvek, který dám do rozvaděče na DIN lištu se hodil naprosto přesně. Co se týká jeho vybavení, je opět naprosto parádní. Má 2x výstup 16A s integrovaným elektroměrem, dále pak 2x výstup jako NO/NC relé, 2x digitální vstup, Lan a WIFI. Takže spínání čerpadla, k tomu možnost spínání druhého zařízení, vstupy pak budou použity jeden pro rychlé spuštění čerpadla při čistění bazénu a druhý zatím zůstane asi nevyužit, ale můžu na něj dát třeba vodoměr, abych věděl, kolik vody jsem profiltroval :)). K tomu pak rovnou díky integrovanému elektroměru získám měření spotřeby čerpadla bazénu. Ideální.

 

Vše jde ovládat jak přes Modbus/TCP, tak přes MQTT nebo XML HTTP REST. Takže integraci lze udělat buď přes NodeRED, nebo napřímo z Loxone přes Modbus.  Koupit lze PowerDIN už nyní na jejich eshopu za 6189 bez dph (7489 s dph).

Zatím mi tu leží v krabici, takže není moc co víc fotit. Věřím ale, že už konečně venku roztaje sníh a začne být i trochu pěkně, takže půjde odzimovat bazén a pustit se do všech potřebných prací :). Další články snad už soon :).