Griffin powermate

I would like very much to have a discreet pause / play and volume control for my raspberry pi/hifi berry, I was wondering if I can use an old griffin power mate and what would be needed code wise?

I looked around but did not see much in the way of support for such a seemingly simple device.

Does anyone have any idea if I can get the griffin powermate working with volumio?

:cry: There appears to be several approaches to this device. I currently believe the following may be best way to integrate the Griffin Powermate into Volumio.

Problems do occur for pausing. Seems you can not do a “mpc toggle” command to a playing shairport or dlna audio cast stream. You can set volume to zero to mute tho.

EvRouter reads events from the Linux input layer, and acts on them according to a user-specified set of rules. Currently, EvRouter can map events to X11 key and button presses, XMMS commands, and it can also run shell commands. EvRouter is intended to help legacy applications understand modern events such as mouse wheel movement and special keys on keyboards. It also offers hotkey-like functions, and can help existing modern applications deal with events that, for one reason or another, X11 is unaware of (as long as they are accessible through a Linux event device).

freecode.com/projects/evrouter/

screamingroot.org/node/5

So his code:
Window “”
“Griffin PowerMate” “” any key/256 “XButton/2”
“Griffin PowerMate” “” any rel/7/1 “XButton/5”
“Griffin PowerMate” “” any rel/7/-1 “XButton/4”

Would look something like:

Window “”
“Griffin PowerMate” “” any key/256 “Shell/shutdown -hF now”
“Griffin PowerMate” “” any rel/7/1 “Shell/mpc volume +2”
“Griffin PowerMate” “” any rel/7/-1 “Shell/mpc volume -2”

Not sure on exact syntacs but you can see approach. Give shutdown when pressed and up/down volume.

Once working we could add more logic to sense long presses and turning knob while being pressed.

Also guy has a method to do Volumio control from an IR remote controller. He uses lirc sw.

how-installed-lirc-with-receiver-and-remote-volumio-t360.html

mpd is comtrolled thru mpc sw. Type pc help to get list of commands. Also mpc toggle command does not work for airplay.

root@ampit:~# mpc help
Usage: mpc [options] []
mpc version: 0.22
Options:
-v, --verbose Give verbose output
-q, --quiet Suppress status message
-q, --no-status synonym for --quiet
-h, --host= Connect to server on
-P, --password= Connect to server using password
-p, --port= Connect to server port
-f, --format= Print status with format
-w, --wait Wait for operation to finish (e.g. database update)
Commands:
mpc Display status
mpc add Add a song to the current playlist
mpc crop Remove all but the currently playing song
mpc current Show the currently playing song
mpc del Remove a song from the current playlist
mpc play [] Start playing at (default: 1)
mpc next Play the next song in the current playlist
mpc prev Play the previous song in the current playlist
mpc pause Pauses the currently playing song
mpc toggle Toggles Play/Pause, plays if stopped
mpc stop Stop the currently playing playlists
mpc seek [±][HH:MM:SS]|<0-100>% Seeks to the specified position
mpc clear Clear the current playlist
mpc outputs Show the current outputs
mpc enable <output #> Enable a output
mpc disable <output #> Disable a output
mpc shuffle Shuffle the current playlist
mpc move Move song in playlist
mpc playlist Print the current playlist
mpc listall [] List all songs in the music dir
mpc ls [] List the contents of
mpc lsplaylists List currently available playlists
mpc load Load as a playlist
mpc insert Insert a song to the current playlist after the current track
mpc save Save a playlist as
mpc rm Remove a playlist
mpc volume [±] Set volume to or adjusts by [±]
mpc repeat <on|off> Toggle repeat mode, or specify state
mpc random <on|off> Toggle random mode, or specify state
mpc single <on|off> Toggle single mode, or specify state
mpc consume <on|off> Toggle consume mode, or specify state
mpc search Search for a song
mpc find Find a song (exact match)
mpc findadd Find songs and add them to the current playlist
mpc list [ ] Show all tags of
mpc crossfade [] Set and display crossfade settings
mpc mixrampdb [] Set and display mixrampdb settings
mpc mixrampdelay [] Set and display mixrampdelay settings
mpc update [] Scan music directory for updates
mpc sticker <get|set|list|del> <args…> Sticker management
mpc stats Display statistics about MPD
mpc version Report version of MPD
mpc idle [events] Idle until an event occurs
mpc idleloop [events] Continuously idle until an event occurs
mpc replaygain [off|track|album] Set or display the replay gain mode
See man 1 mpc for more information about mpc commands and options

So the problem now I am having is to get the program evrouter installed on the rpi2.

bedroomlan.org/bedroomlan-debian-repository

Even thro it is debian I get the following =>

root@ampit:~# sudo aptitude update
Hit mirrordirector.raspbian.org jessie InRelease
Hit mirrordirector.raspbian.org wheezy InRelease
Ign debian.bedroomlan.org unstable InRelease
Ign debian.bedroomlan.org unstable Release.gpg
Hit debian.bedroomlan.org unstable Release
Ign debian.bedroomlan.org unstable/non-free Sources/DiffIndex
Ign debian.bedroomlan.org unstable/contrib Sources/DiffIndex
Get: 1 mirrordirector.raspbian.org jessie/main armhf Packages [8,963 kB]
Get: 2 mirrordirector.raspbian.org wheezy/main Sources [6,081 kB]
Ign mirrordirector.raspbian.org jessie/main Translation-en_GB
Ign mirrordirector.raspbian.org jessie/main Translation-en
Get: 3 debian.bedroomlan.org unstable/non-free Sources [20 B]
Get: 4 debian.bedroomlan.org unstable/contrib Sources [20 B]
Err debian.bedroomlan.org unstable/main armhf Packages
404 Not Found [IP: 2a01:348:293::bed:1 80]
Err debian.bedroomlan.org unstable/non-free armhf Packages
404 Not Found [IP: 2a01:348:293::bed:1 80]
Err debian.bedroomlan.org unstable/contrib armhf Packages
404 Not Found [IP: 2a01:348:293::bed:1 80]
Ign debian.bedroomlan.org unstable/contrib Translation-en_GB
Ign debian.bedroomlan.org unstable/contrib Translation-en
Ign debian.bedroomlan.org unstable/main Translation-en_GB
Ign debian.bedroomlan.org unstable/main Translation-en
Ign debian.bedroomlan.org unstable/non-free Translation-en_GB
Ign debian.bedroomlan.org unstable/non-free Translation-en
Fetched 4 B in 31s (0 B/s)
W: Failed to fetch debian.bedroomlan.org/debian/dis … f/Packages: 404 Not Found [IP: 2a01:348:293::bed:1 80]
W: Failed to fetch debian.bedroomlan.org/debian/dis … f/Packages: 404 Not Found [IP: 2a01:348:293::bed:1 80]
W: Failed to fetch debian.bedroomlan.org/debian/dis … f/Packages: 404 Not Found [IP: 2a01:348:293::bed:1 80]
E: Some index files failed to download. They have been ignored, or old ones used instead.
E: Couldn’t rebuild package cache

I think the error means there is nothing for the rpi2 soc cpu hw and I must compile evrouter from source. Not sure tho !?! Will try the compile from source approach to make evrouter program.

ALL HELP IS WELCOME.

So I have evrouter running on Volumio. I used the github approach using git-clone and did a compile and make on the pi running Volumio. I got evrouter to compile but broke Volumio 1.55 in the process. During compile allot of php scripts where updated and that may have ruined the Volumio startup files. After I have evrouter redirecting USB device key presses into shell commands I will relook at the Volumio startup being broken issue.

However the new problem is that evrouter requires X windows to run. More specifically from the evrouer developer we have the following info:

“One of my own issues with evrouter is that it depends on X11. It needs the XTEST X11 extension to inject X key events, and it needs access to the X11 window manager so it can tell what window is focused. This must be optional. Evrouter 2 will work without X11, but will still make use of the added information if X11 and a window manager is running.”

So I get evrouter to “run” under Xvfb but I need all of the X11, ie an entire GUI. The rpi2 has plenty of cpu power and the SD card has plenty of memory space but I am having an issue putting a GUI on the Volumio 1.55 distribution. Any suggestions and all input are welcome.

TIA.

:smiling_imp: :imp: Welcome to dependency hell :imp: :smiling_imp:

Why wouldn’t you just make a script that listens to the input events and starts bash commands like mpc stop?
You wont need to install X11 just for interpetation of these events.

Yes that is the plan exactly - if you mean use the ability to execute shell commands thru evrouter based upon input character events on a USB HID device.

If there is a way to read and test input characters from the powermate directly from bash and execute a command please let me know how. That would be so much easier.

However using evrouter you must take all of the program when you compile and link it unless you completely rewrite the source code, and change the evrouter app.

Since evrouter does the Xkey and XMMMS remapping also it requires these libraries in order to compile even tho I have no intention of using this functional capability of the evrouter program.

I have the evrouter program running under a xvfb-run command and all is AOK. As soon as you touch the powermate the program aborts with an X windows I/O error. This IO error occurs (error 22) and is the same whether evouter is run as a daemon or from command line to query your devices output commands (so you can link them with a config file to the redirected shell commands or X key or XMMS). Don’t know if this is a permission issue.

Also I believe there may be an issue with the powermate driver on Volumio 1.55 on a RPI2. The powermate’s USB device number changes over time causing evrouter to stop working as its USB device number has changed. The powermate seems to unattach and reattach and when this occurs the device number goes up by one.

I have a rpi B+ (no evrouter on it tho) and when you plug in the powermate and boot it the device driver loads and the device number stays constant. You can do a lsusb and the device number does not change over time like on the rpi2.

You should be able to fix the USB address issue with udev. Take a look here. http://ubuntuforums.org/showthread.php?t=168221

And there a great introduction to keyboard input here. http://unix.stackexchange.com/questions/116629/how-do-keyboard-input-and-text-output-work

I must admit that I haven’t read them completely but it should point you in the right direction.
I looked in the EVROUTER source code, but I was unable to find the interpreter of the raw events. (probably incompetence)
Mabey you could take a look. There should be a part that reads the raw events.

Or you could search on their site to find what events EVROUTER listens to.

Thanks for your detail reply.

I think I have the powermate udev rules all setup AOK. The evrouter program would not even run with it ready to read the powemate dev until this was done.

Also on the rpi B+ once you plug in the powermate and do a lsusb the device number never changes. I never even setup any udev rules for the powermate but it remained stable at the same number always on the rpi B+. However, on the rpi2, with the rules or without the rules for the powermate device the powermate device number keeps increasing. The powermate detaches and reattaches all the time. It starts out a low number less then 10 and by the next morning it is up to 120+.

Wonder were I can / should report the powermate driver error ?

Hold the horses. I think I have found a much easier approach then the evrouter or the gizmod (gizmo daemon) others have used to redirect the powermate to shell commands.

The evrouter and gizmod approaches require X to run. So why not use the xbindkeys tool that comes with X. You can use this tool to setup a action that’s associated with a button being pressed. This is done purely by entering the proper values in a config file. The link below shows how easy it is to setup a xbindkeys config file so a particular shell command (xterm in the example) is issued whenever a defined mouse button is pressed.

unix.stackexchange.com/questions … or-command
(check out the reference links on the bottom as they are great for udev knowledge)

Also with X it appears you will get Griffin Powermate device setup. I guess the Powermate is used allot on Linux boxes used as numerical controllers. See the support detail and what to look for on control output to X from a Powermate at the following link.

lists.x.org/archives/xorg/2009-April/045234.html
(you have to read up and down the thread to see all the info and the bug solution approach.)

The issue with the bad Powermate driver on the rpi2 remains. Any help on where that issue should be reported is most needed and appreciated.

The other problem also still remains, how do you install all of X on to Volumio 1.55 and not break it? We should make sure that all of X is included in Volumio 2 also.

The approach is great for ANY USB device that X knows about, and that list is huge. So just plug in an old USB mouse into your Volumio and run xev to see the X output protocol for each button or wheel turn of the device and then edit a config file and put in mpc and other shell commands using xbindkeys configuration method to control your Volumio node thru the USB mouse.

I can see folks taking apart a five button mouse with scroll wheels to get total control of their Volumio in the form factor they want and NO SOLDERING. Plus if you use an LED mouse the LED can be treated as a “the kernel is up and USB bus is a active” when the light is on and the hardware is shutdown when the mouse LED light is off.

Lets see, no soldering, complete volume and multiple button control, including a safe shutdown button, with an ON/OFF light for $20-30 by setting up a config file. Sounds good to me.

Why not include full X in Volumio 2 ?!?

No, because of the goal and design of volumio. It’s made for audio.

It should be installable though. A goal for volumio 2 is an apt repository this should make it harder to break.

Awesome. Thanks for the input.

So to test this xbindkeys approach to control a headless rpi with USB devices issuing shell commands I will work with standard Raspbian on a plain rpi2 with no DAC… I will then try and have shell commands issued from a Griffin Powermate, Apple mouse and Microsoft Intellimouse.

Already I had to install the following packages on top of the standard vanilla GUI boot image of Raspbian.

xinput
xbindkeys
xbindkeys-config

Yes the xbindkeys and xinput with shell script methods both work.

Did the test on Raspbian stock with boot to GUI.

Setup button 8 on Microsoft intelli-mouse to perform a reboot.

xinput command is very useful too. States device name and button state. Ran shell script that displays the button # and its state.

Not so lucky with the Griffin Powermate tho. Seems I can not get X to recognize the Powermate. Must make sure that all my udev permissions are done correctly. You see the Powermate with the lsusb command. In fact here is the verbose output of lsusb just for the Powermate:

Bus 001 Device 011: ID 077d:0410 Griffin Technology PowerMate Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x077d Griffin Technology idProduct 0x0410 PowerMate bcdDevice 4.00 iManufacturer 1 Griffin Technology, Inc. iProduct 2 Griffin PowerMate iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 41 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 Media Controller bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 5 Endpoint 1 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.00 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 74 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0006 1x 6 bytes bInterval 10 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 10 Device Status: 0x0000 (Bus Powered)

This is output of xinput -list with the Powermate plugged into the rpi2.

⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ Macally iKeySlim Macally iKeySlim         id=7    [slave  pointer  (2)]
⎜   ↳ Mitsumi Electric Apple Optical USB Mouse  id=9    [slave  pointer  (2)]
⎣ Virtual core keyboard                         id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ↳ Macally iKeySlim Macally iKeySlim         id=6    [slave  keyboard (3)]

Don’t know why X does not see the Powermate. Not sure how to troubleshoot the udev permission either. Setup all the rules.d for the Powermate identical to the folks who get the Powermate to work using the evrouter program. Still X never see’s the Powermate.

Wonder why no one posted anywhere on the web getting the Powermate to work with the xbindkeys method. Seems all Linux users with the Powermate are using the evrouter or gizmod programs, and I do not know why?

BTW here is the output of the command:

egrep “” /proc/bus/input/devices

with just the Apple mouse, MacAlly keyboard and Powrmate plugged into the rpi2.

I: Bus=0003 Vendor=2222 Product=0013 Version=0110
N: Name="Macally iKeySlim Macally iKeySlim"
P: Phys=usb-3f980000.usb-1.3.1/input0
S: Sysfs=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.0/0003:2222:0013.0002/input/input0
U: Uniq=
H: Handlers=sysrq kbd event0
B: PROP=0
B: EV=120013
B: KEY=10000 7 ff9f207a c14057ff febeffdf ffefffff ffffffff fffffffe
B: MSC=10
B: LED=7

I: Bus=0003 Vendor=2222 Product=0013 Version=0110
N: Name="Macally iKeySlim Macally iKeySlim"
P: Phys=usb-3f980000.usb-1.3.1/input1
S: Sysfs=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.1/0003:2222:0013.0003/input/input1
U: Uniq=
H: Handlers=kbd mouse0 event1
B: PROP=0
B: EV=17
B: KEY=10000000 0 0 70000 10000 10000 17a 0 e0000 0 0 0
B: REL=103
B: MSC=10

I: Bus=0003 Vendor=05ac Product=0304 Version=0110
N: Name="Mitsumi Electric Apple Optical USB Mouse"
P: Phys=usb-3f980000.usb-1.4/input0
S: Sysfs=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4/1-1.4:1.0/0003:05AC:0304.0001/input/input3
U: Uniq=
H: Handlers=mouse2 event3
B: PROP=0
B: EV=100017
B: KEY=f0000 0 0 0 0 0 0 0 0
B: REL=143
B: MSC=10

I: Bus=0003 Vendor=077d Product=0410 Version=0400
N: Name="Griffin PowerMate"
P: Phys=usb-3f980000.usb-1.3.2/input0
S: Sysfs=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/input/input6
U: Uniq=
H: Handlers=event2
B: PROP=0
B: EV=17
B: KEY=1 0 0 0 0 0 0 0 0
B: REL=80
B: MSC=2

The fact that the Powermate does not have a mouse handler may be the issue as to why X does not see it. Don’t know tho for sure.

OK success running the evrouter program with the Griffin Powermate on a rpi2 (no I2C DAC card) on a Raspbian GIU install.

Questions about the Powermate rpi2 driver and issues that X seemed not to recognize the Powermate as a HID were not answered. I thought possibly even IF I had the permissions all setup correctly for the Powermate, udev and X the Powermate may not be recognized by X as it may not be in its database of HID. Or said another way possibly X does not have the Powermate in its list of input devices it recognizes (if that is even an issue). Of course having the Powermate recognized by X is required for using either the xbindkeys or xinput --query-states script approaches.

Therefore I installed evrouter on a rpi2 with standard Raspbian that boots to GUI. Then I ran evrouter in debug mode to get output of Powermate control characters. Worked perfectly showing what control characters the Powermate outputs for each turn or knob press.

Then I created /etc/udev/rules.d/powermate.rules with the following content:

SUBSYSTEM=="input", ATTRS{idVendor}=="077d", ATTRS{idProduct}=="0410", SYMLINK+="powermate", MODE="660", GROUP="video"

Made sure user pi was a member of the video group. (The setup for udev rules will be made better later on, but this works.)

Then I created evrouterrc config file with shell commands linked to Powermate output. Powermate button push does “reboot”, turn knob right does “echo Volume UP” and turn volume left does “echo Volume DOWN”. Then I open terminal in GUI and run the following command:

 sudo evrouter -c /etc/evrouterrc /dev/input/event3

and the Powermate does what it is supposed to do. Push knowb down and rpi2 reboots. Turn knob and you see Volume UP and Volume DOWN repeated on the terminal window many times !

Don’t have evrouter running automatically on a boot yet and will setup /dev to a defined device powermate (so the command sudo evrouter -c /etc/evrouterrc /dev/powermate will work) so evrouter is not tied to a specific event# as it is now.

Now the question is can I install evrouter on Volumio 1.55 and get it to run without breaking Volumio 1.55?

This is how I got evrouter to install on vanilla Raspbian boot into GUI.

sudo apt-get install update
sudo apt-get install git-core
sudo apt-get install build-essential
sudo apt-get install libX11-dev
sudo apt-get install libXtst-dev
mkdir git
cd git
git clone git://github.com/larsmagne/evrouter.git
cd evrouter
./configure
sudo make check
sudo make install

Run this command to see if evrouter will run

evrouter --help

Also this was done on top of the current Raspbian GUI boot (2015-11-21-raspbian-jessie image) which has many more modules installed (X org eg.) then Volumio 1.55.

Now I need Volumio gurus to provide knowledge if I could ever get evrouter to run on Volumio 1.55 without breaking it and how to do that.

All input is welcome.
TIA.

SUCCESS !

Ok I have the Griffin Powermate control metal knob successfully attached to a rpi2 Volumio 1.55 node.

I used a C++ program called grifcat that only needed the libusb library. All other (much easier) solutions require X11 packages which when installed on Volumio in order to have an X server running cause Volumio to fail.

The Powermate works great with Volumio on a rpi2. Also running a HiFiberry Amp+ with it.

As the amp and speakers find their “sweet spot”, the the knob gets very sensitive. That is to say the approximate one degree turn of the knob still only allowed mdp to increase by delta 1% (mpc increase +1). However the increase in volume from 33% to 34% doesn’t sound that much louder. However the same 1 degree turn also takes mdp from 79% to 80% and that DOES seem much louder.

Sooooo, since we are a fly by wire control I wrote a stepped shell control script. As the volume increases you need more degrees of turning to add that delta 1% more in mpd volume. Works great and flattens out the control at the high end. Left volume down alone because when you want volume down speed is AOK. When you press the knob the mdp mutes

The sw installation works (thru setup, configurations and coding) on a headless boot and has total hotplug capabilities. Plug in the Powermate after boot, unplug and replug to different SB port it all doesn’t matter the Powermate just works.

The sound control is spontaneous. This does require CPU cycles that always seem <6% most of the time for grifcat and the shell script. If you spin the knob several times righ then left you can peak out around 20% for both tasks when running top.

Let me know if anyone wants source codes and installation instructions for this wired control device.

BTW found a fatal sw bug in Volumio 1.55, but as development has shifted to Volumio 2 it probably will not get solved. If you attach a 5 Ghz WiFi USB adapter and configure it in Volumio 1.55 browser interface all works fine. However when you reboot you loose ALL (wired and wifi) network connections and boot into single user mode. Very ugly, so don’t setup for 5GHz AP’s.

GREAT to see you have it working!
I believe congratulations are in order!

A C++ program that directly reads libusb works on a much lower level than when you tried it trough X11.
That is exactly the route I wanted to point you into. You say that the other solutions that require X11 are much easier, but in fact they turned out to be much harder to get working. :mrgreen:

I think, that if you would compare the cpu load this could even be lower load for the overall device than the x11 solutions. They need more processes thus more ram, more cpu cycles and more storage. Granted you wont notice the storage, but you kept it a truly headless system. :smiley:

Oh and that bug is worthy of a bug report :wink: makes it better to find for others.

@cmullen

nice work,
i would like to buy a griffin knob too but since it is expenxive, i would like to know if it would the whole thing still work with volumio 2.0??

thx in advance

@cmullen. have you had any luck with powermate on Volumio 2?

Yes have Griffin Powermate working with Volumio2. Was quite easy to do. Let me know if you want the details. Using the IQaudio Amp+. The command to incease / decrease volume is different for HiFiberry and IQaudio HAT boards.

You have to know the cli to change volume fir you amp board. It’s probably an mpc or amixer command. This is because you are controlling via fly by wire and sw.