Forum
@smotek7 Aha, zajimavy poznatek.
Ohledne toho, jaky bordel chodi do UDP virtualniho vstupu, tak presne proto jsem tenkrat zacal tento program resit. Loxone ten UDP neumi prijmout v kuse, rozseka ho na spoustu nahodne malych casti.
Ale je zajimave to s tim UDP virtualnim vstupem.
Muzete @dave / @elapso mrknout, jestli mate nejake jine virtualni vstupy v Loxconfigu? Jestli se to tam s necim nepere, pripadne zkusit na chvili na test odstranit?
Sam pouzivam spoustu jinych UDP vstupu pro komunikaci mezi NodeRED a Loxone, takze problem by v tom byt nemel, spis jestli se to nepere u Vas na necem konkretnim.
@dave: ok, jestli byla i jina SD karta, tak to muzem vyloucit taky.
PS: Jak dopadl vcerejsi test s prohozenim portu a zapnutim debug vystupu. udelalo to neco?
@L a nevie to spracovat lebo to je dlhe a rozseka to?
Myslis ak by posielal len jeden vstup tak by to prislo ok? Narazam na upravu FW quida.
Dle meho pozorovani neni problem v delce, ale v binarni povaze dat.
Z toho co jsem tenkrat testoval to vypada, ze cokoli, kde je nejake \0, \x01,... tzn jakekoli ne-textove znaky loxone vyresi tak, ze je bud zahodi, nebo podle nich ukonci data a zacne nova.
Virtualni vstupy jsou zrejme pripravene jen na primitivni textove hodnoty a vic se nepredpoklada, ze by nekdo potreboval.
A jelikoz Spinel je binarni format, tak on to seka jak ho zrovna napadne. Tzn zmena na jeden vstup by toto nevyresila. Leda nejaky dalsi textovy protokol, ktery ale z pohledu papoucha nebude davat smysl.
A jelikoz ani uprava na posilani jednoho vstupu se zatim nijak nepohla, obavam se, ze nejaky textovy nepripada v uvahu vubec
JJ je to nejak tak, ja ked som ladil protokol pre relayduino tak som tiez s tymto zapasil. Tusim tam este dost aj zalezalo na ukoncovacom znaku prikazu, pouzil som v loxone ';' a za nim pre istotu z arduina posielam este '\n'. S touto kombinaciou nemam ziaden problem. Ale dost som sa s tym natrapil nez som to odladil a chovalo sa to presne takto kokotsky, ze to sekalo prikazy v nahodnych chunkoch, preskakovalo to niektore a tak. Proste vymrdany loxone.
@L Keby to node red prekladal s binaru "dlheho" na text "kratky" bolo by to pomale, nezvladlo dvoj klik? To len teoreticky dotaz.
@smotek7: budes muset v nodered napsat cely SpinelDekoder, coz samo o sobe je docela prace.
Pak to musis prelozit do textu a poslat smer Loxone. A ted je otazka, jak moc je nodered rychly. Toto sem nikdy netestoval.
V Loxonu pak budes muset udelat sto virtualnich UDP vstupu s exaktnim textem, takze tam by to snad uz moc trvat nemuselo, ale opet, nemam vyzkouseno jak se toto chova.
Jinak, ten dvouklik je zatim problem taky jen u dvou-tri lidi, vetsine to zatim funguje. Ten zrejme zase zalezi na vytizeni miniserveru, ze obcas uz pak nestiha. Problem je, ze par jednotlivcu uz ma problem dvoukliku i v zakladnim miniserveru/extension.
V techto pripadech pak bude UDP urcite pomalejsi nez nativni propojeni loxone, takze problem by to neresilo.
Ale vsechny tyhle problemy jsou zpusobene jen posledni verzi LoxConfigu. Staci downgrade a dvouklik beha. A je vlastne otazka, jestli i to tuhnuti nedela jen posledni verze.
Když ovládání "vytuhne", lze vidět v monitoru jen příchozí pakety ze vstupního modulu Quida:
Automatický restart PicoC "c_auto_restart_every_sec" jsme nastavili na 5 minut, a ten také ve stavu vytuhnutí nechodí.
Po restartu (napájení) Loxone se vše rozběhne tak, jak má. Komunikace chodí ze vstupního modulu Quida i na výstupní modul Quida:
Nastavení vstupního modulu Quida:
Nastavení výstupního modulu Quida:
Po restartu napájení již chodí i autorestart PicoC:
Takže podle mě zřejmě z nějakého důvodu vytuhne vykonávání PicoC programu..
Takze Loxone ty pakety vidi, ale PicoC nejede. Skvely ;-).
Tak co mne jeste napada, ze tam na ten port dorazi nejakej obrovskej balik dat, kterej ten PicoC shodi.
Takze ted plz jeste zkuste prehodit to na porty treba 21001 a 21002. Vystupni quido klidne nechte tak jak je.
dobra prace!
ja bych jen dodal, ze ja nemusel odpojovat elektriku, ale stacil restart skrz Loxone HTTP API, ktery jsem si "bezpecne dostal" jako shortcut do iPhonu 🙂
obecne problem s PicoC a tuhnutim asi nebude, protoze treba HUE integrace jede bez problemu a fungovala ikdyz PicoC pro papoucha vytuhlo
No ja ted podeziram tu funkci stream_read. Protoze to je vlastne to jedine, co se tam porad odkola vola a dela. Proto mne napadlo, jestli tam nedorazi nejaky bordel, co tu funkci vytuhne.
I když to s tím tuhnutím nesouvisí, zajímalo by mě, proč jsou v logu vždy (když funguje i nefunguje) 4 řádky té komunikace Quido vstupní karta -Loxone.
Nad tim jsem taky premyslel, ale to muze byt cokoli. Mozna proto, ze tam jsou ty binarni \x0 a on to i v tom monitoru rozseka do 4 samostatnych UDP paketu. Stejne tak pak v tom mustku, kdyz se to prijima, tak tam se to v pripade pokracujicich dat slepuje dohromady:
int nTimeout = 60000;
int nReadPosition = 0;
while ( nReadPosition < nDataSize )
{
//printf("SPINEL - Read data and wait %d", nTimeout);
int nRead = stream_read(quido_udp_stream_read, (char*)pBuffer + nReadPosition, nDataSize - nReadPosition, nTimeout);
if ( nRead == -1 )
{
printf("SPINEL - STREAM READ ERROR (-1), restarting stream");
RestartQuidoUdpStream();
return -1;
}
if ( nRead == 0 )
{
//printf("SPINEL - EMPTY NO DATA");
return 0;
}
nReadPosition += nRead;
}
return nReadPosition;
To co podeziram je, ze ta funkce stream_read v urcitym okamziku proste zustane viset a i kdyz tam ma timeouty a ruzne kontroly, tak nic neudela a ceka.
Ale na to bych ti pak poslal jinou verzi mustku, ktera bude logovat kazde zavolani a kazdy navrat z tehle funkce i s nejakyma cislama co do ni/z ni leze.
OK díky. Domluvím se s @Davem a odpoledne prohodíme porty a dám pak vědět, zda to pomohlo. Pokud nepomůže, pak bychom zkusili tu jinou verzi můstku.
Díky !
Jeste mne napada jeden pokus. Udelejte druhou zalozku opet se vstupnim mustkem a na nej napojte ty 3 vstupy z toho vystupniho modulu.
Dejte je samozrejme na dalsi jiny porty (treba nekam uplne pryc, 23001 a 23002).
At nam bezi dva stejne PicoC programy vedle sebe a zkuste, jestli vytuhnou oba, nebo co to bude delat.