Forum
Ahoj, řeším nyní menší problém a už si s tím nevím rady, tak bych se rád zeptal, zdali někdo neřešil něco podobného.
Má konfigurace:
Loxone Miniserver + Loxone Tree Extension + Papouch Quido ETH 30/3 + Papouch Quido ETH 4/32 OC + Relátka od Weidmülleru DRIKITP 24VDC 2CO LD/PB + zdroje obyčejné Mean Well DR-60-24
Relé: https://catalog.weidmueller.com/catalog/Start.do?localeId=cs&ObjectID=2576190000
Zdroj: https://www.czech-meanwell.cz/meanwell/DR-60-24-Mean-Well-Napajeci-spinany-zdroj-na-DIN-li-d265.htm
Aktuálně mám 8 chytrých vypínačů Loxone Touch a pár klasických tlačítkových ovladačů s řazením 1/0 od Schneideru (u nás tomu říkám zvonkový vypínač). S těmi klasickými je onen problém.
Zapojení:
Vlastní zdroj pro Loxone Miniserver, Extension a Loxone Touch vypínače. Zatím v testovacím režimu zapojené na prasáka do jedné dutiny a svorky.
Vlastní zdroj pro relátka a papouch moduly. Napájení a nuly mám propojeny na můstcích.
Výstupy z papouch modulu jdou na relátka, které spínají 230V.
PROBLÉM:
Stává se mi zpravidla, že mi vždy večer přestanou fungovat zvonkové vypínače. Buď nejdou vůbec, nebo se mi také párkrát stalo, že jsem rozsvítil a už jsem nezhasl. Chytré Touch vypínače přitom normálně fungují a relátka spínají. Na výstupech z papoucha naměřím 24V, nepřeskočí to ale na relátko. Na vstupní kartě mám taky 24V, když cvakám vypínačem, bliká i dioda na vstupní kartě. Na výstupu už ale nic. Po vypnutí a nahození jističe od Loxone vše funguje zase normálně.
Nesetkal se někdo s něčím podobným? Můžou být třeba ty zdroje slabé?
Díky moc za každou radu.
U @dave jsme to analyzovali. Skoro každý večer vytuhne komunikace mezi Papouchem kartou vstupů Quido 100/3 a Loxonem. LED komunikace na straně Papoucha bliká, pokud je požadavek na poslání (někdo zmáčkne tlačítko - přijde signál na vstup). V loxonu se ale nic neděje. V LiveView nejde vstup vidět. Zkoušeli jsem pozorovat Log, ale tam se vkládá jen NTP error:
Po restartu loxone se komunikace normálně rozjede, NTP error je tam stále:
(NTP souvisí asi s obecným časováním v síti ?).
Loxone je zapojen do obyčejného switche, dále tam je zapojena Papouch karta Quido 100/3 a Papouch karta Quido ETH 4/32 OC. Když přestane posílat Quido 100/3, tak komunikace s Quido ETH 4/32 OC funguje dále bez problémů - ověřeno. Komunikace s Quido ETH 4/32 OC funguje stále bez problémů.
Zkoušeli jsme vymazat logy dle @pobi, ale nepomohlo.
Stalo se někomu z vás něco podobného ? Případně tušíte, co zkontrolovat nebo jak diagnostikovat chybu? Nejsem vůbec kovaný v síťových komunikacích, ale tuším, že by mohl pomoci Wireshark a diagnostika provozu na síti (komunikace s vnějším světem v rámci switche teď není).
Díky za nápady.
deje se mi absolutne to same, ne s uplne 24h pravidelnosti... uz mam udelanou scheduled tasku na serveru, ktera mi loxone kazdou noc otaci...
v krabici uz ceka 2x DI extension a s papouchem se definitivne rozloucim hned jak bude cas na prekabelovani. tak jako tak povazuju vypinace za zasadni funkcionalitu, ktera by nemela byt zavisla na ethernetu
@georgio:
@elpaso:
Zkusili jste, proc to vytuhne? Jestli je to casem, nebo nejakou jinou udalosti? Zkusili jste treba v pulce dne provest restart, a zjistit, jeslti vytuhnuti probehne stejne nebo ne?
Ohledne detekce, bud wireshark, nebo ma papouch primo spinel tool, ktery kdyz se pusti ve stejne siti, tak ukazuje primo spinel komunikaci.
Ad NTP, to vubec s papouchem nesouvisi a nenapada mne, co by to melo byt. Mam na Loxone zakazanou jakoukoli komunikaci ven a nedela mi to. Takze leda, ze by to byla nejak nova feature
Ohledne tlacitek, vzdy jsem psal, ze kriticke veci bych na quido nedaval. spise okenni kontakty, mene dulezita tlacitka, zaluzie, atd.
Osobne nechapu, proc dvoum lidem se to chova jinak a desitkam dalsich se to chova stejne jako mne. Bud je to neco s miniserver HW, na coz by bylo potreba prohodit miniservery a zkusit, zda se to bude chovat stejne, nebo ne.
Nebo je to neco v siti nebo v LoxConfigu, ale taky se nikomu nepodarilo prijit na to, co by to mohlo byt. Na to by to chtelo vymazat cely loxconfig a nechat tam jen Quido bridge, zda to udela taky. Ale to je v realnem provozu taky narocne udelat.
zkousel jsem to dat na solo switch odpojeny od hlavniho switche a zbytku site. zatezi to neni, sekne se to ikdyz neni nikdo doma...
souhlas, NTP stim rozdhone nema nic spolecneho
bohuzel nahradni MS nemam a toto testovani je cele tak narocne, ze na to nemam cas 🙁
Náhradní MS máme k dispozici, takže to můžeme zkusit, jestli se to bude chovat stejně
A jestli existuje spinel tool, tak super. To zkusíme taky. Chci zjistit, zda Papouch zprávy posílá/neposílá, když se to stane. Pokud posílá, pak bude problém někde na straně Loxone.. z obsahu komunikace snad zjistíme, co se děje..
Díky za rady. Dáme vědět, až na něco přijdeme..
@georgio:
@elpaso:
Zkusili jste, proc to vytuhne? Jestli je to casem, nebo nejakou jinou udalosti? Zkusili jste treba v pulce dne provest restart, a zjistit, jeslti vytuhnuti probehne stejne nebo ne?
Časem ani událostí to podle mě není. Je to zhruba každý den večer, ale zase ne úplně každý den. A stává se to, i když je klid (zatím máme na Loxone jen světla).
Jednou se během dne při bouřce Loxone restartoval (@Dave to poznal tak, že se změnil čas na troubě) a pak večer to nevypadlo.. ale těžko říci, zda to byla náhoda nebo to pomohlo..
@elpaso: když to každou noc restartuješ, pak se ti to neděje ?
kdyz restartuju tak se to deje skutecne vyjimecne, kdy pak staci restartovat manualne...
na test dat z papoucha neni treba druhej MS, to jsem zkousel odchytat wiresharkem. data z papoucha chodej, problem je na strane loxonu
OK díky za info. Jen jsem chtěl zkusit druhý MS, jestli se to bude chovat stejně...
Přemýšlím nad tím proč vytuhne jen quido in 100 a quido out 32 běží. Nemůže být problém, že 100 vstupů je na MS v "nějaký konstalaci" moc? Šlo by Quido na test softwarově osekat třeba na 50 vstupů?
todle tusim Lubos definuje uvnitr te papouch integrace, ja si stim hral a to nicemu nepomuze... daval jsem do papoucha a ruzne verze FW od vyrobce... stale se to chova stejne
@pa-v-el: In a Out nelze uplne porovnavat, protoze to funguej uplne jinak.
Zatimco vstupy se deji tak, ze na strane Loxone v PicoC bezi nekonecna smycka, ktera cte data ze streamu a v pripade, ze neco dorazi, tak to rozparsuje a nastavi na bloku Program adekvatni hodnoty, ktere se pak pres demultiplexer rozhazi na konkretni znacky,
tak vystupy funguji tak, ze v okamziku zmeny hodnoty na vstupu Programu se vytvori odpovidajici retezec a ten se posle pres streams ven.
Tzn jsou to jine smycky a jina logika veci. Z toho vseho, co jsme zatim testovaly je cely tento problem zpusoben tim, ze v pripade vstupu se drzi otevreny socket nekonecne dlouho a nektere miniservery s tim maji problem.
Muj mustek uz dokonce dela to, ze po nejakem case zavira a otvira socket znovu (tzn cely ho restartuje), dokonce anuluje vsechny hodnoty a snazi se simulovat defakto restart programu. Ale ani to nepomaha. Interval tohoto restartu se nastavuje pomoci promenne c_auto_restart_every_sec.
Co se tyka omezeni vstupu, to bohuzel nejde. To je dalsi problem, ktery pro zmenu resim s p. Pouchou, jenze oni zatim stale nedodali slibeny update. Problem je v tom, ze v pripade vstupu (a vlastne i vystupu) se posila vzdy cely stav vsech vstupu/vystupu.
Takze pri stisku 1 tlacitka se posle napriklad 0101010101....101010101. Tzn sto hodnot, ktere ukazuji stav vsech tlacitek. A ja pak musim overit co se zmenilo a na to reagovat. Resil jsem s nimi, aby udelali novy prikaz, ktery posle jen cislo vstupu a jeho hodnotu pri zmene. Bohuzel, zatim se tato modifikace nepohnula dal.
Par lidi p. Pouchovi i psala, ze by tuto zmenu rovnez ocenili a chvili to vypadalo, ze je to na dobre ceste. Ale pak se to cele umlcelo. Muzeme jim zkusit vsichni znovu napsat. Tato zmena ale pravdepodobne nepomuze otevrenemu socketu. Ta spis resi rychlost parsovani, kdy by se dalo o neco zvysit rychlost odezvy a problem poslednich updatu Loxone, kdy nekomu zlobi dvoukliky.
PS: @elpaso Ludek, ne Lubos 😉
sorry 🙂 tesne vedle... nechtel jsem psat "L"
Cital som to len zbezne a mozno placnem uplne mimo, ale ked som kedysi vyvijal komunikaciu medzi arduinom a loxone, pamatam si, ze som uplne zavrhol pouzivat tcp sockety, pretoze sa mi z arduina odoslane spravy v tej zelenej primitivnej sracke zahadne stracali, resp. ze ten socket zatuhol a uz nim neslo nic prestuchnut, musel sa zavriet a znovu otvorit. Mam taky pocit ze to mozno este nejak suviselo s ukoncovacim znakom virtualneho prikazu, ale to uz je len hmliste tusenie, tcp som u loxone definitivne zavrhol a presiel na udp (kde som z podstaty protokolu ocakaval obcasnu stratu paketu, opak je ale po 2 rokoch pravdou).
Spinel (protokol, ktery Quido pouziva) je komplet UDP. Navic je to otrevreno pres stream, takze defakto prijde buffer, ten se znakove projde, zpracuje a dal prijima.
Je tam dokonce ochrana, ze se kazdou hodinu stream zavre, vsechny promenne vynuluji a vse znovu otevre. Ale nepomaha to.
Pravdepodobne leakuje neco uvnitr Loxonu a to jeste jen na nekterych miniserverech (verze miniserveru/configu pravdepodobne nehraje roli).
To sa potom nadherne supportuje riesenie tretej strany (myslim Tvoj kod pre quido) 🤔 Jebnut celu zelenu mrchu z okna ...
