Ahoj,
zkoušel jsem už položit dotaz zde, ale bohužel bez reakce.
Zkusím to ještě tady a jinak a můj dotaz zní, je možné u rozšiřujících modulů zapnout u vstupu direct switch i jinak, než v evoku, např. v konzoli či jinak, bez použití mervisu ?
Posts made by kratas
-
xS11 Direct switch
-
RE: EVOK a xS11 chyba
evok je poslední verze 2.4.12, zkoušel jsem i starší, tam to žádnou chybovou hlášku nehodí, ale změna se neprovede.
Ikdyž to vypadá, že ano, po restartu, je v nastavení opět simple a direct switch se neuložil. -
EVOK a xS11 chyba
Ahoj,
mám unipi Patron M207 a rozšiřující modul xS11, v evok.conf jsem nastavil rozšiřující modul, v evoku ho vidím, vstupy a výstupy, ovládání relé funguje.
Potřebuju ale na inputech u rozšiřujícího modulu nastavit direct switch, stejně jako u M207, bohužel to ale vždy skončí chybovou hláškou.
evok.conf
#!!! Do not use '#' for comments !!! [MAIN] ; !!! ALL MAIN SECTION OPTIONS ARE MANDATORY !!! config_version = 2.5 ; Configuration file version, DO NOT CHANGE! use_schema_verification = False ; Enabling this will deny any requests that do not match the JSON Schema; NOTE THAT THIS RESULTS IN A SIGNIFICANT INCREASE IN LATENCY AND SHOULD NOT BE USED EXCEPT FOR TESTING log_level = ERROR ; Minimum severity of messages to be logged; one of INFO, DEBUG, WARNING, ERROR, CRITICAL log_file = /var/log/evok.log ; Log file to use; will be cleared on boot port = 8080 ; !!! Internal API port - only change if you are certain you know what you are doing; FOR OUR WEB INTERFACE THE PORT SHOULD BE CHANGED IN "/etc/evok-nginx.conf" INSTEAD !!! webhook_enabled = False ; Enables webhook notification - see e.g. https://sendgrid.com/blog/whats-webhook/ webhook_address = http://127.0.0.1:80 ; Put your server endpoint address here (e.g. http://123.123.123.123:/wh ) webhook_device_mask = ["input","wd"] ; List of device types to notify on (written as a JSON list) - adding AI will generate a large amount of messages! webhook_complex_events = False ; EVOK will send POST requests with the same data as WebSocket, rather than an empty GET request soap_server_enabled = False ; Enables the simple SOAP server; use only if you need the functionality soap_server_port = 8081 ; !!! IF SOAP SERVER IS ENABLED, THIS PORT NEEDS TO BE UNIQUE (i.e. different from the port setting above) !!! force_immediate_state_changes = False ; Outputs will return the value they are set to, rather than the value that the device is currently aware of websocket_all_filtered = False ; 'All' WebSocket requests will be subject to the filtering set by 'filter' [NEURON_1] global_id = 1 ; Mandatory, REQUIRED TO BE UNIQUE allow_register_access = False ; Optional, False default scan_frequency = 10 ; Optional, 10 default, scanning frequency in [Hz] scan_enabled = True ; Optional, True default ; Below you can find examples for connecting devices over UART; first example is a Neuron extension while the second is a custom third-party device ; Devices sharing a port use the port settings of the first device on that port (baud rate, parity, stop bits) ; !!! Note that device_name has to match a filename in the /etc/hw_definitions directory !!! See /etc/hw_definitions/CUSTOM_MODBUS_DEVICE.yaml for an example [EXTENSION_1] global_id = 2 ; Mandatory, REQUIRED TO BE UNIQUE device_name = xS11 ; Mandatory, must match name of .yaml modbus map file in /etc/hw_definitions modbus_uart_port = /dev/extcomm/0/0 ; Mandatory neuron_uart_circuit = 1_01 ; Optional, allows associating extensions with specific Neuron UART-over-Modbus ports (not possible for non-Modbus UART ports, e.g. /dev/ttyUSB0 or /dev/ttyS0) allow_register_access = False ; Optional, False default, is mandatory with third-party devices address = 1 ; Optional, 1 default scan_frequency = 10 ; Optional, 10 default, scanning frequency in [Hz] scan_enabled = True ; Optional, True default ; Note that the following settings will be inherited by other devices sharing the same port, i.e. /dev/extcomm/0/0 ;baud_rate = 115200 ; Optional, NEEDS UNIPI IMAGE TO WORK WITH UNIPI SERIAL PORTS! USE API TO CONFIGURE UART MANUALLY IF USING STANDARD RASPBIAN ;parity = N ; Optional, NEEDS UNIPI IMAGE TO WORK WITH UNIPI SERIAL PORTS! USE API TO CONFIGURE UART MANUALLY IF USING STANDARD RASPBIAN ;stop_bits = 1 ; Optional, NEEDS UNIPI IMAGE TO WORK WITH UNIPI SERIAL PORTS! USE API TO CONFIGURE UART MANUALLY IF USING STANDARD RASPBIAN ;[EXTENSION_2] ;global_id = 3 ; Mandatory, REQUIRED TO BE UNIQUE ;device_name = CUSTOM MODBUS DEVICE ; Mandatory, must match name of .yaml modbus map file in /etc/hw_definitions ;modbus_uart_port = /dev/extcomm/0/0 ; Mandatory ;neuron_uart_circuit = 1_01 ; Optional, allows associating extensions with specific Neuron UART-over-Modbus ports (not possible for non-Modbus UART ports, e.g. /dev/ttyUSB0 or /dev/ttyS0) ;allow_register_access = True ; Mandatory with third-party devices ;address = 1 ; Optional, 15 default ;scan_frequency = 2 ; Optional, 1 default, scanning frequency in [Hz] ;scan_enabled = True ; Optional, True default [OWBUS_1] owbus = /dev/i2c-2 ; Mandatory, scanned bus (--i2c=/dev/i2c-1:ALL or localhost:2122 or 'u' for USB dongle) interval = 3 ; Mandatory, [s] length of sensor reading scan_interval = 300 ; Mandatory, [s] How often the scanning is done ; See below for 1Wire extension module configuration ; Example for the 1W-4R/4DI extension module, 1W-8R is almost the same, only with inputs instead of relays ; ; - Map a new 1Wire sensor with the appropriate address, type and interval ; - The syntax can be either SENSOR or 1WDEVICE ; - Setting the correct reading interval is crucial to achieve ideal performance; the default interval is 15s ; ;[1WDEVICE_2] ;bus = 1 ;address = 29F39A17000000BC ;type = DS2408 ;interval = 1 ; ;[1WRELAY_10] ;sensor = 2 ;pin = 0 ; ;[1WRELAY_11] ;sensor = 2 ;pin = 1 ; ;[1WRELAY_12] ;sensor = 2 ;pin = 2 ; ;[1WRELAY_13] ;sensor = 2 ;pin = 3 ; ;[1WINPUT_20] ;sensor = 2 ;pin = 4 ; ;[1WINPUT_21] ;sensor = 2 ;pin = 5 ; ;[1WINPUT_22] ;sensor = 2 ;pin = 6 ; ;[1WINPUT_23] ;sensor = 2 ;pin = 7
verze OS je poslední node-RED
patron-node-red_image.20220103.0.zip
Mám někde něco špatně já, nebo co by mohl být problém, že mi nejde nastavení uložit ? Název vstupu/výstupu se uloží i přes chybovou hlášku, nastavení bohužel ne a to je pro mě klíčové.
Díky
Adam -
RE: Patron a mervis/evok vs home assistant
Modbus už jsem zprovoznil, funkcionalita zatím jen na test rozsvěcením user led je ok, ale někde jsem tu zahlédl na fóru a nechám si raději potvrdit následující věc.
Mám v plánu rozšíření po RS485 do podružného rozvaděče do patra v domě, podaří se mi namapovat přes modbus tcp i registry z rozšíření na sběrnici ? Pokud ne, tak tady celá moje ideologie končí :-( Pak když ne přes modbus, přes evok jsem schopen do HA namapovat rozšíření ?Jinak, evok se mi podařilo nainstalovat na výchozí instalaci OS s mervisem, tak jak byla jednotka vyexpedována.
Omlouvám se za mé nepochopení, ale domníval jsem se, že EVOK a MERVIS jsou dvě odlišné "distribuce" OS, které je možnost rozeběhnout na unipi.
Ale pokud jsem rozeběhl evok ve výchozím stavu, tak mohu používat logiku mervisu a zároveň přes evok vyčítat/ovládat ?Čili, mervis a evok jsou pouze nástavby běžící na linuxu a je tedy možnost jejich souběžného fungování ?
Ještě jednou omluva, ale bohužel jsem tomu nějak neporozuměl.K samotnému HA, viděl jsem na githubu hotové integrace už i skrze evok, zároveň tedy mám ozkoušený modbus a teď tedy nevím, jakou cestou se vydat.
Zcela upřímně (a sám nevím proč) se mi více zamlouvá řešení přes modbus tcp. Potřebuju ale následující fungování, popíšu můj případ.
-
Hlavní rozvaděč
v něm Patron M207 - ovládání venkovních světel, TČ, garážových vrat, žaluzií apod -
- podružný rozvaděč
v něm rozšiřující modul xS11 připojen po RS485 - ovládání světel v přízemí
- podružný rozvaděč
-
- podružný rozvaděč
v něm rozšiřující modul xS11 připojen po RS485 - ovládání světel v patře
- podružný rozvaděč
Zároveň počítám i s teploměry na 1wire, elektroměr přes modbus, podružný elektroměr přes S0 a DI
Základ, tj. ovládání světel, bych chtěl mít napodmínkováno v samotném patronu (mervis?), zde využít možnost direct switch, případně další logika na základě teplot z teploměrů apod.
Zároveň bych ale potřeboval vše ovládat i v rámci HA, např. v závislosti na předpovědi počasí žaluzie, západ/východ slunce světla, a další prvky přes google home, který mám do HA integrován.Nyní ale nevím, jakou cestou se vydat, žiju v domění, že modbus tcp je pro mě správná volba, jak pro ovládání výstupu, tak i pro čtení vstupů, jak to ale bude s rozšiřujícími moduly ?
Ještě k direct switch - tato funkce je dostupná jak na samotném patronu tak i na rozšíření úplně stejně ? Jestli jsem správně pochopil, direct switch je funkce, která je schopna eliminovat "vytuhnutí" samotného systému, který by v případě záseku nebyl schopen provádět logiku ovládání relé v závislosti na DI a je to tedy spíš taková, blbě řečeno, hardwarová záležitost ?
Předem díky za odpověď
Přeji hezký den :-) -
-
Patron a mervis/evok vs home assistant
Ahoj,
zakoupil jsem jednotku Patron M207 do novostavby, pro ovládání všech světel, žaluzií, regulace topení, hlídání teplot, spotřeby z elektroměrů a prostě dalších věcí. které mohu s unipi využít.
Už nějakou dobu provozuji home assistant na rpi s pár zigbee věcma (teploměry, vypínače, dveřní magnety) a wifi žárovkama apod. Zvykl jsem si na komfort a širokou podporu integrací třetích stran a s tím samozřejmě elegantní ovládání a automazice všech prvků.
Home assistanta bych z těchto důvodů rád ponechal a propojil s unipi, už několikrát zde probírané téma, ale mě zajímá pár následujících věcí.
Zatím jsem jen v rychlost zkusil přes modbus tcp viz
https://forum.unipi.technology/topic/694/unipi-neuron-home-assistant-setup/2což funguje zdá se mi super, bohužel nejsem schopen odnikud vyčíst coily ostatních vstupů/výstupů abych s nimi mohl pracovat.
Až jsem si říkal, že varianta s EVOKem a web sockety by mohla být jednodušší, čistší, je tu ale jedno velké ALE ...Potřeboval bych potvrdit či vyvrátit mou domněnku a to, že pokud ponechám mervis, kde si přímo vytvořím základní automatizaci např. světla, digitální vstup č.1 sepne relé č.1, je pro mě daleko lepší (řekněmě spíš spolehlivější) řešení v tom smyslu, že když náhodou padn rpi s home assistantem, pořád mám možnost si rozsvítit, či jiné věci, které bude řídit program přímo v unipi.
Kdežto při variantě s evokem jestli dobře chápu, je veškerá logika a automatizace závislá na rpi a ha v mém případě a pokud rpi lehne, jsem v háji a ani si nerozsvítím :-)
Osobně se mi zamlouvá ponechat mervis a přes modbus propojit s HA - beru to jako takovou přidanou hodnotu mít to zaintegrováno do home assistanta a ovládat dalším způsobem, v závislosti na integraci dalších platforem formou HA.
Je tedy má ideologie mervis/evok vs HA správná ?
Pokud bych razil touto cestou s mervisem a modbus tcp, nejsem aktuálně schopen bohužel zjistit id ostatních coilů :-(
Nějaká dobrá duše, která by mě nakopla správným směrem ?
Moc díky