Hi!
Just some more info about ‘volumio’ commands.
Volumio uses a mpc emulation layer. As you guess, it is supposed to be used instead of mpc direct command. Why? Using it allows all music services, not only mpd to talk with volumio with the same command while /usr/bin/mpc is just for mpd.
As results, even Spotify, Tidal, Qobuz connect, BlueTooth, Airplay can remote volumio.
Bluetooth remote control doesn’t seem to connect automatically when loading Volumio. Is there a solution to this problem?
After restart (or new start) Volumio I have to ssh bluetoothctl scan on. Then Volumio “find” my Remote.
If I start with bluetoothctl connect 41:42:67:01:D0:10 nothing happen.
Currently, Volumio does not automatically reconnect Bluetooth HID remotes after reboot. If your remote is already paired and trusted, you can reconnect it manually via:
This can be added to a script or run after every reboot via SSH.
A more robust solution with retry logic (e.g., background daemon or timed reconnects) would be best implemented as a plugin, which is a good candidate for future development.
In my case it works with:
Boot ssh volumio@192.168.1.101 bluetoothctl scan on
[Device becomes ready]
This suggests that your Bluetooth remote may not be advertising or discoverable immediately after boot, possibly because:
It goes into low-power or sleep mode
It only wakes and becomes visible when a scan is actively running
It does not maintain an active connection unless explicitly polled
Additionally, for any reconnect logic to work reliably, we still need to confirm the following:
Pairing and trust state
Please run:
bluetoothctl
info XX:XX:XX:XX:XX:XX
Check for these two lines:
Paired: yes
Trusted: yes
Wake behavior
Does the remote send any input (e.g. detected by evtest) after reboot, without running scan on?
If not, does pressing any button first help the reconnect command succeed?
Does running scan on consistently cause the device to become connectable?
This kind of behavior means any reconnect logic would likely need to include conditional checks or retry with periodic scan on bursts. That would be best handled by a plugin with active polling or event-based reconnection logic.
For now, the basic reconnect script can be used, but its success will depend heavily on the specific behavior of your remote.
Let us know the output of info and your observations when scanning or pressing buttons.
Prototype: Auto-reconnect script + systemd Service (Untested)
If you want to experiment with automatic reconnection after reboot, here is a basic SSH-based prototype. This is not officially supported or tested, and may require adjustment based on your setup. Use at your own risk.
Store your device MAC address
echo 'XX:XX:XX:XX:XX:XX' > /data/bt-remote.mac
Create the reconnect script
sudo nano /usr/local/bin/bt-remote-reconnect.sh
Add the following contents
#!/bin/bash
MAC_FILE="/data/bt-remote.mac"
if [ -f "$MAC_FILE" ]; then
MAC=$(cat "$MAC_FILE" | tr -d '\r\n')
if [ -n "$MAC" ]; then
echo "Attempting to reconnect to $MAC"
echo -e "connect $MAC\nexit" | bluetoothctl
fi
fi
If your device is paired, trusted, and reachable, it should reconnect automatically after boot.
Disclaimer: This setup is experimental, untested, and not officially supported. Behavior may vary depending on your device or Bluetooth stack state. A proper reconnect handler with retries and event-driven logic would be more appropriate as a future plugin.
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: ADS7846 Touchscreen
Select the device event number [0-0]:
Remote device do not listed and do not send keystrokes.
No. Device is not connected.
No. After the scan on I have to push any button on remote to connect remote control.
connect XX:XX:XX:XX:XX:XX - not needed. Only bluetoothctl + scan on + button
Maybe it’s a boot script that does two things:
bluetoothctl
scan on
then to enable remote control I’ll only need to press a button.
Although it probably doesn’t work that way, otherwise it would be easy?
Thanks.
Understood. Here is the updated version of /usr/local/bin/bt-remote-reconnect.sh that includes an active scan before attempting to connect:
#!/bin/bash
MAC_FILE="/data/bt-remote.mac"
if [ -f "$MAC_FILE" ]; then
MAC=$(cat "$MAC_FILE" | tr -d '\r\n')
if [ -n "$MAC" ]; then
echo "Starting Bluetooth scan..."
echo -e "scan on\nexit" | bluetoothctl > /dev/null
echo "Waiting for remote to wake up..."
sleep 10
echo "Attempting to reconnect to $MAC"
echo -e "connect $MAC\nexit" | bluetoothctl
else
echo "MAC address in $MAC_FILE is empty."
fi
else
echo "MAC file $MAC_FILE not found."
fi
Notes:
This script initiates scan on, waits 10 seconds, then tries to connect.
This remains experimental and untested. Some remotes still require a manual button press to wake and begin advertising.
Adjust the sleep 10 delay if your remote needs more or less time to become discoverable.
Dear @VictorDUA , dear @nerd ,
my (very simple) HID-remote does survive reboots (if reboots happen ) and even system upgrades.
But I have used the “connect” command during pairing process.(at the end of command-chain)
) and even system upgrades.