Diskuze: Bluetooth reproduktory - automatické připojení po startu systému
Člen
Zobrazeno 23 zpráv z 23.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
mozno ti v tomto scriptiku chyba:
pair 1A:03:26:B1:04:00
trust 1A:03:26:B1:04:00
a na zaciatok by som este pridal:
#!/bin/sh
e este vy som ten script upravil tak, aby pri spustani by zaviedol vsetko
potrebne a pri vypinani a restarte aby saq vypinal (cize aby sa daol pouzit
/init.d/script.sh start|stop|restart
viac na tvirbu initd scriptov najdes v niektorom z ukazkovych skriptikoch a
doplnil by som zavislosti na inych demonoch, ktore tento script spusta
Na začátku samozřejmě mám
#!/bin/sh
postoval jsem sem jen výřezy kódu.
A trust stačí dát jen jednou, pokud se jedná o stále to samé
zařízení, ne ?
Pak by dle mého mělo stačit právě jen to "connect". A takto mi to i funguje
při ručním spuštění. S init.d scriptama umím, jen to nijak potom nebudu
potřebovat, jde mi jen o prvotní spuštění při startu, nijak se to potom
ovládat nebude.
Závislosti na jiných daemonech myslíš něco konkrétního ? Nebo víš jak tyto závislosti zjistit ?
mam na mysli zavislost na pulseaudio, bluetoothd, bluez, aby sa tvij script
spustil az po spusteni vsetkych tych demonov, ktore tvoj script vyuziva
je mozne, ze tvoj script sa spusta este skor, nez su spustene vsetky potrebne
demony
A máš nějakou konkrétní radu, co si kde ohlídat ? Netuším, které věci mám kde hledat a hlídat.
Co jsem četl, tak rc.local by se měl spouštět ať na konci zavedení všeho. Takže se v podstatě spouští až na konci bootování.
Každopádně teď jsem si zkusil spustit rc.local ručně a opět mi píše
chybu že není k dispozici žádný agent a když jsem si poté spustil
rozhraní bluetoothctl ručně, všiml jsem si, že po zadání příkazů
ručně dostávám nějakou odpověď, kdežto při spuštění scriptu s
příkazy za sebou to nic nevypíše, proto má otázka teď zní:
Jsou ty příkazy vůbec odeslány/potvrzeny ? Nebo popř. můžu je nějak
nechat odeslat ? (něco jako "prikaz \n")
podla apt sprvcu balikov odhadujem, ze ficis na deb based Linuxe...
vytvor si spustaci script podla nejakeho ukazkoveho scriptu v danom adresari,
hod ho do /etc/init.d, v adresari /etc/rc3.d vytvot nan link vo formate
SXXscript, kde XX nahradis poradovym cislom vacsim, nez su sluzby, ktore
potrebujes k svojmu scriptu (kludne moze byt vo formate S99script
S znaci, ze sa spusti pri starte v danom runleveli, 99 znaci poradie scriptu
(cize po spusteni vsetkych predchadzajucich scriptov, cize niekedy na konci) a
script je nazov tvojho vlastneho scriptu
alebo, ak pouzivas SystemD bazed distribuciu, tak odporucam vytvorit script pre SystemD, totiz SystemD svoje scripty nespusti, kym nie su vsetky demony spustene, na ktorych dany script zavisi, az po ich spusteni sa spusti dany script
a takisto odporucam aj sa pozriet do /var/log, kde sa loguje beh sluzieb
Zkusil jsem tedy ještě způsob přes init.d, avšak nemám z toho žádný output kromě:
root@3GL0874:~# systemctl | grep btconnect
btconnect.service loaded active running LSB: Connects to the bluetooth speakers
A samozřejmě chová se to stejně jako přes rc.local. Jak jsem psal výše - nemůže být problém v tom, že se ty příkazy neodešlou přes ten script, když se podíváš na screenshot ?
Tak jsem ještě zkusil journalctl a dostal jsem:
Jun 15 10:43:53 3GL0874 btconnect[430]: Starting btconnect
Jun 15 10:44:14 3GL0874 btconnect[430]: W: [pulseaudio] main.c: This program is not intended to be run as root (unless --system is specified).
Jun 15 10:44:15 3GL0874 pulseaudio[633]: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Jun 15 10:44:15 3GL0874 pulseaudio[633]: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Jun 15 10:44:15 3GL0874 pulseaudio[633]: org.bluez.Manager.GetProperties() failed: org.freedesktop.DBus.Error.UnknownMethod: Method "GetProperties" with signature "" on interface "org.bluez.Manager" doesn't exist
Jun 15 10:44:25 3GL0874 btconnect[430]: [105B blob data]
Jun 15 10:44:25 3GL0874 btconnect[430]: [77B blob data]
Jun 15 10:44:25 3GL0874 btconnect[430]: [bluetooth]# power on
Jun 15 10:44:25 3GL0874 btconnect[430]: [bluetooth]# agent on
Jun 15 10:44:25 3GL0874 btconnect[430]: [bluetooth]# default-agent
Jun 15 10:44:25 3GL0874 btconnect[430]: No agent is registered
Jun 15 10:44:25 3GL0874 btconnect[430]: [bluetooth]# connect 1A:03:26:B1:04:00
Jun 15 10:44:25 3GL0874 btconnect[430]: Attempting to connect to 1A:03:26:B1:04:00
Jun 15 10:44:25 3GL0874 btconnect[430]: [61B blob data]
Jun 15 10:44:25 3GL0874 btconnect[430]: [91B blob data]
Jun 15 10:44:25 3GL0874 btconnect[430]: [26B blob data]
Jun 15 10:44:25 3GL0874 btconnect[430]: (bluetoothctl:675): GLib-CRITICAL **: Source ID 26 was not found when attempting to remove it
Takže v podstatě opět to samé.
scripty pre SystemD su uplne ine, nez pre init.d, aj ked dokaze spracovat aj init.d scripty
na roote, abclinuxu, ci linuxexprese by mal byt k systemd aj serialik
Tím chceš říct, že pokud to nefunguje přes službu (init.d) nebo přes rc.local, tak by to přes systemd fungovat mohlo ? Nebo to chápu špatně ?
rc.locval je cast z InitD a InitD zavadza sluzby a spusta init scripty rad za
radom, najprv pri spustani sa spustia linky KXX..., az potom sa spustaju
SXX...
a pokial nemas SXX pre dane procesy v poradi, podla daneho cisla, cize podla
abecedy
ale SystemD k spustaniu sluzieb pristupuje uplne inac, on sa pozrie pri spusteni sluzby, na zavislosti, ak je dana sluzba zavisla od inej sluzby a nie je este spustena, tak pocka, kym sa vsetky sluzby nespustia, na ktorych je zavisla a az potom spusti ju a zaroven SystemD umoznuje paralelne spustanie sluzieb
trosku som to zjednodihsil, viac o tom najdes v clankoch na serveroch, co som ti odkazal, tsam sa viac venuju init procesom
Zkusil jsem tedy nastavit autostart přes systemd a chová se to úplně stejně jako v předchozích případech přes rc.local nebo init.d.
Systemd service file, které využívám je:
[Unit]
Description=Connect to the bluetooth speaker
After=dbus-org.bluez.service sound.taget bluetooth.target bluetooth.service pulseaudio.socket
[Service]
Type=oneshot
ExecStart=/home/btconnect
[Install]
WantedBy=multi-user.target
Výstup z journalctl:
root@3GL0874:~# journalctl | grep btconnect
Jun 19 14:17:21 3GL0874 systemd[1]: [/etc/systemd/system/btconnect.service:3] Fa iled to add dependency on sound.taget, ignoring: Invalid argument
Jun 19 14:17:27 3GL0874 btconnect[431]: W: [pulseaudio] main.c: This program is not intended to be run as root (unless --system is specified).
Jun 19 14:17:51 3GL0874 btconnect[431]: [105B blob data]
Jun 19 14:17:51 3GL0874 btconnect[431]: [77B blob data]
Jun 19 14:17:51 3GL0874 btconnect[431]: [bluetooth]# power on
Jun 19 14:17:51 3GL0874 btconnect[431]: [bluetooth]# agent on
Jun 19 14:17:51 3GL0874 btconnect[431]: [bluetooth]# default-agent
Jun 19 14:17:51 3GL0874 btconnect[431]: No agent is registered
Jun 19 14:17:51 3GL0874 btconnect[431]: [bluetooth]# connect 1A:03:26:B1:04:00
Jun 19 14:17:51 3GL0874 btconnect[431]: Attempting to connect to 1A:03:26:B1:04: 00
Jun 19 14:17:51 3GL0874 btconnect[431]: [bluetooth]# quit
Jun 19 14:17:51 3GL0874 btconnect[431]: [61B blob data]
Jun 19 14:17:51 3GL0874 btconnect[431]: [91B blob data]
Jun 19 14:18:01 3GL0874 btconnect[431]: [26B blob data]
Stále si myslím, že by to chtělo spíš přijít na to, zda-li se ty příkazy, které se snažím odeslat opravdu do bluetoothctl odesílají, protože mi přijde že ne. Ale jak jinak tomu interfacu ty příkazy předat než přes pipe nebo EOF ?
root@3GL0874:~# echo -e "power on \nquit" | bluetoothctl
[NEW] Controller B8:27:EB:2F:B3:52 3GL0874 [default]
[NEW] Device 1A:03:26:B1:04:00 JPM2021
[bluetooth]# power on
[bluetooth]# quit
[DEL] Controller B8:27:EB:2F:B3:52 3GL0874 [default]
root@3GL0874:~# bluetoothctl
[NEW] Controller B8:27:EB:2F:B3:52 3GL0874 [default]
[NEW] Device 1A:03:26:B1:04:00 JPM2021
[bluetooth]# power on
Changing power on succeeded
[bluetooth]# exit
[DEL] Controller B8:27:EB:2F:B3:52 3GL0874 [default]
I když to napíšu takto a) přes automatické odeslání příkazu, b) ručně, je zde vidět při ručním odeslání ta odpověď a to si myslím, že je hlavní kámen úrazu, ale co s tím ?
Zrovna jsem narazil na jeden post, kde to někomu také nefungovalo a někdo na to napsal toto:
@Lukas1 - I guess this is really because bluetoothctl works asynchronously. In order to script something more complex you need to somehow wait for each command to complete.
Nějaký nápad ?
Zkus použít wait po každém příkazu, měl by počkat na dokončení.
A nebo to zprasit přes sleep
A to ? Do bluetoothctl interfacu wait dát nemůžu.
[bluetooth]# wait
Invalid command
A jakmile "vylezu" z interfacu, tak se ukončí a s tím to i killne právě probíhající příkaz. Takže moc nepřipadá v úvahu napsat to ve stylu
bluetoothctl <<EOF
power on
EOF
sleep 5
bluetoothctl <<EOF
agent on
EOF
sleep 5
bluetoothctl <<EOF
default-agent
EOF
Funguje to když interfacs spustíš, zadáš jeden příkaz, počkáš,
interface ukončíš, opět spustíš, zadáš druhý atd.?
Tohle by se v bashi mělo dát načasovat.
Teď mě ještě napadá, jestli si dobře pamatuju, v pythonu se dá připojit k terminálu a sypat do něj příkazy nezávisle na tom co terminál dělá, zítra se na to kouknu.
No já nemám přes script jak počkat... kdybych jak počkat měl, tak by to nejspíš fungovalo, ale pokud napíšu do interfacu script a ukončím ho, tak to nepočká ani na splnění toho příkazu a hned se ukončí.
Zobrazeno 23 zpráv z 23.