Forum
Ahoj,
měl bych jeden dotaz ohledně rychlosti quida. Defakto i když sem testoval na stole ruzne věci tak až nyní vše reálně nasazuji do domu.. Překvapila mne rychlost quida, kdy i pokud dam do loxone pouze jeden jediný logicky prvek a zmačknu jeden vypínač, tak je to dost pomalé.
Defakto se jedná cca 0.5 sec než dojde k sepnuti rele.
Buď tedy mam něco blbě nastaveno, nebo je problem někde jinde. Chtěl bych se zeptat tvurce quida mustku proč je po stisku tlačítka volana funkce stream_read tolikrat dokola.
Spíše bych předpokladal že se načte vždy max_buffer_size do pole a pak se to pole bude prochazet a postupně z něj vyzobavat
ty přichozí spinel pakety. t.j. v jedne davce se načte většinou cely zaslany požadavek, případně třeba při větším provozu i kus dalšího, ale ten se pak připojí k tomu dalšímu co se načte v dalšim kroku.
Nebo to nějak blbě chapu, takto bych řekl že ta pomalost je tam pravě kvuli tomu načítání.
Díky
Honza
Zde je kus logu:
00000000 192.168.0.50 17:47:12.055 17:47:13.376 PRG Virtualoutput to /lx/log/def.log '2020-12-11 17:47:13.376;SPINEL-DEBUG: Header [2a,61] size[0,12], datasize: 18, streamread: 4\n'
00000001 192.168.0.50 17:47:12.056 17:47:13.381 PRG Virtualoutput to /lx/log/def.log '2020-12-11 17:47:13.381;SPINEL-DEBUG: - stream_read (wait 60000)\n'
00000002 192.168.0.50 17:47:12.057 17:47:13.384 PRG Virtualoutput to /lx/log/def.log '2020-12-11 17:47:13.384;SPINEL-DEBUG: - stream_read (wait 60000)\n'
00000003 192.168.0.50 17:47:12.057 17:47:13.389 PRG Virtualoutput to /lx/log/def.log '2020-12-11 17:47:13.389;SPINEL-DEBUG: - stream_read (wait 60000)\n'
00000004 192.168.0.50 17:47:12.064 17:47:13.399 PRG Virtualoutput to /lx/log/def.log '2020-12-11 17:47:13.399;SPINEL-DEBUG: Data [ADR:31,SIG:52,INST:d,SUM:92,CRC:d], streamread: 18\n'
00000005 192.168.0.50 17:47:12.111 17:47:13.446 PRG Virtualoutput to /lx/log/def.log '2020-12-11 17:47:13.446;SPINEL-DEBUG: - stream_read (wait 60000)\n'
00000006 192.168.0.50 17:47:12.150 17:47:13.485 PRG Virtualoutput to /lx/log/def.log '2020-12-11 17:47:13.485;SPINEL-DEBUG: - stream_read (wait 60000)\n'
00000007 192.168.0.50 17:47:12.160 17:47:13.495 PRG Virtualoutput to /lx/log/def.log '2020-12-11 17:47:13.495;SPINEL-DEBUG: Header [2a,61] size[0,12], datasize: 18, streamread: 4\n'
00000008 192.168.0.50 17:47:12.162 17:47:13.498 PRG Virtualoutput to /lx/log/def.log '2020-12-11 17:47:13.498;SPINEL-DEBUG: - stream_read (wait 60000)\n'
00000009 192.168.0.50 17:47:12.165 17:47:13.504 PRG Virtualoutput to /lx/log/def.log '2020-12-11 17:47:13.504;SPINEL-DEBUG: - stream_read (wait 60000)\n'
00000010 192.168.0.50 17:47:12.178 17:47:13.513 PRG Virtualoutput to /lx/log/def.log '2020-12-11 17:47:13.513;SPINEL-DEBUG: Data [ADR:31,SIG:53,INST:d,SUM:d1,CRC:d], streamread: 18\n'
00000011 192.168.0.50 17:47:12.228 17:47:13.562 PRG Virtualoutput to /lx/log/def.log '2020-12-11 17:47:13.562;SPINEL-DEBUG: - stream_read (wait 60000)\n'
00000012 192.168.0.50 17:47:12.453 17:47:13.788 LNK Value to 0bd9bf14 DigOutputs 00000001 39491
00000013 192.168.0.50 17:47:12.469 17:47:13.804 LNK Value from 0bd9bf14 DigOutputs 00000001
Ahoj,
napis, jaky mas MS a jakou verzi. Pokud mas MS1 a Loxone v11, tak je to proste pomale, protoze Loxone je ..... a proste MS1 zprznil uz natolik, ze nestiha.
Co se tyka logiky, asi popravde nemam moc potrebu obhajovat proc je co napsano tak a tak. Duvody tam jsou a vez, ze to cele ladim uz docela dost let na to, aby to bylo nejoptimalnejsi jak vubec muze byt a zaroven to fungovalo stabilne v tom prisernem PicoC a Loxone HW.
Bez urazky, ale pokud mas pocit, ze je to napsano spatne, muzes zkusit napsat sam. Uz pri studiu Spinel protokolu zjistis, ze je potreba nacitat nanekolikrat, protoze musis nejprve overovat hlavicku, ve ktere prichazi kolik dat je potreba nacist a pote az nacitat dal. Jelikoz se jedna o UDP stream, tak neexistuje zadny pevne dany ramec, ale proste se v kuse cte co prichazi do streamu a sam si musis veci parsovat (a proto musis taky resit, ze muzou prijit dva UDP pakety promotane do sebe a vyjde z toho nesmysl, takze musis resit CRC a dalsi legrace).
Do toho pridej nemoznost prace s dynamickou pameti, ale nutnost brat vse pres globalni promenne (protoze Loxone a protoze PicoC) a mas zabavu na dlouhe vecery a stovky hodin ladeni, aby si to cele rozbehal tak, aby to behalo v desitkach a mozna i stovce instalaci.
A pak, po skoro peti letech prace prijde nekdo, kdo ma po 10ti mintach jasno, ze jsi to udelal spatne.
Prosim, zkus si nejprve zjistit vice info a terba i mrknout do ostatnich vlaken tady na foru, kde neustale dokola vysvetluju, ze je Loxone debil a ze opravdu nemuzu za to, ze zatimco v LoxConfigu v 8.1 zvladne mustek 200 impulzu za sekundu, zatimco v posledni verzi uz zvlada 1-2 impulzy.
Stejne tak je tato informace napsana primo na strance, kde je clanek o mustku ( https://www.vodnici.net/2020/08/loxone-propojeni-s-modulem-quido-od-papoucha/) a kde jsou vsechny informace shrnuty, spolu s odkazem na dalsi informace zde na foru:
- V případě, že vlastníte starý miniserver (původní s KNX portem), je potřeba si pohlídat zátěž můstku. Bohužel díky nejnovejším aktualizacím se miniserver stále více a více zpomaluje. Zatímco ve verzi LoxConfigu v8 zvládal můstek až 100-200 signálů za sekundu, s poslední aktualizací již starý Miniserve zvládá jen 1-2 impulzy za sekundu. Z tohoto důvodu není doporučeno na Quido zavěšovat různé elektroměry a vodoměry, jelikož by mohlo dojít k přetížení miniserveru a jeho restartu. Toto omezení se netýká nového Miniservreu, který má zatím výkonu dostatek. Více info o této situaci zde https://www.vodnici.net/community/loxone-a-arduino/quido-a-novy-loxone-config
Takze tak.
Pekne svatky.
To nebylo nic proti tobě, to jsi špatně pochopil.
mne to jen zajímalo jestli to má nějaký duvod proč se to načítá takto.
Jedná se o Miniserver 2 - posledni aktualizace, resetovaný, prázdný jen vloženy Quido a jedna stranka kde je ovladani osvětleni. log cca 5 minut po restartu, nic na něm neběží jen to co jsem napsal.
A prostě evidentně po zapnutí debug je v tom logu vidět že cca 300ms se děje jen přijem a několikrát se čtou data pomoci stream_read. Takže mne jen zajimalo proč to tak je, jestli je proto třeba nějaký duvod, co mne nedocvaklo.
Jen prostě logicka uvaha co mne napadne pokažde když řeším problém v nějakém projektu...
Všechny odkazy sem četl asi 10x už minimálně...
Honza
Ok, sorry too. Vyznelo mi to jinak, ale pojdme to resit konstruktivne (Mne uz proste jen nebavi, ze cokoli nefunguje, vzdy za to muze mustek, ktery ma mraky instalaci, namisto toho, ze za to muze Loxone, ktery neustale vsem zneprijemnuje zivot).
Jestli to uz dela i Miniserver 2, tak je to v hajzlu, protoze jsou jen dve varianty. Bud Loxone zase neco vymejsli, aby zneprijemnil zivot vsem, nebo je problem nekde v u tebe siti.
Neni totiz duvod, aby za to mohl sam o sobe mustek.
streamread je defakto jen cteni vstupniho bufferu. Je uplne jedno, jeslti se udela 10x streamread(1B) nebo 1x streamread(10B). je to jen nacteni toho bufferu do nejake promenne. To co trva je otvirani/zavirani streamu, ale to se tam nedeje.
Ale k logu. pises, ze to trva 0.5sec. Log ale rika neco jineho:
Header je prijmut v 17:47:13.376, data pak 17:47:13.389, konec dat pak 17:47:13.485.
Tzn pokud pocitam spravne, je to presne 109ms, nikoli 0.5s
To dalsi je uz dalsi prikaz, ktery opet trava 100ms, stale ne 0.5s
Takze zde problem neni.
Co je zvlastni, proc je v logu vickrat za sebou: - stream_read (wait 60000)\n'
To indikuje nejaky bordel v siti pravdepodobne, nebo problemy se sitovou kartou loxone.
Kazde toto volani je aktivovane kdyz se nacita cast fragmentu. Jednou header, jednou data,
tzn mel by si to videt vzdy jen jednou (pokud se nepletu, ale koukam do kodu a melo by to tak byt).
Spinel paket se nacita zjednodusene takto:
ReadSpinelStreamData(g_buff_header, 4);
ReadSpinelStreamData(g_buff_data, nDataSize);
a ReadSpinelStreamData dela toto
while ( nReadPosition < nDataSize )
{
if (c_enable_debug_log)
printf("SPINEL-DEBUG: - stream_read (wait %d)", nTimeout);
int nRead = stream_read(quido_udp_stream_read, (char*)pBuffer + nReadPosition,
....
}
Tzn pokud to vidis vicekrat, znamena to, ze stream_read neni schopny nacist vsechny potrebne data hned napoprve (a to i kdyz nacita jen 4B) a musi to zkouset vickrat.
Z toho mi vypliva problem v siti, nebo problem v Loxone sitove karte.
Vecer zkusim pustit plny log u sebe a podivam se, jak presne vystup vypada. Ten musim bezet koupat prcka.
Btw, ted mne tak napada. V programu je konstanta logging, je tam u toho komentar. 0/1 je zapnuto vypnuto, kdyz das 2, uvidis i co presne ten streamread cte. To mi sem schvalne postni, protzoe to bude pravdepodobne nejaky bordel.
A pak jeste jedna vec, kdyz je zaply loging, tak je cely mustek pomalejsi, protoze to vypisovani do logu bere docela dost prostredku a trva. ale predpokladam, ze si to zkousel i s vyplym logovanim.
//pokud je hodnota 1, do logu se vypisuji detaily o zpracovani prikazu. Hodnota 2 dumpne cele prijate data.
int c_enable_debug_log = 0;
Ok, jasně už to vidím blbě sem to asi tedy popsal.
Ten log co jsem poslal je když stisknu a uvolním tlačítko. prostě udělám cvak rychle udělám cvak. Tudíž v debugu vidím to co jsem poslal a subjektivně než se sepne rele a zapne světlo to trva celou tu dobu toho logu t.j. od 17:47:13.376 do 17:47:13.788 než se sepne rele.
Pokavad udělám to, že tlačítko stisknu a držím a pak třeba po 3 sec pustím nebo dříve to není tak podstatne. Tak ta změna nastane okamžitě. No protože už je tam jen to rozpojeni. Možna to mam jen nějak blbě nastavena. Tlačítko mám připojení na vstup T5/1 blok ovládání osvětlení.
Ja mam všechny světla přes DALI, teď sem přidával světlo do technicke kde je spinane pomoci rele v loxone a tak sem si toho všimnul, ostatni co jsem teď nastavoval sem bral prostě jako fakt, že je to přes DALI a tak to tak zpožděne funguje ...
Tak tech vice readu mi to dela taky, ocividne ty data od Loxone chodi vice rozfragmentovane nez sem si myslel a proto se ctou navickrat. UDP nema garantovano, ze data prijdou v kuse a ocividne Loxone to nejak vic seka. proto se cte vickrat.
Obcas mi to nacte napoprve, obcas 2x, obcas 3x. Loxone 8 jeste neukazuje milisekundy, ale tika mi tam toho mraky, protoze na tom jedou vsechny elektromery. Tzn tech vice nacitani to nezpomaluje a nemusi to nutne byt bordel v siti.
Posílám níže ten kod, prostě to je jedno rychlé cvaknutí:
00000000 192.168.0.50 20:09:00.590 20:09:02.286 PRG Virtualoutput to /lx/log/def.log '2020-12-11 20:09:02.286;SPINEL-DEBUG: - Received data (size:4): data: 2a610012\n'
00000001 192.168.0.50 20:09:00.590 20:09:02.290 PRG Virtualoutput to /lx/log/def.log '2020-12-11 20:09:02.289;SPINEL-DEBUG: Header [2a,61] size[0,12], datasize: 18, streamread: 4\n'
00000002 192.168.0.50 20:09:00.590 20:09:02.293 PRG Virtualoutput to /lx/log/def.log '2020-12-11 20:09:02.293;SPINEL-DEBUG: - stream_read (wait 60000)\n'
00000003 192.168.0.50 20:09:00.590 20:09:02.296 PRG Virtualoutput to /lx/log/def.log '2020-12-11 20:09:02.296;SPINEL-DEBUG: - stream_read (wait 60000)\n'
00000004 192.168.0.50 20:09:00.590 20:09:02.301 PRG Virtualoutput to /lx/log/def.log '2020-12-11 20:09:02.301;SPINEL-DEBUG: - stream_read (wait 60000)\n'
00000005 192.168.0.50 20:09:00.599 20:09:02.328 PRG Virtualoutput to /lx/log/def.log '2020-12-11 20:09:02.328;SPINEL-DEBUG: - Received data (size:18): data: 31b40d000000000000000000000000016f0d\n'
00000006 192.168.0.50 20:09:00.602 20:09:02.331 PRG Virtualoutput to /lx/log/def.log '2020-12-11 20:09:02.331;SPINEL-DEBUG: Data [ADR:31,SIG:b4,INST:d,SUM:6f,CRC:d], streamread: 18\n'
00000007 192.168.0.50 20:09:00.648 20:09:02.379 PRG Virtualoutput to /lx/log/def.log '2020-12-11 20:09:02.379;SPINEL-DEBUG: - stream_read (wait 60000)\n'
00000008 192.168.0.50 20:09:00.655 20:09:02.384 PRG Virtualoutput to /lx/log/def.log '2020-12-11 20:09:02.384;SPINEL-DEBUG: - stream_read (wait 60000)\n'
00000009 192.168.0.50 20:09:00.669 20:09:02.398 PRG Virtualoutput to /lx/log/def.log '2020-12-11 20:09:02.398;SPINEL-DEBUG: - Received data (size:4): data: 2a610012\n'
00000010 192.168.0.50 20:09:00.671 20:09:02.401 PRG Virtualoutput to /lx/log/def.log '2020-12-11 20:09:02.401;SPINEL-DEBUG: Header [2a,61] size[0,12], datasize: 18, streamread: 4\n'
00000011 192.168.0.50 20:09:00.674 20:09:02.404 PRG Virtualoutput to /lx/log/def.log '2020-12-11 20:09:02.404;SPINEL-DEBUG: - stream_read (wait 60000)\n'
00000012 192.168.0.50 20:09:00.680 20:09:02.409 PRG Virtualoutput to /lx/log/def.log '2020-12-11 20:09:02.409;SPINEL-DEBUG: - stream_read (wait 60000)\n'
00000013 192.168.0.50 20:09:00.707 20:09:02.437 PRG Virtualoutput to /lx/log/def.log '2020-12-11 20:09:02.437;SPINEL-DEBUG: - Received data (size:18): data: 31b50d000000000000000000000000006f0d\n'
00000014 192.168.0.50 20:09:00.708 20:09:02.438 PRG Virtualoutput to /lx/log/def.log '2020-12-11 20:09:02.438;SPINEL-DEBUG: Data [ADR:31,SIG:b5,INST:d,SUM:6f,CRC:d], streamread: 18\n'
00000015 192.168.0.50 20:09:00.756 20:09:02.486 PRG Virtualoutput to /lx/log/def.log '2020-12-11 20:09:02.486;SPINEL-DEBUG: - stream_read (wait 60000)\n'
00000016 192.168.0.50 20:09:00.982 20:09:02.712 LNK Value to 0bd9bf14 DigOutputs 00000003 48084
@honza no tak pockat, takze problem ale tim padem neni v tom, ze klik prijde pozde, ale ze mas zpozdeni u klik&uvolnit.
A to uz zacina byt zase problem trochu jinde. Problem je v tom, ze Quido musi poslat vsechna data vickrat. Nejprve musi quido poslat stav vsech vstupu pri stisku, to se musi rozparsovat a zpracovat.
Pak pri uvolneni quido opet vygeneruje stav vsech vstupu a posle to do loxone, kde se to musi opet cele rozparsovat a zpracovat.
To, ze to je subjektivne rychlejsi pri prodleve je jeasne, protoze se uz neceka na zpracovani predchoziho paketu. Vse co quido posila se bufferuje na strane Loxone a mustek to musi postupne zpracovat.
A tim se dostavame opet k pomalosti PicoC interpretu, ktery se zrejme v tomto pripade uz opet zpozduje a proto nemas klinuti instantne.
Vzdy bude pomalejsi vygenerovat 2x UDP paket se stavem bsech vstupu (nevim kolika vstupove quido mas), poslat to pres ethernet, pak to zase cele rozparsovat a nastavit na loxone vstupy, nez kdyz to jde jen po intreni loxone sbernici bez vsech techto mezivrstev.
Pokud potrebujes instantni rychlost, pouzij originalni HW Loxone. Pisu to i v tom uvodnim clanku, ze Quido se hodi spis na pasivni vstupy, nez na hlavni tlacitka v dome. Je idealni na zaluzie, kde je reakce stejne pomalejsi, nebo okenni kontakty, stavova cidla, atd. Ale ne tam, kde potrebujes instantni odezvu.
jelkoz to jde pres nekolik vrstev a pak stejne zpatky do Loxone, nebude to nikdy tak rychle jako kdyz je to primo v jednom HW.
@honza ad log, je to tim padem nejakych 200ms na kliknuti, protoze vse se musi v mustku zpracovat 2x. poprve se zaregistruje click, podruje release-click.
200ms je rozhodne vic, nez kolik mi to dava na stare v8. Ale toto uz neni neco, co ja dokazu ovlivnit. to uz musis napsat na Loxone, proc stara v8 na MS1 je nasobne rychlejsi nez nejnovejsi MS2 s poslednim Loxone.
Uz od verze v8 mam zmereno, ze s kazdou novou verzi se veci zpomalovaly. nejprve o trochu, pozdeji vyrazneji az do stavu, ze na tom stejnem HW ale jen s novejsim LoxoneConfigu zvlada 1 impulz misto 100 za sekundu.
Duvod? Nevim. Muze to byt zamer, prootze nechteji zadne externi nastroje. A nebo je to diletantismus. A zrejme se to deje na MS2 postupne znovu.
Ale jak sem psal, toto ja nevyresim a nic s tim neudelam, to musis napsat jim.
a jeste ad log k tem datum z debug_log=2, tak tam vidis, ze on posila vzdy stav celeho quida a dle velikosti mas zrejme tu 100/3. takze on musi vzdy na strane quida projit vsechny stavy, otestovat vstupy a vygenerovat retezec a pak na strasne loxone se musi tenhle retezec cely projit, rozparsovat, nastavit spravne vystupy z PicoC programu a jeste behem toho udelat CRC testy, ze ten paket neni bouchly.
A tady uz zrejme narazime na ten vykon MS2. Uvidim, jestli prijdou stavajici uzivatele MS2 s tim, ze se jim rovnez zpomaluje mustek. pokud jo, tak tam Loxone zase zanasi nejaka svinstva.
Ok,
díky za vyčerpávajúci informace, už je mne to jasné.
Jeden poznatek, strávil jsem nad tím ještě XX času teď. Restaret Loxone, quido, celej barak sem odpojil zase zapnul. vyměnil switch a furt stejný.
Teď sem udělal jednu drobnost, nastavil papoucha na TCP server, hned jak se restartoval jsem jej nastavil na UDP a najednou vše funguje,
doba než se provede klik t.j. stisknuti a spuštění je prakticky okamžité, rozsvícení je okamžité.
Jako nechápu
00002930 192.168.0.50 11:14:55.518 11:14:55.664 PRG Virtualoutput to /lx/log/def.log '2020-12-12 11:14:55.664;SPINEL-DEBUG: - stream_read (wait 60000)\n'
00002931 192.168.0.50 11:14:55.528 11:14:55.674 PRG Virtualoutput to /lx/log/def.log '2020-12-12 11:14:55.674;SPINEL-DEBUG: Header [2a,61] size[0,12], datasize: 18, streamread: 4\n'
00002932 192.168.0.50 11:14:55.531 11:14:55.677 PRG Virtualoutput to /lx/log/def.log '2020-12-12 11:14:55.677;SPINEL-DEBUG: - stream_read (wait 60000)\n'
00002933 192.168.0.50 11:14:55.536 11:14:55.682 PRG Virtualoutput to /lx/log/def.log '2020-12-12 11:14:55.682;SPINEL-DEBUG: - stream_read (wait 60000)\n'
00002934 192.168.0.50 11:14:55.545 11:14:55.692 PRG Virtualoutput to /lx/log/def.log '2020-12-12 11:14:55.692;SPINEL-DEBUG: Data [ADR:31,SIG:bc,INST:d,SUM:67,CRC:d], streamread: 18\n'
00002935 192.168.0.50 11:14:55.592 11:14:55.738 PRG Virtualoutput to /lx/log/def.log '2020-12-12 11:14:55.738;SPINEL-DEBUG: - stream_read (wait 60000)\n'
00002936 192.168.0.50 11:14:55.602 11:14:55.748 PRG Virtualoutput to /lx/log/def.log '2020-12-12 11:14:55.748;SPINEL-DEBUG: Header [2a,61] size[0,12], datasize: 18, streamread: 4\n'
00002937 192.168.0.50 11:14:55.606 11:14:55.753 PRG Virtualoutput to /lx/log/def.log '2020-12-12 11:14:55.753;SPINEL-DEBUG: - stream_read (wait 60000)\n'
00002938 192.168.0.50 11:14:55.609 11:14:55.756 PRG Virtualoutput to /lx/log/def.log '2020-12-12 11:14:55.756;SPINEL-DEBUG: - stream_read (wait 60000)\n'
00002939 192.168.0.50 11:14:55.619 11:14:55.766 PRG Virtualoutput to /lx/log/def.log '2020-12-12 11:14:55.766;SPINEL-DEBUG: Data [ADR:31,SIG:bd,INST:d,SUM:67,CRC:d], streamread: 18\n'
00002940 192.168.0.50 11:14:55.649 11:14:55.795 LNK Value to 0bd9bf14 DigOutputs 00000001 36922