Ahoj,
nastavil jsem si chovani LEDek pri ruznych stavech. Vysel jsem ze zde uvedenych ukazek a navodu jinych a jen jsem si to priohnul v podminkach a barvach pro sve potreby. Narazil jsem na jednu nepekny, osklivou vec. V pripade, ze zmenim status LEDek PCI2 nebo PCI3.
Napriklad
rainbow pci2 blue enable
a nasledne zpet na
rainbow pci2 green auto
tak LED pci2 zustane pouze svitit jako ve stavu enable a uz se nevrati k “blikaci” funkci. U pci3 je to obdobne, ta sice zacne poblikavat, ale rozhodne to neodpovida predchozimu stavu, byt provoz se vyrazne nezmenil.
V pripade ze v LuCI vlezu do konfigurace LED a dam pouze ulozit&pouzit, zacnou LEDky spravne blikat. Prijde mi, jak kdyby tim enable&auto zmenou prisli o to spojeni s HW vrstvou.
Nejdrive jsem si myslel, ze jsem zapomnel nekde ve skriptu enable stav, ale ani po zadani z cli se to nezmeni.
Mate nekdo stejny problem? Delam neco spatne? Diky za rady,
kontroluji připojení k internetu connCheck.sh (změna barvy a trigger mode - režimu blikání, současně na wifi vidím, zda jen vysílá maják, nebo zda je někdo připojen)
Výsledkem bylo, že u LED wlan0 a wlan1 se “trigger mode” (link tx rx) změnil ač byl nastaven v “LED Configuration” a bylo nutné jej znova ručně nastavit a potvrdit.
Nelezené řešení spočívá v tom, že existuje soubor /etc/init.d/led_autoconfig kde jsou uloženy i výchozí hodnoty trigger. (to co nastavíš ručne, se restartem nebo jiným zásahem do režimu LED zruší)
v SSH /etc/init.d/led_autoconfig disable (nezkoušel jsem )
nebo úprava souboru v sekci "netdev"
z - uci set system.@led[$i].mode="link tx rx"
na - uci set system.@led[$i].mode="tx"
uci set system.@led[$i].default="1"
uci set system.@led[$i].trigger="netdev"
uci set system.@led[$i].dev="$DEV"
#uci set system.@led[$i].mode="link tx rx"
uci set system.@led[$i].mode="tx"
Tato úprava uchovává nastavení trigger mode u wifi LED i při změnách. (kvůli tomuto problému jsem změnil původní _ connCheck.sh_, tak aby neovlivňoval LED wlan0 a wlan1 a již jsem neověřoval zda to mohu po výše uvedeném zásahu vrátit zpátky)
U me je to tak, ze zakladni barvy LED mam nastavene v rainbow.
Behem dne menim intenzitu pres cron a prikaz, a pak kazdych x minut kontroluji ruzne stavy a obarvuji dle toho ledky, mam na to ledControl.sh - asi bude dost podobne, vysel jsem z toho co jsem nasel tady na foru.
U wlan0 i 1 mam vsechny trigger mody zapnute - link, tx, rx - vidim to tak v LuCI i v config file. Ale prijde mi, ze pokud zmenim enable&auto&disable ve skriptu, tak se ty triggery ztrati - coz bych povazoval za bug.
Zkusim tedy vecer otestovat tento zpusob a uvidime co s tim udela zmena enable/disable. Zatim jsem take zakomentoval zmeny statusu a menim pouze barvu - tam se mi zda, ze to jede dobre.
Nechal by se ten uci set prikaz volat i ze skriptu po zmene? Nebo to lze jen pres konfigurak?
Tak jsem to otestoval a vyměnil si s JardouB pár PM a závěr je takový, že příkazem rainbow pciX enable/disable/auto rozbije nastavení triggeru danne ledky. Bohužel ani následné znovu přiřazení triggeru pres uci set system… A uci commit nepomůže.
Jediné co zabírá je znovu potvrzení triggeru přes LuCI v LED konfiguraci.
Netuší někdo, co spouští uložení tohoto nastavení v LuCI? Případně co nastavit, nebo zavolat, aby se to nerozbilo? Vypadá to na chybu v rainbow. Nastavení nezmizí, všude se dal zobrazuje, jak v LuCI tak pres uci show system, jen ty ledky prostě neblikaji podle triggeru.
Podarilo se mi najit sluzbu, ktera promitne nastaveni LEDek do praxe.
Samotne
uci set system.@led[2].trigger='netdev'
uci set system.@led[2].mode='tx rx'
uci commit system
totiz nefunguje, respektive zmeny se do konfiguraku propisou, ale nestanou se aktivnimi. O to se postara
/etc/init.d/setup_led restart
ktery reloadne konfiguraci a tim ji privede k zivotu.
Zaver je tedy takovy, ze jakykoli
rainbow pci2 enable/disable/auto
rozbije funkci triggeru. Neprisel jsem na to proc, v konfigu LED je vse dobre, ale zmena se neprojevi. Skoro bych rekl, ze v te funkci enable/disable/auto nekde chybi ten reload toho setupu.
Na uplny konec sveho skriptu, pro nastavovani barvy LEDek v zavislosti na ruznych udalostech, jsem tedy pridal
/etc/init.d/setup_led restart > /dev/null
Je sice videt mensi prodleva, protoze ten restart chvilku trva, takze cca 1-2 vteriny sviti LEDky spatne po prikazech rainbow, ale po probehnuti restartu vse blika jak ma.
Vzhledem k tomu, ze to drive nikdo nepozoroval, tak bych to videl na nejakou feature/bug v rainbow pri nejakych nedavnych upravach.