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/2

což 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

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 ?

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.

Opravdu žádné řešení? :-(

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

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

• 1. podružný rozvaděč
     v něm rozšiřující modul xS11 připojen po RS485 - ovládání světel v přízemí
• 2. podružný rozvaděč
     v něm rozšiřující modul xS11 připojen po RS485 - ovládání světel v patře

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

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/2

což 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