• Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    1. Home
    2. kratas
    K
    • Profile
    • Following 0
    • Followers 0
    • Topics 3
    • Posts 6
    • Best 1
    • Controversial 0
    • Groups 0

    kratas

    @kratas

    1
    Reputation
    7
    Profile views
    6
    Posts
    0
    Followers
    0
    Following
    Joined Last Online

    kratas Unfollow Follow

    Best posts made by kratas

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

      posted in Installations
      K
      kratas

    Latest posts made by kratas

    • xS11 Direct switch

      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 ?

      posted in UniPi Extension Modules (Axon & Neuron)
      K
      kratas
    • 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.

      posted in Official EVOK API
      K
      kratas
    • RE: EVOK a xS11 chyba

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

      posted in Official EVOK API
      K
      kratas
    • 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.
      evok1.png

      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

      posted in Official EVOK API
      K
      kratas
    • 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

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

      posted in Installations
      K
      kratas
    • 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/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

      posted in Installations
      K
      kratas