Good afternoon!
As promised after @nerd’s announcement a little bit Bluetooth testing today, so this post is a little bit longer.
For those who are not interested in debugging information the “general” and most important part first:
Installed 4.017 via OTA - went without problems.
Capability of reboot from installer/GUI is still missing.
This time this is unfortunately true for reboot commands from terminal as well- so reboot is currently not possible - hard reset (power off) is neccessary.
As @nerd has promised:
BT remote is connected and it WORKS ! 
- great job, thanks a LOT!.
Unfortunately again one of the rotary encoders has stopped to work - it’s the same one as last time, connected to GPIO 22/27 for rotation and GPIO 17 for clicking. Click works, rotation NOT.
(HW) Config:
Pi5,
Raspi 2 Display (DSI),
Two rotary encoders on several GPIOs - one working fine, one not.
Working BT remote
Testing:
- Spotify plugin, works (my only use case).
- Touch display (and corresponding plugin) works
- “Now Playing” plugin works
- Rotary encoders are working partly
- WiFi is working (can access from laptop / phone).
- BT remote is working (connected and signals detected)
CORRD link still only leads to app-store, no intergrations as far as I can see.
Here my findings during trial of debugging the BT thingy:
Initial attempt: remote is working but not reliably. Some clicks are recognized, some not, Volume increases/decreased two ticks, song skipping skips two songs, play/pause not working.
So I’ve tried to figure out, what the system is recognizing.
from my notes I found that I’ve successfully used in the past
sudo thd --dump /dev/input/event0
sudo thd --dump /dev/input/event1
sudo thd --dump /dev/input/event2
to identify the trigger signals and the channel where the signal is detected.
This doesn’t work anymore. Despite the sytem IS recognizing signals, the above commands didn’t show them up.
From earlier trials I had a weird triggerhappy configuration file which contains the mapping of all events for all three channels - this was my assumption for the reason of the misbehaviour.
So from my perspective it seems that not only the dump of signals isn’t working but the signals are detected on multiple channels in parallel?
Because I was not able to figure out where the signals are detected, I tried/errored in mentioned config file
/etc/triggerhappy/triggers.d/audio.conf
After several reboots I’ve identified that channel 1 works for me, so the current file looks like (as far as I remember correctly this is the default configuration):
#VOLUMIO TRIGGERHAPPY CONFIGURATION FILE
#VOLUME UP
KEY_VOLUMEUP 1 /usr/local/bin/volumio volume plus
#VOLUME DOWN
KEY_VOLUMEDOWN 1 /usr/local/bin/volumio volume minus
#PLAY PAUSE TOGGLE
KEY_PLAYPAUSE 1 /usr/local/bin/volumio toggle
#NEXT
KEY_NEXTSONG 1 /usr/local/bin/volumio next
#PREVIOUS
KEY_PREVIOUSSONG 1 /usr/local/bin/volumio previous
In the course of debugging I’ve made two mistakes:
My older notes suggested to delete “/lib/systemd/system/triggerhappy.socket” - this worked earlier obviously but in current version this socket isn’t re-created after reboot and the service stops working.
Fortunately I made a copy before deleting so I was able to recover and the service works again properly.
Same of my notes suggested as well to use
sudo /etc/init.d/triggerhappy reload
To apply changes in triggerhappy config file to the demon - This fails as well (There is a confirmation statement, but it needed reboot to apply changes).
With the above config file with only one channel per command the Bluetooth remote is working properly.
The SKIP functionalty is a little bit buggy but this is true for the GUI and the rotary encoders, as well - so no problem of the BT device alone.
So far my findings.
Let me know if you need more information, more than happy to deliver.
Really GREAT work - respect!
Nice rest of the day to all of you,
Regards,