Tak write on change dělá přesně to co potřebuji.

Proměnnou lze modifikovat z druhého místa, ale sesynchronizuje se zpět, když se změní stav logiky v FBD.

Píšu pro případ, kdyby se to někomu také hodilo, protože v dokumentaci o tom není ani píp.

Tak write on change dělá přesně to co potřebuji.

Proměnnou lze modifikovat z druhého místa, ale sesynchronizuje se zpět, když se změní stav logiky v FBD.

Píšu pro případ, kdyby se to někomu také hodilo, protože v dokumentaci o tom není ani píp.

Dobrý den,
Pro spínání světel v domě z více tlačítek (tlačítka jsou na modbus sběrnici a mají vlastní paměť a chovají se jako stiskem zapni, stiskem vypni) používám XOR mezi proměnnými.

Potřeboval bych tu výslednou hodnotu číst a měnit ze vzdáleného místa přes SSCP.

Napadá mě, že by se na to hodilo definovat ji jako write on change, ale nikde v dokumentaci nevidím přesnou definici chování write on change, abych pochopil, zda to je aplikovatelné.

Nebo mi nezbyde nic jiného než mít dvě proměnné? Jednu k zobrazení a druhou přidat jako další vstup do toho XORu.

Díky za pomoc

Pro ty koho by to také zajímalo, zkouším https://github.com/cervenyxp/hass_sscp_integration
Zatím to oťukávám, ještě žádné konkrétní výsledky. Nejprve musím přijít na to jak to celé efektivně "architektovat".

Dobrý den
Dnes 3.7.2025 se mi objevilo místo rozhraní prohlížení databáze, že jsem si měl do 30.6 koupit mervis scada a že jsem si měl do daného datumu stáhnout data jinam.

Jenomže, co mám dělat, když mi ta informace byla sdělena až teď?
Nevím jestli mi nějaký e-mail spadnul do spamu, nebo co, to je jedno.

To to nemohlo být vidět v rozhraní DB? Tam jsem se díval obden. Ještě předevčírem jsem tam přidával nové proměnné ...

Potřebuji ta data.

Scada nepoužívám, a nechci používat, nechci platit (bratr, majitel domu řízeného vašimi PLC, také nechce).

Tohle je zatím největší kudla do zad od unipi.

Jsem opravdu rozčílený.

Zdravím,

postavil jsem řízení domu na dvou unipi jednotkách. Dělá to jen logiku, PID regulaci a pod, časových plánů je tam minimum. Uživatel interaguje jen tlačítky na modbus rtu sběrnici.

Chtěl bych tomu přidat uživatelský komfort, automatizaci podle počasí a podobně, pomocí Home Assistant.
Zatím ale nevím jaká je nejlepší cesta s propojením.

Modbus TCP je možnost, ale je třeba ručně vyplnit tabulky datových bodů. Toho je ale už hoooodně. Uvítal bych nějaký automatický export a import.

Máte někdo zkušenost, jak takovou věc co nejrychleji a nejsprávněji provést?

Díky
Jakub

@cleve
OK, díky, myslel jsem si to, že EN bude ta cesta, ale chtěl jsem se ujistit.

@cleve said in chyba komunikace s Unipi Extension xS51:

@ladmanj
Dobrý den,
teplý restart je možné provést zavoláním funkce reloadapplication s parametrem flags (příznaky restartu, 1 - cold restart, jinak warm). Funkci je možné přidat pravým tlačítkem nebo zavolat z ST.

Omlouvám se, ale není mi jasné jak se ve FBD zavolá ta funkce reloadapplication (nedokumentovaná) tak, aby se restart provedl jen při true boolean proměnné. Kdyby flag 0 byl "žádná akce", 1 "warm restart", 2 "cold restart", tak bych věděl, ale když 1 je cold a vše ostatní je warm restart, tak nějak nevím co dělat.

Chápu že je to míněno tak, že v takovém případě se funkce vůbec nemá volat, ale já nevím jak takovou věc ve fbd nakreslit. Pokud to nepůjde, pokusím se to nadatlovat v ST, ale zatím ho stále neovládám. Dokážu C, C++, python, pascal, assembler pro různé platformy, Verilog, tak se nakonec zvládnu i ST. Zatím mi ale způsobuje nevolnost.

@cleve said in chyba komunikace s Unipi Extension xS51:

Softwarové řešení hw problému není snadné. Můžete zkusit detekovat chybu linky pomocí její proměnné commerror a následně zkusit restartovat extension nebo IO desku Neurona pomocí proměnných reboot.

V tom máte jistě pravdu. Napájení i celkové zapojení je provedeno pečlivě. Nicméně chybu nelze vyloučit v žádném případě.
Komunikace běží na 57600 8N1. Sběrnice je dlouhá cca 5m, na obou koncích zakončená. Na neuronu je zapnut příslušný DIP switch, na opačném konci je 120R rezistor.

Na sběrnici je kromě neurona unipi extension modul a jedno zařízení mé vlastní konstrukce, které interně používá libmodbus.
Použitý kabel je https://www.jablotron.com/cz/produkt/kabel-sbernice-2x20awg-2x24awg-676/
Obě zařízení jsou tímto kabelem také napájená.

Potenciálně problematické je, že v mém vlastním modulu je vzduchový kompresorek s kartáčovým stejnosměrným motorem, ale ten je napájen z (analogového) regulátoru proudu a běží se zlomkem jmenovitého proudu a taktéž se nekoná standardní rozběhová proudová špička.

Ano připouštím, že moje zařízení může teoreticky něco ošlivého poslat do sběrnice. Ano připouštím, že moje zařízení se může "rozhodnout", že do sběrnice bude už navěky bez přestání vysílat a pak komunikace zdechne.

Jenže, jak je v takovém případě možné, že pomůže pokaždé teplý restart mervisu?
Nerestartuje se linux ani nic jiného. Nevypíná se napájení sběrnice.

Mimochodem: už k tomu opět došlo a to i po updatu firmwaru v neuronu. V extension jsem fw ještě neupdatoval. Z bezpečnostních důvodů to nechci dělat přes ssh na dálku.

Díky za případné další informace.

@cleve

Díky, vyzkouším uvedené rady. Firmware jsem od nákupu neuronů neupdatoval, tak v tom vidím naději. Ty proměnné k detekci chyby také považuji za dobré nasměrování.

Opravdu pro mě nemáte žádnou odpověď?

Teď jsem zařízení našel ve stejném stavu. Neuron ukazoval v ladění proměnné červeně a neměnné.

Po teplém startu vše běží.

Není možné komunikaci (s Extension xS51) nějak hlídat a vyvolat teplý restart, pokud se zastaví?

Díky